Hi Junio, (Sorry for the late reply) > > Git providers are inventing proprietary extensions to HTTP authentication > > for Git. It seems smarter to use SASL for this purpose, possibly allowing > > the client a choice and authentication ringback to the client's own domain. > > To adopt things like this, the work to extend how to make extensible > what is on WWW-Authenticate in the thread that contains this recent > message https://lore.kernel.org/git/Y9LvFMzriAWUsS58@xxxxxxxxxxxxxxxxxxxxxxx/ > may be relevant, perhaps? This framework tries to get away from just Basic / Digest auth, but if I read correctly, it still assumes a single authentication step, which greatly reduces the strength of authentication. SASL assumes that the endpoints can hold state and progress through any challenge/response exchange, in multiple steps if needed. This is not trivial with stateless HTTP, but we fixed it with a "s2s" argument which can hold the (datestamped, signed, encrypted) state on the server side. A few mechanisms that spring to mind as useful with Git over HTTP-SASL are - Kerberos / GSS-API, desirable for companies using its single sign-on _ FIDO, currently being added to SASL to benefit all protocols - OPAQUE, a very modern crypto, developed in IETF now - SXOVER-PLUS, our own work that calls back to a user's domain for login (so no server-stored credentials needed, only access control) I'm curious if this would indeed be considered an improvement to Git. Cheers, -Rick
