{"thread":{"id":"55174","subject":"git credential cache timeout questions","startedAt":"2021-02-19T15:48:07Z","lastAt":"2021-03-10T15:42:59Z","messageCount":3,"participants":["John Ratliff","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"417407","messageId":"CAP8UukiL0niGSm3o7uYNBzL3FP-UEgfOuq-Tu=fksWJkerT5fg@mail.gmail.com","threadId":"55174","inReplyTo":null,"subject":"git credential cache timeout questions","fromName":"John Ratliff","fromEmail":"john@technoplaza.net","sentAt":"2021-02-19T15:46:48Z","receivedAt":"2021-02-19T15:48:07Z","isPatch":false,"sender":{"key":"john@technoplaza.net","avatar":null},"body":"I have configured my git to cache my credentials for 12 hours using\nthis section in my .gitconfig\n\n[credential \"https://mygithub.example.edu\"]\n    username = myuser\n    helper = cache --timeout 43200\n\nHowever, the credentials don’t always seem to expire after 12 hours.\nSometimes I come back the next morning and the credentials still work.\nThis is generally after leaving at 5:00 PM and coming back in the next\nday at 9:00 AM, well past the 12 hour timeout.\n\nIs there any way to see the current timeout value? Is it a rolling\ntimeout (i.e. any git action resets the timeout)?\n\nIf it happened once or twice, I would assume I just forgot that I did\nsomething with git later than I thought. But this happens frequently\nenough that it’s difficult to accept that as a possibility. It’s not a\ndaily occurrence. My credentials do expire…I just have no idea when\nthey will.\n\nHave I setup my gitconfig section wrong?\n\nCentOS 7. Git 2.24.3.\n\nThanks.\n\n\n--John\n"},{"id":"417409","messageId":"YC/vqJBSnDHoLIdJ@coredump.intra.peff.net","threadId":"55174","inReplyTo":"CAP8UukiL0niGSm3o7uYNBzL3FP-UEgfOuq-Tu=fksWJkerT5fg@mail.gmail.com","subject":"Re: git credential cache timeout questions","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2021-02-19T17:04:40Z","receivedAt":"2021-02-19T17:05:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 19, 2021 at 10:46:48AM -0500, John Ratliff wrote:\n\n> I have configured my git to cache my credentials for 12 hours using\n> this section in my .gitconfig\n> \n> [credential \"https://mygithub.example.edu\"]\n>     username = myuser\n>     helper = cache --timeout 43200\n> \n> However, the credentials don’t always seem to expire after 12 hours.\n> Sometimes I come back the next morning and the credentials still work.\n> This is generally after leaving at 5:00 PM and coming back in the next\n> day at 9:00 AM, well past the 12 hour timeout.\n> \n> Is there any way to see the current timeout value? Is it a rolling\n> timeout (i.e. any git action resets the timeout)?\n\nIt's the \"rolling\" thing, though the source is a bit subtle. The\ncredential-cache helper sets an absolute expiration when the value is\nstored, and it doesn't update it on a \"get\" request.\n\nHowever, Git's interaction with the helpers is generally:\n\n  - when we need a credential ask for one\n\n  - when a credential is rejected by a server, tell helpers to erase it\n\n  - when a credential is accepted by a server, tell helpers to store it\n\nAnd it's that last one that provides the rolling timeout, because we do\nit even if the credential came from a helper in the first place!\n\nI actually wrote a patch long ago to switch this behavior:\n\n  https://lore.kernel.org/git/20120407033417.GA13914@sigill.intra.peff.net/\n\nBut it turned out some people actually rely on it. :)\n\nThere's some discussion in that thread about paths forward, and I think\nI even played around with it back then. But then it sat on my todo list,\nand now it has been 9 years, so I don't remember if there were good\nreasons not to push it forward, or if I simply never got around to it (I\nsuspect the latter; nobody had a pressing use case that was solved by\navoiding the rolling timeouts, it just seemed to me to be a bit less\nsurprising). I'd be happy if somebody wanted to revisit the topic.\n\n(To your other question, \"is there a way to see the timeout value\", the\nanswer is \"not really, without running it under gdb\". I wouldn't be\nopposed to adding more diagnostic output to the daemon. But you can also\nsee some of what's going on by setting GIT_TRACE=1 in the environment,\nwhich will show the extra \"store\" operation being done by Git).\n\n-Peff\n"},{"id":"418688","messageId":"CAP8UukgvnxtMLa00jNn-T_sATNMz2qDo6bCVBnWhqqLmqA42Xw@mail.gmail.com","threadId":"55174","inReplyTo":"YC/vqJBSnDHoLIdJ@coredump.intra.peff.net","subject":"Re: git credential cache timeout questions","fromName":"John Ratliff","fromEmail":"john@technoplaza.net","sentAt":"2021-03-10T15:41:56Z","receivedAt":"2021-03-10T15:42:59Z","isPatch":false,"sender":{"key":"john@technoplaza.net","avatar":null},"body":"Thanks. Now that I know it is a rolling timeout, I was able to narrow\nmy search for anything that might be causing the timer to extend.\n\nThere is a git helper program I use that has a background refresh that\nI think I must leave open overnight sometimes. I think this was\ncausing my timeout to be extended. I disabled the background refresh\ntask and the timeout seems to be expiring like I expect now.\n\n--John\n\nOn Fri, Feb 19, 2021 at 12:04 PM Jeff King <peff@peff.net> wrote:\n>\n> On Fri, Feb 19, 2021 at 10:46:48AM -0500, John Ratliff wrote:\n>\n> > I have configured my git to cache my credentials for 12 hours using\n> > this section in my .gitconfig\n> >\n> > [credential \"https://mygithub.example.edu\"]\n> >     username = myuser\n> >     helper = cache --timeout 43200\n> >\n> > However, the credentials don’t always seem to expire after 12 hours.\n> > Sometimes I come back the next morning and the credentials still work.\n> > This is generally after leaving at 5:00 PM and coming back in the next\n> > day at 9:00 AM, well past the 12 hour timeout.\n> >\n> > Is there any way to see the current timeout value? Is it a rolling\n> > timeout (i.e. any git action resets the timeout)?\n>\n> It's the \"rolling\" thing, though the source is a bit subtle. The\n> credential-cache helper sets an absolute expiration when the value is\n> stored, and it doesn't update it on a \"get\" request.\n>\n> However, Git's interaction with the helpers is generally:\n>\n>   - when we need a credential ask for one\n>\n>   - when a credential is rejected by a server, tell helpers to erase it\n>\n>   - when a credential is accepted by a server, tell helpers to store it\n>\n> And it's that last one that provides the rolling timeout, because we do\n> it even if the credential came from a helper in the first place!\n>\n> I actually wrote a patch long ago to switch this behavior:\n>\n>   https://lore.kernel.org/git/20120407033417.GA13914@sigill.intra.peff.net/\n>\n> But it turned out some people actually rely on it. :)\n>\n> There's some discussion in that thread about paths forward, and I think\n> I even played around with it back then. But then it sat on my todo list,\n> and now it has been 9 years, so I don't remember if there were good\n> reasons not to push it forward, or if I simply never got around to it (I\n> suspect the latter; nobody had a pressing use case that was solved by\n> avoiding the rolling timeouts, it just seemed to me to be a bit less\n> surprising). I'd be happy if somebody wanted to revisit the topic.\n>\n> (To your other question, \"is there a way to see the timeout value\", the\n> answer is \"not really, without running it under gdb\". I wouldn't be\n> opposed to adding more diagnostic output to the daemon. But you can also\n> see some of what's going on by setting GIT_TRACE=1 in the environment,\n> which will show the extra \"store\" operation being done by Git).\n>\n> -Peff\n"}]}