Clever! The library does indeed only consider svn:// insecure and it does not validate the scheme other than that. So, this would work (although it of course requires some configuration in the places I want to use it, but I can live with that).
It took me some reading and fiddling though to get this to work completely. nc wants parameters as 'nc <hostname> <port>'. The command defined in subversion config under [tunnels] is called as: <command> <hostname> svnserve -t This will make nc treat "svnserve" as the port and therefore refuse it. Specifying hostname as hostname:port will not work either. For now, I wrote a small bash script "nc-forwarder" with the following contents: #!/bin/bash nc $(echo $1 | sed 's/:/ /g') Made it executable chmod +x nc-forwarder Put it in the config: [tunnels] nc = /home/xx/.subversion/nc-forwarder When run it simply executes nc with the first argument. In my case I use a custom port so it replaces the colon with space which works great with nc. If no custom port is used you can always add :3690 (or enhance the bash script further to set that as default port). All other arguments (svnserve -t) are at the same time scrapped. Which in the end makes a command such as this work like a charm: svn info svn+nc://hostname:3699 Maybe you had a simpler way of achieving the same in mind? In any case, thanks a lot all for your helpful inputs and suggestions - made my day! Best regards, Nils-Johan On Thu, May 6, 2021 at 3:24 PM Daniel Shahaf <d...@daniel.shahaf.name> wrote: > Nils-Johan Andreasson wrote on Thu, May 06, 2021 at 14:48:01 +0200: > > I have indeed considered svn+ssh but there are other details involved > which > > makes me prefer to stay with svnserve and svn:// if possible. > > Does your library consider svn+foo:// secure? If so, you can define an > svn+foo:// scheme that simply wraps plain old TCP sockets. You have two > options for that, even: either «svn+nc://hostname/path» that uses nc(1) > or socat(1) to wrap a plain TCP socket, or a scheme that hardcodes > a specific hostname, that you then use in URLs whose hostname component is > ignored (can actually be left empty). >
