On Mon, 15 Jun 2009, Mark Lodato wrote:
(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.
Hm, thinking about the encryption case: Maybe I'm missing something but
wouldn't it be enough to simply peek at the key file and look for the
string "ENCRYPTED" in a header like this?
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
I.e. a simple, temporary solution that does not depend on OpenSSL to
prevent the introduction of the new http.sslCertNoPass flag?
(But now that you've also created patches for PKCS12 support this might
not be feasible anymore?)
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?
(As a git user without libcurl insights) I think that such query functions
about private keys (Is it encrypted?) or certificates (What type is it?)
would make sense and belong into libcurl. (And it would be great if these
queries could be answered *without* performing actual trial network
connections just by looking into the respective key/certificate files.)
Karsten
--
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