Re: Temporary credentials timeout during long operations

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Aug 26, 2020, 01:44 UTC
Message-ID: <20200826014426.GB7678@camp.crustytoothpaste.net>
In-Reply-To: <1f95e9da5e734dd3a8f94c1337f8c756@EX13D10UWA004.ant.amazon.com>

[Please keep the list in CC. Other people may have important contributions to the discussion, and due to weather, I may be offline at some point in the future and be unable to respond.]

On 2020-08-26 at 00:18:05, Peterson, Alex wrote:

Show 6 quoted lines

> Hi Brian,
> 
> Unfortunately, even if the server returns a 401, git will retry but with the old expired credentials which will fail.  I believe it is because of this line that checks if a username/password already exists (which it does)
> https://github.com/git/git/blob/07d8ea56f2ecb64b75b92264770c0a664231ce17/credential.c#L338
> 
> In my test I cleared the username and password to force it to re-request credentials and that worked OK.

Ah, yes. In that case, it looks like we call credential_reject and then return HTTP_NOAUTH. I think the assumption is that the credential helper returns a consistent set of credentials and once we've told the credential helper to reject them, then the user can push again and be prompted for new credentials.

I would be open to seeing a patch which, the first time through, returned HTTP_REAUTH. We wouldn't want to do that indefinitely, since that would mean that the user would get stuck in a loop if the credentials were wrong.

I will say that my gut tells me that it's generally a reasonable assumption that credentials are valid for the life of a push, whatever that is, so while I'm not opposed to seeing a patch to improve this, I'm not especially sympathetic to using credentials that have such a short lifetime that this occurs, even if I am in general in support of short-lived credentials.

-- 
brian m. carlson: Houston, Texas, US