Thanks for excellent input! Unfortunately this external library is being very widely used and is not shipped with svn included. Rather it relies on being able to use svn if detected as installed on the system, so simply waiting for a new release wouldn't be an option to make a library-wide change.
The only other work-around I can come to think of would be if there is a way to probe whether a server uses/requires encryption for communication. Let's say I access svn://hostname/repository Is there a way (command) to remotely determine if the svn server behind 'hostname' has sasl enabled/uses encryption/enforces a min_ssf >= 128? Preferably without having to send any authentication credentials (to not risk sending anything in clear text). If so, an initialization step could hopefully be added which determines whether the source is deemed to be secure to access or not. I have indeed considered svn+ssh but there are other details involved which makes me prefer to stay with svnserve and svn:// if possible. Best regards, Nils-Johan On Thu, May 6, 2021 at 1:52 PM Stefan Sperling <s...@elego.de> wrote: > On Thu, May 06, 2021 at 01:03:28PM +0200, Nils-Johan Andreasson wrote: > > Thanks Stefan for your response and pointers! > > > > There is no doubt my connections are already encrypted. > > The issue is that the external library I'm referring to supports > specifying > > paths to source code using multiple protocols, e.g. svn:// (but also > > https://, http://, git://, ftp:// etc) and any svn:// source is > generally > > considered insecure, just like http:// (but not for example https://). > It > > is not verified in any way if that's actually the case, it's just based > on > > the scheme prefix svn:// > > > > So, what I'm looking for is a way to ensure an svn client command is only > > allowed to execute if using an encrypted transport. E.g. something like: > > svn --enforce-encryption checkout svn://hostname/repository > > svn --min-encryption 128 checkout svn://hostname/repository > > (or --disallow-unencrypted-transport, --require-sasl etc) > > > > Using something like that I can hopefully convince the library maintainer > > to enable this flag by default and then consider an svn:// source secure > by > > default (as connection would otherwise not succeed). > > > > I understand your point with that as long as "use-sasl = true" is > > configured on the server, the connection would abort if the client cannot > > communicate securely. However, this means that if this external library > is > > pointed to a svn:// source with "use-sasl = false" the connection would > > succeed, which is what I'm trying to prevent here to guarantee no > > unencrypted connections are made. > > > > Hope my point came through better this time? > > Yes. It seems indeed impossible to enforce a min_sff parameter other than > zero on the client side at present, which is an unfortunate omission. > I am sure there is no technical reason which would prevent this from > becoming configurable. > > If you or the third-party library maintainer are compiling your own > client binaries, the easy way to fix this would be to set min_ssf here: > > https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_svn/cyrus_auth.c?view=markup#l276 > > When adding this an official Subversion feature, I would suggest to > expose the SASL configuration parameters that svnserve is already using > as part of the client-side configuration, and then ensuring that these > parameters are applied after svn_ra_svn__default_secprops() is called. > Note that any configuration file parameters can also be specified on > the command line via the --config-option option so you won't necessarily > need to add a new separate option to the command line interface if this > feature gets implemented via config file options. > > I agree that this would be useful. However, someone would need to write > a patch, and then you would have to wait for a Subversion 1.15 release > to ship since this feature cannot be added in a 1.14 patch release due > to our compatibility promises (a clean roll-back from 1.14.Y to 1.14.X > without any configuration/parameter changes must remain possible). And > your third party library would need to upgrade to that version once it > has been released. All of this could take many months. > > Have you considered using svn+ssh instead? > > Cheers, > Stefan >
