Re: [PATCH 2/2] http.c: add http.sslCertType and http.sslKeyType

On Mon, 15 Jun 2009, Mark Lodato wrote:

quoted

(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