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

Re: feature request

From
Shawn Pearce <spearce@spearce.org>
Date
Feb 19, 2013, 22:27 UTC
Message-ID
<CAJo=hJvmaj4Yn6ACDxQvnetfU+ay1hbfwsnCNN+tGG9MNoovkA@mail.gmail.com>
In-Reply-To
<20130218204511.GA27308@sigill.intra.peff.net>
On Mon, Feb 18, 2013 at 12:45 PM, Jeff King <peff@peff.net> wrote:
>
> The thing that makes 2FA usable in the web browser setting is that you
> authenticate only occasionally, and get a token (i.e., a cookie) from
> the server that lets you have a longer session without re-authenticating.

Right, otherwise you spend all day typing in your credentials and syncing with the 2nd factor device.

Show 7 quoted lines
> I suspect a usable 2FA scheme for http pushes would involve a special
> credential helper that did the 2FA auth to receive a cookie on the first
> use, cached the cookie, and then provided it for subsequent auth
> requests. That would not necessarily involve changing git, but it would
> mean writing the appropriate helper (and the server side to match). I
> seem to recall Shawn mentioning that Google does something like this
> internally, but I don't know the details[1].
...
Show 6 quoted lines
> [1] I don't know if Google's system is based on the Google Authenticator
>     system. But it would be great if there could be an open,
>     standards-based system for doing 2FA+cookie authentication like
>     this. I'd hate to have "the GitHub credential helper" and "the
>     Google credential helper". I'm not well-versed enough in the area to
>     know what's feasible and what the standards are.

Yes, it is based on the Google Authenticator system, but that's not relevant to how Git works with it. :-)

We have a special "git-remote-sso" helper we install onto corporate workstations. This allows Git to understand the "sso://" protocol. git-remote-sso is a small application that:

- reads the URL from the command line,
- makes sure a Netscape style cookies file has a current cookie for
the named host,
   - acquires or updates cookie if necessary
- rewrites the URL to be https://
- execs `git -c http.cookiefile=$cookiefile remote-https $URL`

The way 2FA works is the user authenticates to a special internal SSO management point in their web browser once per period (I decline to say how often but its tolerable). Users typically are presented this SSO page anyway by other applications they visit, or they bookmark the main entry point. A Chrome or Firefox extension has been installed and authorized to steal cookies from this host. The extension writes the user's cookie to a local file on disk. Our git-remote-sso tool uses this cookie file to setup per-host cookies on demand within the authentication period.

Horrifically hacky. It would be nice if this was more integrated into Git itself, where the cookies could be acquired/refreshed through the credential helper system rather than wrapping git-remote-https with a magical URL. I am a fan of the way our extension manages to get the token conveyed automatically for me. Much easier than the OAuth flows[2], but harder to replicate in the wild. Our IT group makes sure the extension is installed on workstations as part of the base OS image.

[2] https://developers.google.com/storage/docs/gsutil_install#authenticate
Previous: Drew Northup
Message 5 of 5 in “feature request”
  1. Jay TownsendFeb 18, 2013
  2. James NylenFeb 18, 2013
  3. Jeff KingFeb 18, 2013
  4. Drew NorthupFeb 19, 2013
  5. Shawn PearceFeb 19, 2013

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.