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

[Karsten Weiss <knweiss@gmx.de>]

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