On Mon, Jun 15, 2009 at 1:43 PM, Karsten Weiss<knweiss@xxxxxx> wrote: > Hi Mark! > > On Sun, 14 Jun 2009, Mark Lodato wrote: > >> Add two new configuration variables, http.sslCertType and >> http.sslKeyType, which tell libcurl the filetype for the SSL client >> certificate and private key, respectively. The main benefit is to allow >> PKCS12 certificates for users with libcurl >= 7.13.0. > > This is interesting. Thanks for working on that! > > (However, it's a similar issue like the question whether the private key is > encrypted or not: Usability would be better if the certificate type could be > determined automatically (without having to violate the layering)). Just as with determining if the certificate is password protected, it is equally difficult to tell what type of file it is without calling OpenSSL directly. This brings up a good point: Should we (I) try to implement (client certificate) usability features in git to work around deficiencies in libcurl, or should we (I) write patches to fix/enhance libcurl directly? The latter would be much easier (though I could be wrong) and would benefit other programs using libcurl, but would require users to upgrade libcurl to get these new features, and of course would rely on the libcurl developers accepting the patches. I am willing to do either, but I think the libcurl route would be better. Any thoughts? Anyway, to implement this in git, the algorithm would be something like: for password in [None, "", prompt()]: for type in ["PEM", "DER", (if libcurl >= 7.13.0) "P12"]: try to make a connection with password and type if not certificate error: return success else: return failure This is much more difficult than it may at first appear. I'm sure it can be done, but it will take a while to get it right. Mark -- 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