git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git credential cache timeout questions

From
JRJohn Ratliff <john@technoplaza.net>
Date
Mar 10, 2021, 15:41 UTC
Message-ID
<CAP8UukgvnxtMLa00jNn-T_sATNMz2qDo6bCVBnWhqqLmqA42Xw@mail.gmail.com>
In-Reply-To
<YC/vqJBSnDHoLIdJ@coredump.intra.peff.net>

Thanks. Now that I know it is a rolling timeout, I was able to narrow my search for anything that might be causing the timer to extend.

There is a git helper program I use that has a background refresh that I think I must leave open overnight sometimes. I think this was causing my timeout to be extended. I disabled the background refresh task and the timeout seems to be expiring like I expect now.

--John
On Fri, Feb 19, 2021 at 12:04 PM Jeff King <peff@peff.net> wrote:
Show 54 quoted lines
>
> On Fri, Feb 19, 2021 at 10:46:48AM -0500, John Ratliff wrote:
>
> > I have configured my git to cache my credentials for 12 hours using
> > this section in my .gitconfig
> >
> > [credential "https://mygithub.example.edu"]
> >     username = myuser
> >     helper = cache --timeout 43200
> >
> > However, the credentials don’t always seem to expire after 12 hours.
> > Sometimes I come back the next morning and the credentials still work.
> > This is generally after leaving at 5:00 PM and coming back in the next
> > day at 9:00 AM, well past the 12 hour timeout.
> >
> > Is there any way to see the current timeout value? Is it a rolling
> > timeout (i.e. any git action resets the timeout)?
>
> It's the "rolling" thing, though the source is a bit subtle. The
> credential-cache helper sets an absolute expiration when the value is
> stored, and it doesn't update it on a "get" request.
>
> However, Git's interaction with the helpers is generally:
>
>   - when we need a credential ask for one
>
>   - when a credential is rejected by a server, tell helpers to erase it
>
>   - when a credential is accepted by a server, tell helpers to store it
>
> And it's that last one that provides the rolling timeout, because we do
> it even if the credential came from a helper in the first place!
>
> I actually wrote a patch long ago to switch this behavior:
>
>   https://lore.kernel.org/git/20120407033417.GA13914@sigill.intra.peff.net/
>
> But it turned out some people actually rely on it. :)
>
> There's some discussion in that thread about paths forward, and I think
> I even played around with it back then. But then it sat on my todo list,
> and now it has been 9 years, so I don't remember if there were good
> reasons not to push it forward, or if I simply never got around to it (I
> suspect the latter; nobody had a pressing use case that was solved by
> avoiding the rolling timeouts, it just seemed to me to be a bit less
> surprising). I'd be happy if somebody wanted to revisit the topic.
>
> (To your other question, "is there a way to see the timeout value", the
> answer is "not really, without running it under gdb". I wouldn't be
> opposed to adding more diagnostic output to the daemon. But you can also
> see some of what's going on by setting GIT_TRACE=1 in the environment,
> which will show the extra "store" operation being done by Git).
>
> -Peff
Previous: Jeff King
Message 3 of 3 in “git credential cache timeout questions”
  1. John RatliffFeb 19, 2021
  2. Jeff KingFeb 19, 2021
  3. John RatliffMar 10, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.