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
