Den fre 23 maj 2025 kl 00:35 skrev Peter Balogh <pe...@svnplus.com>: > Hi, > > So basically the patch becomes this > I can't say I like the actual branch condition, but I'm open to > suggestions :) >
Hi, I have not studied the patches in detail but I'm not so sure if I like the idea of Serf special-casing / hardcoding a custom response reason. I feel it would be better to offloading this to Subversion since we control both ends there. Also, RFC7235 [1] require a 401 response to send a WWW-Authenticate header - I don't know if it would be possible to use this to send the challenge. The response could then be added as a header field. Would it be possible for the server to return a bearer token (= more or less the same as a Set-Cookie) that we could store client-side to include on future requests? Kind regards, Daniel Sahlberg [1] https://www.rfc-editor.org/rfc/rfc7235#section-3.1 > > Best regards, > Peter > > On 2025. 05. 21. 23:47, Peter Balogh wrote: > > Hi, > > > > Would my approach (especially the serf change) acceptable, if instead > > of 499, I rely on the 401 reason string from the status line? > > > > Best regards, > > Peter > > > > On 2025. 05. 19. 12:37, Greg Stein wrote: > >> Hi Peter, > >> > >> Apologies for not seeing this on the Subversion dev@ list when you > >> first brought it up. > >> > >> Generally speaking, 2FA solutions along this set of requirements, use > >> a "Bearer token" which is then placed into the Authorization: header. > >> (sometimes referred to as a Personal Access Token (PAT)). That token > >> is fetched out of band, placed into a config file, and then picked up > >> for authentication with the origin server. I've seen this pattern > >> used across many systems, and I would not like to see a custom 499 > >> HTTP response to (re)invent the wheel. Nor cookies. Just place the > >> token into the Authorization header. > >> > >> I believe there are four parts here: > >> 1. a cgi that gets placed on an svn server that can generate a bearer > >> token for an authenticated user (standard HTTP Basic/Digest, > >> according to whatever ACLs the server may want to use for access to > >> that cgi). The bearer token is placed into a sqlite database on the > >> svn server. > >> 2. the user provides the bearer token to the svn client, which is > >> saved into a new auth scheme in the svn config directories. > >> "svn.bearer", for example. > >> 3. a serf authentication API/mechanism to submit a Bearer token, and > >> svn will present the bearer token extracted from its config > >> 4. httpd grows a new "mod_auth_bearer" or "mod_auth_pat" ... and I > >> could also bet you that such exists, so the above parts could be > >> edited to match > >> > >> For the token used in this system, I would suggest Python's > >> "secrets.token_hex(20)" to generate a hex string of 40 > >> characters, which represents 160 bits for a token (which I believe > >> should be sufficient for this system; I'd think the CGI could simply > >> have a constant that local installations may want to edit). > >> > >> Cheers, > >> -g > >> > >> ps. for step 1, I imagine that the Apache Infra team would like to > >> implement a custom solution to generate the bearer token for its > >> deployment on ASF systems, but a CGI is a great mechanism for all > >> third parties and to demonstrate the minimum needs to construct such > >> tokens. > >> > >> > >> On Sun, May 18, 2025 at 4:18 PM Peter Balogh <pe...@svnplus.com> wrote: > >> > >> Hi, > >> > >> I'm moving this conversation from the subversion dev mailing list > >> for now > >> I'm working on adding 2FA to subversion > >> > >> I have a working PoC of this system, and I'd like to start > >> submitting patches. > >> The serf changes are attached, what is the process to get approval > >> for this? > >> > >> The patches, configs and scripts to make this work are publicly > >> available here: > >> https://pub.svnplus.com/repo/2fa/trunk > >> > >> The implementation uses a special 499 http response code to > >> request 2FA auth, I have a working server config that serves this > >> without any server side changes > >> https://pub.svnplus.com/repo/2fa/trunk/webdav.conf > >> > >> The system is running at https://2fa.svnplus.com/repo/2fa/trunk/, > >> and it works in the browser and the svn cli with the patches > >> applied, but the svn client does not yet save the cookie, so every > >> command needs a 2fa > >> > >> To access the demo system, use the username: user and password: pass > >> The 2FA QR code is displayed on the page > >> > >> Please let me know, what you think > >> > >> Best regards, > >> Peter > >> > >> On 2025. 04. 02. 9:25, Daniel Sahlberg wrote: > >>> Hi, > >>> > >>> Den mån 31 mars 2025 kl 13:09 skrev Peter Balogh > >>> <pe...@svnplus.com>: > >>> > >>> Hi, > >>> > >>> I'm working on a proof of concept to add multi factor > >>> authentication to > >>> subversion > >>> I have multiple directions, and I'd like to get some feedback > >>> from this > >>> group before I head down the wrong road > >>> Please let me know, if I should read up on any of these, I > >>> did not find > >>> any recent conversation about these topics > >>> > >>> > >>> I think this is a very interesting concept! > >>> > >>> > >>> 1. One option would be to extend the existing Basic auth with > >>> another > >>> challenge. This would support standard TOTP without external > >>> connections > >>> I couldn't find any standard way to communicating this > >>> through HTTP, my > >>> best solution would be to > >>> > >>> 1.A extend the 401 response with information that the system > >>> also needs > >>> a TOTP token > >>> I've only found the realm string I can use for this without > >>> modifying > >>> the serf library > >>> > >>> 1.B reject the username + password attempt with a different 401 > >>> This would have to be handled inside the serf library > >>> > >>> > >>> I don't see a problem modifying Serf if it is needed. Several of > >>> the Subversion committers are also Serf committers and we can > >>> help there. > >>> > >>> > >>> 2. Provide an external login path instead Basic auth. This > >>> would open up > >>> using oauth or similar external providers, but a web based > >>> provider > >>> could be run besides svn as well > >>> The server would respond with a 30X response, and the cmdline > >>> could > >>> print the url for the user to open, login and return to the > >>> terminal > >>> after authentication > >>> This would feel less native, but pretty common these days > >>> > >>> > >>> I like this idea - I guess this would open up to for example > >>> Microsoft Entra. > >>> > >>> Make sure to use the standard baton/callback method to > >>> communicate the redirect URL to the client. This way GUI clients > >>> (for example TortoiseSVN) can implement a more "native" solution > >>> to the redirect. > >>> > >>> > >>> All of the solutions above would result in a HTTP cookie that > >>> would be > >>> stored encrypted in the auth folder, and sent with every > >>> subsequent request > >>> > >>> > >>> See existing discussions about storing the basic auth password in > >>> the auth folder. On Windows, there are APIs to encrypt the > >>> password linked to the user profile. In general no such on Unix, > >>> but I assume it could be stored in Gnome Keyring/Kwallet/GPG-agent. > >>> > >>> > >>> Do you have any thoughts or preferences about this? > >>> Do you see any technical or security issue with these? > >>> > >>> > >>> I know very little about the technical details of authentication > >>> on the http level but I think it would be god to adhere to > >>> existing standards as much as possible instead of inventing > >>> something unique to Subversion. For example it would be good if > >>> this can be done across a forward/reverse proxy. > >>> > >>> If this feature is enabled on a server, it would be impossible to > >>> authenticate with an older client. Don't know if this is a > >>> compatibility concern or not, but I think this addition would > >>> warrant new releases. > >>> > >>> Kind regards, > >>> Daniel > >>>
