Mark Lodato <lodatom@xxxxxxxxx> writes: >> And for the libcurl not supporting this, I figure it _could_ be done by >> simply letting libcurl prope the remote and see if it can access it without >> a passphrase as that would then imply that isn't necessary. >> >> I'm not familiar enough with the code and architecture to deem how suitable >> such an action would be. > > I don't think it is possible to check to see if it is encrypted from > within git (without calling OpenSSL directly). I think what Daniel is suggesting is to attempt making a test connection (that does not have to have anything to do with the real object transfer) without passphrase to see if it fails. If it doesn't, you know you do not need a passphrase to unlock the key/cert. While I still think that kind of automated detection would be necessary in the longer term (in other words, we do not necessarily have to have it in the initial implementation that appears in our official release), until that materializes, I think it is more prudent to follow the approach below. >> <snip...> If you can't do that, probably you can introduce a config var that says >> "this certificate is encrypted", and bypass your new code if that config var isn't set. I think I've said this already in another message, but "I break your working setup with my patch, but you can add this configuration to unbreak it" should not be done lightly, certainly without a good reason. And the reason here as far as I can see is that the code chooses not to bother with the autodetection of encryptedness of the cert/key. So... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html