Re: Enforce encryption client-side

[Daniel Shahaf]

Nils-Johan Andreasson wrote on Fri, May 07, 2021 at 15:41:47 +0200:
> On Thu, May 6, 2021 at 3:24 PM Daniel Shahaf  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).
> 
> 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  '.
> The command defined in subversion config under [tunnels] is called as:
>   svnserve -t
⋮
> 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?

No.  You _could_ inline the wrapper script into the configuration, along
these lines:
.
[tunnels]
nc = $SUBVERSION_TUNNEL_NC sh -c 'nc ${1%:*} ${1##*:}' :
.
but other than that, what you did is exactly what I had in mind.  Sorry
it wasn't clear the first time.

BTW, to support the default port:
.
nc = $SUBVERSION_TUNNEL_NC sh -c 'case $1 in *:*) ;; *) set -- ${1}:3690;; 
esac && nc ${1%:*} ${1##*:}' :

I've committed a related clarification in https://svn.apache.org/r1889629.
Thanks for raising that.

The other approach I described was to define a tunnel such as
.
[tunnels]
bar = $BAR sh -c "nc lorem.bar.example 3690"
.
which can then be used as «svn+bar:///some/path» with an empty hostname
component.  I used to do this, for two reasons: it made the URLs
shorter, and it let me change the SSH jumphost centrally across all my
working copies.

> In any case, thanks a lot all for your helpful inputs and suggestions -
> made my day!

You're welcome.

Daniel

Re: Enforce encryption client-side

[Nils-Johan Andreasson]

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  '.
The command defined in subversion config under [tunnels] is called as:
  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  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).
>