Re: [ANNOUNCE] Git 1.7.8.rc0

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 2, 2011, 19:13 UTC
Message-ID: <7vwrbiibgz.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20111102181041.GA5366@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 13 quoted lines

> So the ideal logic is:
>
>   1. look in netrc
>
>   2. If we have a username and no password, ask for password
>
>   3. Otherwise, try it and see if we get a 401.
>
> But we can't do that, because (1) and (3) happen atomically inside of
> curl.
>
> The simplest thing is to just drop the behavior in (2), and let it drop
> to a 401. The extra round trip probably isn't that big a deal.

That is essentially what Stefan's fix is about.

The cases we have "extra" roundtrip are:

 - when you have username@ in URL but no password is stored in .netrc;
 - when you have username@ in URL and no $HOME/.netrc file.

and in such a case using URL without username@ in it as a workaround would save the roundtrip but forces you to type your username@ over and over again, which is _not_ a real workaround.

A workaround for people who want ultimate convenience is to use .netrc to have both username:password, but that is at the cost of potentially reduced security. Having username@ in URL and typing password interactively, if it worked properly, would have been the best of both worlds.

> The other option is to start parsing netrc ourselves, or do the extra
> round trip if we detect ~/.netrc or something. But that last one is
> getting pretty hackish.

I tend to agree that we wouldn't want to parse netrc ourselves (that is what library support e.g. CURLOPT_NETRC is for). The latter is hackish but on the other hand it is a cheap, simple and useful hack.

How would the upcoming keystore support fit in this picture, by the way?