{"thread":{"id":"59156","subject":"Git over HTTP; have flexible SASL authentication","startedAt":"2023-01-27T16:40:23Z","lastAt":"2023-02-06T22:08:11Z","messageCount":6,"participants":["Rick van Rein","Junio C Hamano","Jeff King","Matthew John Cheetham"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"471091","messageId":"20230127163434.GA784@openfortress.nl","threadId":"59156","inReplyTo":null,"subject":"Git over HTTP; have flexible SASL authentication","fromName":"Rick van Rein","fromEmail":"rick@openfortress.nl","sentAt":"2023-01-27T16:34:34Z","receivedAt":"2023-01-27T16:40:23Z","isPatch":false,"sender":{"key":"rick@openfortress.nl","avatar":null},"body":"Hello,\n\nGit providers are inventing proprietary extensions to HTTP authentication\nfor Git. It seems smarter to use SASL for this purpose, possibly allowing\nthe client a choice and authentication ringback to the client's own domain.\n\nI wrote an Internet Draft to allow just that, and we implemented it for\nApache, Nginx and FireFox. I would love to learn if this list considers\nit a sensible extensions to Git.\nhttps://datatracker.ietf.org/doc/html/draft-vanrein-httpauth-sasl\n\nIf you think this is useful, it would be wonderful to mention that on the\nHTTP WorkGroup list as well, because they are now considering HTTP-SASL\nfor adoption, a formal requisite to send \"Authorization: SASL\" headers.\nhttps://datatracker.ietf.org/wg/httpbis/about/\n\n\nThanks!\n\nRick van Rein\nInternetWide.org\n\n\nApache :- https://gitlab.com/arpa2/apachemod/-/tree/master/arpa2_sasl\n https://gitlab.com/arpa2/apachemod/-/tree/master/arpa2_diasasl\nNginx :- https://github.com/stef/ngx_http_auth_sasl_module\nFireFox :- https://gitlab.com/arpa2/http_sasl_client\n\n"},{"id":"471092","messageId":"xmqq7cx7aov7.fsf@gitster.g","threadId":"59156","inReplyTo":"20230127163434.GA784@openfortress.nl","subject":"Re: Git over HTTP; have flexible SASL authentication","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-01-27T17:06:36Z","receivedAt":"2023-01-27T17:08:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rick van Rein writes:\n\n> Git providers are inventing proprietary extensions to HTTP authentication\n> for Git. It seems smarter to use SASL for this purpose, possibly allowing\n> the client a choice and authentication ringback to the client's own domain.\n\nTo adopt things like this, the work to extend how to make extensible\nwhat is on WWW-Authenticate in the thread that contains this recent\nmessage https://lore.kernel.org/git/Y9LvFMzriAWUsS58@coredump.intra.peff.net/\nmay be relevant, perhaps?\n\n\n\n \n"},{"id":"471223","messageId":"Y9pL0D2WuKqqwB7X@coredump.intra.peff.net","threadId":"59156","inReplyTo":"xmqq7cx7aov7.fsf@gitster.g","subject":"Re: Git over HTTP; have flexible SASL authentication","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2023-02-01T11:24:00Z","receivedAt":"2023-02-01T11:24:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 27, 2023 at 09:06:36AM -0800, Junio C Hamano wrote:\n\n> Rick van Rein writes:\n> \n> > Git providers are inventing proprietary extensions to HTTP authentication\n> > for Git. It seems smarter to use SASL for this purpose, possibly allowing\n> > the client a choice and authentication ringback to the client's own domain.\n> \n> To adopt things like this, the work to extend how to make extensible\n> what is on WWW-Authenticate in the thread that contains this recent\n> message https://lore.kernel.org/git/Y9LvFMzriAWUsS58@coredump.intra.peff.net/\n> may be relevant, perhaps?\n\nIt's relevant, but I think there's a ways to go. That is just about\npassing WWW-Authenticate headers to helpers, which can then try to make\nsense of them. But Git would still only understand getting back a\nusername/password from the helper, and passing it along to curl. And\nhopefully we'd do it all through curl's SASL support, and not invent our\nown handling.\n\nI'm not sure what all that might might look like. I'm sure Matthew has\nprobably thought about it, so I'll let him say something more\nintelligent. :)\n\n-Peff\n"},{"id":"471262","messageId":"df7fb59a-ea74-d724-46dd-9a4c32779a30@github.com","threadId":"59156","inReplyTo":"Y9pL0D2WuKqqwB7X@coredump.intra.peff.net","subject":"Re: Git over HTTP; have flexible SASL authentication","fromName":"Matthew John Cheetham","fromEmail":"mjcheetham@github.com","sentAt":"2023-02-01T19:36:35Z","receivedAt":"2023-02-01T19:36:40Z","isPatch":false,"sender":{"key":"mjcheetham@github.com","avatar":null},"body":"On 2023-02-01 03:24, Jeff King wrote:\n\n> On Fri, Jan 27, 2023 at 09:06:36AM -0800, Junio C Hamano wrote:\n> \n>> Rick van Rein writes:\n>>\n>>> Git providers are inventing proprietary extensions to HTTP authentication\n>>> for Git. It seems smarter to use SASL for this purpose, possibly allowing\n>>> the client a choice and authentication ringback to the client's own domain.\n>>\n>> To adopt things like this, the work to extend how to make extensible\n>> what is on WWW-Authenticate in the thread that contains this recent\n>> message https://lore.kernel.org/git/Y9LvFMzriAWUsS58@coredump.intra.peff.net/\n>> may be relevant, perhaps?\n> \n> It's relevant, but I think there's a ways to go. That is just about\n> passing WWW-Authenticate headers to helpers, which can then try to make\n> sense of them. But Git would still only understand getting back a\n> username/password from the helper, and passing it along to curl. And\n> hopefully we'd do it all through curl's SASL support, and not invent our\n> own handling.\n> \n> I'm not sure what all that might might look like. I'm sure Matthew has\n> probably thought about it, so I'll let him say something more\n> intelligent. :)\n> \n> -Peff\n\nThese are the same thoughts I have on this. My patches only add support for the\nGit -> helper information flow, but don't make an attempt to change how helpers\ncan change Git's (curl's) response or behaviour.\n\nI had earlier iterations [1] of the patch that included the ability to change\nthe auth type/headers that curl would respond with based on the helper's output.\n\nFor example:\n\nprotocol=https\nhost=example.com\npassword=\nauthtype=bearer\n\n..would have Git configure curl to set CURLOPT_XOAUTH2_BEARER. However I pulled\nthese patches to keep the scope of that series smaller. It's still my plan to\nreintroduce such a patch series in the future.\n\nI'd imagine that Git could advertise to helpers that its version of curl supports\nSASL and a helper could enable or select this mechanism. Alternatively it could\njust be a Git config to enable it outright `credential.useSasl` or something.\nI haven't had chance to review SASL yet.\n\nThanks,\nMatthew\n\n\n[1] https://lore.kernel.org/git/230118.86k01kxfr7.gmgdl@evledraar.gmail.com/T/#m37fffe327593ca4f7bf32a205b7ee1d1ecd1ed46\n"},{"id":"471482","messageId":"20230204113408.GD21507@openfortress.nl","threadId":"59156","inReplyTo":"xmqq7cx7aov7.fsf@gitster.g","subject":"Re: Git over HTTP; have flexible SASL authentication","fromName":"Rick van Rein","fromEmail":"rick@openfortress.nl","sentAt":"2023-02-04T11:34:08Z","receivedAt":"2023-02-04T11:34:16Z","isPatch":false,"sender":{"key":"rick@openfortress.nl","avatar":null},"body":"Hi Junio,\n\n(Sorry for the late reply)\n\n> > Git providers are inventing proprietary extensions to HTTP authentication\n> > for Git. It seems smarter to use SASL for this purpose, possibly allowing\n> > the client a choice and authentication ringback to the client's own domain.\n> \n> To adopt things like this, the work to extend how to make extensible\n> what is on WWW-Authenticate in the thread that contains this recent\n> message https://lore.kernel.org/git/Y9LvFMzriAWUsS58@coredump.intra.peff.net/\n> may be relevant, perhaps?\n\nThis framework tries to get away from just Basic / Digest auth, but\nif I read correctly, it still assumes a single authentication step,\nwhich greatly reduces the strength of authentication.\n\nSASL assumes that the endpoints can hold state and progress through any\nchallenge/response exchange, in multiple steps if needed. This is not\ntrivial with stateless HTTP, but we fixed it with a \"s2s\" argument which\ncan hold the (datestamped, signed, encrypted) state on the server side.\n\nA few mechanisms that spring to mind as useful with Git over HTTP-SASL are\n\n - Kerberos / GSS-API, desirable for companies using its single sign-on\n _ FIDO, currently being added to SASL to benefit all protocols\n - OPAQUE, a very modern crypto, developed in IETF now\n - SXOVER-PLUS, our own work that calls back to a user's domain for login\n\t(so no server-stored credentials needed, only access control)\n\nI'm curious if this would indeed be considered an improvement to Git.\n\nCheers,\n -Rick\n"},{"id":"471616","messageId":"xmqqk00u4fco.fsf@gitster.g","threadId":"59156","inReplyTo":"20230204113408.GD21507@openfortress.nl","subject":"Re: Git over HTTP; have flexible SASL authentication","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2023-02-06T22:08:07Z","receivedAt":"2023-02-06T22:08:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Rick van Rein writes:\n\n> SASL assumes that the endpoints can hold state and progress through any\n> challenge/response exchange, in multiple steps if needed. This is not\n> trivial with stateless HTTP, but we fixed it with a \"s2s\" argument which\n> can hold the (datestamped, signed, encrypted) state on the server side.\n\nThat's nice to know, and its applications below do look useful, at\nleast to me.\n\n> A few mechanisms that spring to mind as useful with Git over HTTP-SASL are\n>\n> - Kerberos / GSS-API, desirable for companies using its single sign-on\n> _ FIDO, currently being added to SASL to benefit all protocols\n> - OPAQUE, a very modern crypto, developed in IETF now\n> - SXOVER-PLUS, our own work that calls back to a user's domain for login\n> \t(so no server-stored credentials needed, only access control)\n>\n> I'm curious if this would indeed be considered an improvement to Git.\n>\n> Cheers,\n> -Rick\n"}]}