[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)
From:       Jeff King <peff () peff ! net>
Date:       2009-07-07 21:11:09
Message-ID: 20090707211109.GA1922 () coredump ! intra ! peff ! net
[Download RAW message or body]

On Mon, Jul 06, 2009 at 10:18:03PM -0400, Mark Lodato wrote:

> > * 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
> [...]
> 
> 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.

Yes, even if you get patches into libcurl, we will be supporting libcurl
without this feature for some time. So I think the right upgrade path
is:

  1. add sslCertPasswordProtected as a bool config option now, defaulting
     to false (i.e., your patches)

  2. libcurl grows new auto-detect feature

  3. When the new feature is available at build-time, turn
     sslCertPasswordProtected into a tri-state yes/no/auto, defaulting to
     "auto". For older libcurl, setting it to "auto" should probably
     generate an error (or perhaps simply default to "no").

IOW, whether the libcurl auto-detection feature happens or not, your
patches are the right first step (and if "not", then they are the final
step :) ).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]