{"thread":{"id":"53851","subject":"Temporary credentials timeout during long operations","startedAt":"2020-07-13T19:48:56Z","lastAt":"2020-08-26T01:44:35Z","messageCount":2,"participants":["Peterson, Alex","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"401507","messageId":"18381efb749d43d097665960021a76ef@EX13D10UWA004.ant.amazon.com","threadId":"53851","inReplyTo":null,"subject":"Temporary credentials timeout during long operations","fromName":"Peterson, Alex","fromEmail":"alexpete@amazon.com","sentAt":"2020-07-13T19:48:50Z","receivedAt":"2020-07-13T19:48:56Z","isPatch":false,"sender":{"key":"alexpete@amazon.com","avatar":null},"body":"Greetings,  recently I've run into an issue where long push operations fail when using a credential helper like the AWS CodeCommit helper because it provides time-limited credentials which expire during the operation.  Is there an existing method to enforce refreshing credentials from a credential helper on the client or should I go down the path of creating a credential.timeout feature that automatically refills credentials from helpers during long operations to avoid this issue?\n\nSteps to reproduce:\n1. Create a repository with LFS\n2. Add a large file that will take a long time to push (long enough for the credentials to expire)\n3. Enable a helper that provides temporary credentials \n4. Set a remote that uses HTTPS and git push\n\nAll initial HTTPS commands authenticate OK and the LFS file uploads fine but by the time it is done, the credentials have expired so the final git-receive-pack fails and the entire push operation fails.\n\n> POST /v1/repos/example/git-receive-pack HTTP/1.1\n< HTTP/1.1 403 \nerror: RPC failed; HTTP 403 curl 22 The requested URL returned error: 403 \nfatal: the remote end hung up unexpectedly \n\nFor testing purposes I modified post_rpc() so that it always requests new credentials before every HTTPS request, and was able to push any number of large files.\n\nSSH works fine (with keepalives enabled) and so does HTTPS with a permanent username/password, it's just the credential helpers that provide time-limited credentials.\n\nThoughts?\n"},{"id":"404498","messageId":"20200826014426.GB7678@camp.crustytoothpaste.net","threadId":"53851","inReplyTo":"1f95e9da5e734dd3a8f94c1337f8c756@EX13D10UWA004.ant.amazon.com","subject":"Re: Temporary credentials timeout during long operations","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2020-08-26T01:44:26Z","receivedAt":"2020-08-26T01:44:35Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"[Please keep the list in CC.  Other people may have important\ncontributions to the discussion, and due to weather, I may be offline at\nsome point in the future and be unable to respond.]\n\nOn 2020-08-26 at 00:18:05, Peterson, Alex wrote:\n> Hi Brian,\n> \n> 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)\n> https://github.com/git/git/blob/07d8ea56f2ecb64b75b92264770c0a664231ce17/credential.c#L338\n> \n> In my test I cleared the username and password to force it to re-request credentials and that worked OK.\n\nAh, yes.  In that case, it looks like we call credential_reject and then\nreturn HTTP_NOAUTH.  I think the assumption is that the credential\nhelper returns a consistent set of credentials and once we've told the\ncredential helper to reject them, then the user can push again and be\nprompted for new credentials.\n\nI would be open to seeing a patch which, the first time through,\nreturned HTTP_REAUTH.  We wouldn't want to do that indefinitely, since\nthat would mean that the user would get stuck in a loop if the\ncredentials were wrong.\n\nI will say that my gut tells me that it's generally a reasonable\nassumption that credentials are valid for the life of a push, whatever\nthat is, so while I'm not opposed to seeing a patch to improve this, I'm\nnot especially sympathetic to using credentials that have such a short\nlifetime that this occurs, even if I am in general in support of\nshort-lived credentials.\n-- \nbrian m. carlson: Houston, Texas, US\n"}]}