Sorry for the very late reply. This got buried. The issue still persists — and I disabled the mail filter that sorted away the answer so that I can respond more quickly next time …
Am Thu, 9 Jul 2026 17:20:04 +0000 schrieb Michael Osipov <[email protected]>: > On 2026/07/07 20:16:00 "Dr. Thomas Orgis via dev" wrote: > > if I'm wrong here with this possibly stupid end-user question … but I > > am trying to keep a setup with svnserve+sasl going, for > > low-infrastructure encrypted communication, where the world decided > > that DIGEST-MD5 is no good. I tried to enable SCRAM-* mechanisms in my > > sasl config for svn, but clients get an empty list of supported > > mechanisms unless I include DIGEST-MD5. […] > > I'm posting this here — as it seems rather obscure to want to do more > > than DIGEST-MD5, or svnserve at all, nowadays — in the hope that the > > subversion developers at least have had one test setup where this > > actually worked. Has the svnserve sasl code been tested with non-MD5 > > mechanisms? > I bet your university operates a KDC, if so you can simply use > Kerberos via SASL or via Apache with mod_auth_gssapi. The latter > works perfectly, the former should work, but I have abandoned > svnserve long time ago. Sure, there is an MS AD service that I very much want to stay clear of. I did mention 'low-infrastructure'. My whole point of running svnserve for our internal repositories is that it is of low complexity and has no further dependencies on other services. Integrating anything with the Kerberos stuff is a different path. If I went for the route of running svn via Apache, I can simply do TLS with plain HTTP auth, I guess. But running Apache just for subversion increases the involved software stack tremendously. It would still be preferrable to something depending on external authentication services; though I then do have the hassle of managing TLS certificates (TODO: I'm not quite sure right now how client-to-server trust works with sasl-encrypted svnserve). And, well … is it really sensible to install a web server stack if I only want to serve Subversion? It seems to be what everyone else does, though. You say that using Kerberos via SASL should work. I wanted to try to get away from DIGEST-MD5 by enabling some SCRAM mechanisms. Those _should_ work, too, but they don't for me. To recap: mech_list: SCRAM-SHA-512-PLUS SCRAM-SHA-256-PLUS SCRAM-SHA-512 SCRAM-SHA-256 SCRAM-SHA-1-PLUS SCRAM-SHA-1 < 2026/07/07 22:01:06.000763594 length=80 from=207 to=286 ( failure ( ( 170001 44:Could not obtain the list of SASL mechanisms 0: 0 ) ) ) While with DIGEST-MD5 in the mech_list, it is < 2026/07/07 21:59:19.000146895 length=42 from=207 to=248 ( success ( ( DIGEST-MD5 ) 8:myrealm ) ) I am not confident that the Kerberos binding would work only because it _should_ work;-) If nobody uses the feature, _should_ work, becomes doesn't work rather quickly … Is the message, then, that svnserve is just to be abandoned? Or at least the attempt to use it with encryption, since SASL seems to be dying, too? I'd be thankful for a clear message here from the Subversion project: Should I invest further time in getting SCRAM mechanisms to work with svnserve + SASL or is it a lost project to begin with? For me it was really nice to get a Subversion system set up just via svnserve, repo-local usernames and passwords and hierarchical permissions defined in a simple text file. My use-case involves kindof machine accounts (with stored plaintext password) where each server has a part of the repo where to read/write its configuration data. Admins can access the whole repo and merge around the tree to move features between systems. You can do this a lot more complex, organization-wide, but for our little island of HPC systems, it is perfect to have this self-contained. The security implications of having plaintext passwords discoverable in case of local exploits on a system are fine with us, as each system can then only access the configuration it already has, and attackers are welcomed to push modified commits that we then can analyze later, as the svn history is safe server-side. We do have more sensitive repos that are accessed by personal accounts only via svn+ssh. But there is no granular access control over parts of a repo that way, and I'm offering users a shell with svn on top. Not good for the use case described above. Svnserve fills a niche for us, but maybe that niche is too small and we have to move to Apache with WebDAV, which is a lot more complex beast? Alrighty then, Thomas -- Dr. Thomas Orgis HPC @ Universität Hamburg
