Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)

[Mark Lodato <lodatom@gmail.com>]

On Mon, Jul 6, 2009 at 2:32 PM, Junio C Hamano<gitster@pobox.com> wrote:
> [Stalled and may need help and prodding to go forward]
>
> * ml/http (Wed May 27 23:16:03 2009 -0400) 2 commits
>  - http.c: add http.sslCertPasswordProtected option
>  - http.c: prompt for SSL client certificate password
>
> I've rewritten these two to (1) move the #ifdef out of the main codepath,
> and (2) use configuration/environment to make the misfeature of always
> asking for a passphrase even a key/cert is unencrypted optional.  I tried
> to be careful but extra sets of eyeballs would be nice to check the result.
>
> Nobody seems to be jumping up-and-down asking for this or helping to push
> this forward.  Perhaps it's time to drop it?

Sorry for the lack of updates.  After hearing feedback, the consensus
seemed to be that detection of the certificate's encryption (above)
and file type (other patch, not in git.git) should be done
automatically, that is, without user configuration.  I agree, but
neither can be done without great difficulty outside of libcurl.
Therefore, I have started implement the autodetection of both, as well
as the password caching, directly in libcurl.  If my work, once
completed, is accepted by the libcurl folks, then there would be no
need for the above, and we should recommend upgrading libcurl for
those who want to use client-side certificates.

However, in the interim, and for users with earlier libcurl versions
(and especially if my libcurl patch is never accepted), it might be
nice to still have the above commits.  They are unobtrusive - the
patches are small, and they do not affect users who do not enable the
option - yet they drastically improve the experience for those using
password-protected client-side certificates.

Anyway, I am still very interested in getting proper client-side
certificate support in git, and I am glad to see Marcus is as well.
Ultimately, I think the libcurl solution is the proper way to go, but
this patch series might still be good to include in git. The downside
is that it adds extra crap to the git-config man page and it does
increase the code size a little.

--
Mark