Push ?

[Dan White <d_...@icloud.com>]

Is is possible to push a checkout or update from a subversion server to a remote client ?

Red Hat Enterprise Linux 5 / CentOS 5 environment.

Re: Push ?

[Branko Čibej <br...@wandisco.com>]

On 15.09.2013 01:22, Dan White wrote:
> Is is possible to push a checkout or update from a subversion server to a remote client ?

You could try svnpubsub:

http://svn.apache.org/viewvc/subversion/trunk/tools/server-side/svnpubsub/

It includes a client implementation called "svnwcsub" which does more or
less what you need. Svnpubsub is included in the Subversion 1.8.x source
tarballs.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com

RE: Push ?

[Bob Archer <Bo...@amsi.com>]

> Guten Tag Dan White,
> am Sonntag, 15. September 2013 um 17:32 schrieben Sie:
> 
> > Searching for a solution found one possibility: Check out a copy on
> > the subversion server and then rsync to the final client destination.
> 
> How is rsync more secure than accessing the client using SSH and use svn
> update? SSH has some options to limit access and possibilities.
> For example ForceCommand sounds interesting:
> 
> http://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-
> port-forwarding
> 
> > I was hoping to find a one-step solution rather than a two step.
> 
> How about polling on the client? Issueing a svn update every some seconds
> shouldn't hurt client and server much.
> 

This is what CI servers do... Cruise Control, Team City, Jenkins, etc.

BOb

Re: Push ?

[Thorsten Schöning <ts...@am-soft.de>]

Guten Tag Dan White,
am Sonntag, 15. September 2013 um 17:32 schrieben Sie:

> Searching for a solution found one possibility: Check out a copy on
> the subversion server and then rsync to the final client destination.

How is rsync more secure than accessing the client using SSH and use
svn update? SSH has some options to limit access and possibilities.
For example ForceCommand sounds interesting:

http://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-port-forwarding

> I was hoping to find a one-step solution rather than a two step.

How about polling on the client? Issueing a svn update every some
seconds shouldn't hurt client and server much.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Push ?

[Nico Kadel-Garcia <nk...@gmail.com>]

> First, it is kind of foolish to assume that anyone with an
unrestricted ssh login doesn't have complete access to all the data
that account can read (or reach from either side of the connection),
but also note that this is the opposite case, where the connection
origin and tunnel destination are on the 'less secure' side and the
controlling keys are also outside.

Oh, Les, this clown was doing both and all and simply treating security as
"something that stops me from getting my important work done". It's
understandable: blindly applied policies do encourage people to simply work
around them, and encourage people to work around them. Blindly applied
workarounds are a similar problem. Simply setting up SSH tunnels, without
some serious thought about how to keep it off the radar of the script
kiddies, or keep it tied to Subversion repository mirroring alone and not
abused for other purposes is one that needs serious thought.

For example, a quick review of SSH daemon configurations allows one to set
up an SSH daemon that is dedicated to Subversion SSH tunnels, with a
restricted and forced specific SSH public key matched to the daemon that
can only be used by the specific tunnel user, tied to the Subversion
server's restricted access. But that takes significant extra work, and root
privileges to start if the daemon is going to run on low numbered ports,
and even SELinux considerations if that's enabled on either end.

Re: Push ?

[Les Mikesell <le...@gmail.com>]

On Tue, Sep 17, 2013 at 7:11 AM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
>>>
>> There is always the trick of ssh-ing a command from inside the
>> firewall to the DMZ box that (a) sets up port-forwarding and (b) runs
>> the svn command as though the repo is on localhost.  Technically, and
>> from the firewall's point of view, the connection is established
>> outbound.
>
>
> This is also a firing offense in many environments.

Yes, I can understand institutions and security policies that blindly
outlaw tunnels, but note that in this case it goes the 'right'
direction.- that is the control and connection comes from the 'more
secure' side and the tunnel is just because the program that needs to
run won't make its own connection in the direction you need.

> I once had a chief
> developer, with various root SSH key access, running just such tunnels to
> and from his home machine, tunnels that I happened to notice. He was also
> using non-passphrase protected SSH keys, and had *built* the previous
> version of Subversion in use at that company. Given the secure data he had
> access to this way, from offsite, it caused a serous scandal behind closed
> doors, (And I replaced that Subversion with a source controlled one, owned
> by "root", instead of the one owned by him individually!)

First, it is kind of foolish to assume that anyone with an
unrestricted ssh login doesn't have complete access to all the data
that account can read (or reach from either side of the connection),
but also note that this is the opposite case, where the connection
origin and tunnel destination are on the 'less secure' side and the
controlling keys are also outside.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Push ?

[Nico Kadel-Garcia <nk...@gmail.com>]

On Mon, Sep 16, 2013 at 4:51 PM, Les Mikesell <le...@gmail.com> wrote:

> On Mon, Sep 16, 2013 at 2:53 PM, Dan White <d_...@icloud.com> wrote:
> > The described solution is one we already use within our network space,
> but
> > Security will not allow a connection from DMZ to the internal SVN server.
> > It violates the whole purpose of having a DMZ in the first place.
> >
>
> There is always the trick of ssh-ing a command from inside the
> firewall to the DMZ box that (a) sets up port-forwarding and (b) runs
> the svn command as though the repo is on localhost.  Technically, and
> from the firewall's point of view, the connection is established
> outbound.


This is also a firing offense in many environments. I once had a chief
developer, with various root SSH key access, running just such tunnels to
and from his home machine, tunnels that I happened to notice. He was also
using non-passphrase protected SSH keys, and had *built* the previous
version of Subversion in use at that company. Given the secure data he had
access to this way, from offsite, it caused a serous scandal behind closed
doors, (And I replaced that Subversion with a source controlled one, owned
by "root", instead of the one owned by him individually!)

Re: Push ?

[Les Mikesell <le...@gmail.com>]

On Mon, Sep 16, 2013 at 2:53 PM, Dan White <d_...@icloud.com> wrote:
> The described solution is one we already use within our network space, but
> Security will not allow a connection from DMZ to the internal SVN server.
> It violates the whole purpose of having a DMZ in the first place.
>

There is always the trick of ssh-ing a command from inside the
firewall to the DMZ box that (a) sets up port-forwarding and (b) runs
the svn command as though the repo is on localhost.  Technically, and
from the firewall's point of view, the connection is established
outbound.

-- 
   Les Mikesell
     lesmikesell@gmail.com

Re: Push ?

[Dan White <d_...@icloud.com>]

The described solution is one we already use within our network space, but Security will not allow a connection from DMZ to the internal SVN server.
It violates the whole purpose of having a DMZ in the first place.

“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.”  (Bill Waterson: Calvin & Hobbes)


On Sep 16, 2013, at 12:19 PM, Thomas Harold <th...@nybeta.com> wrote:

> On 9/15/2013 11:32 AM, Dan White wrote:
>> The issue is that the client end of the transaction is in a DMZ
>> A connection from a DMZ to one’s internal network is a very high
>> security risk. What I was hoping for was a way to define a very
>> specific connection from the Subversion server to the DMZ client
>> (push). This is considered to be a much lower security risk.
>
> One way to handle this is to use SSH to access the specific SVN repository.
>
> 1. Use no-password SSH public-key pair that the DMZ host can punch
> through to the SSH port on the internal SVN server. (Naturally, SSH
> should be set to dis-allow root login, and only allow public-key
> authentication.)
>
> - If you can't change everyone over to using public keys and disabling
> password based authentication for SSH, then you should run a 2nd SSHD
> process on a different port and have that only allow specific accounts
> to login and require public-key authentication. Then you can setup your
> DMZ -> SVN server firewall to only allow access to the SVN SSH alternate
> port from the DMZ.
>
> 2. Give the SSH account read-only access to the SVN repo that it needs
>
> 3. Lock down what the SSH account can do to just:
>
> command="/usr/bin/svnserve -t -r
> /var/svn",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding ssh-rsa
> ...
>
> Since the account will have very limited permissions on the SVN machine
> (read-only access), there's not a whole lot that someone could do with
> the account. Plus the use of the command= line means they'd have to
> figure out a way to escape the svnserve program in order to get a
> command-line on the SVN machine.

Re: Push ?

[Thomas Harold <th...@nybeta.com>]

On 9/15/2013 11:32 AM, Dan White wrote:
> The issue is that the client end of the transaction is in a DMZ
>
> A connection from a DMZ to one’s internal network is a very high
> security risk. What I was hoping for was a way to define a very
> specific connection from the Subversion server to the DMZ client
> (push). This is considered to be a much lower security risk.

One way to handle this is to use SSH to access the specific SVN repository.

1. Use no-password SSH public-key pair that the DMZ host can punch 
through to the SSH port on the internal SVN server.  (Naturally, SSH 
should be set to dis-allow root login, and only allow public-key 
authentication.)

- If you can't change everyone over to using public keys and disabling 
password based authentication for SSH, then you should run a 2nd SSHD 
process on a different port and have that only allow specific accounts 
to login and require public-key authentication.  Then you can setup your 
DMZ -> SVN server firewall to only allow access to the SVN SSH alternate 
port from the DMZ.

2. Give the SSH account read-only access to the SVN repo that it needs

3. Lock down what the SSH account can do to just:

command="/usr/bin/svnserve -t -r 
/var/svn",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding ssh-rsa 
...

Since the account will have very limited permissions on the SVN machine 
(read-only access), there's not a whole lot that someone could do with 
the account.  Plus the use of the command= line means they'd have to 
figure out a way to escape the svnserve program in order to get a 
command-line on the SVN machine.

Re: Push ?

[Dan White <d_...@icloud.com>]

The issue is that the client end of the transaction is in a DMZ

A connection from a DMZ to one’s internal network is a very high security risk.
What I was hoping for was a way to define a very specific connection from the Subversion server to the DMZ client (push).
This is considered to be a much lower security risk.

Searching for a solution found one possibility: Check out a copy on the subversion server and then rsync to the final client destination.

I was hoping to find a one-step solution rather than a two step.

Other considerations include using svnsync to create a copy in the DMZ, but that has its own security concerns.

Sadly, this is not a simple problem.

On Sep 15, 2013, at 6:21 AM, Thorsten Schöning wrote:

> Guten Tag Dan White,
> am Sonntag, 15. September 2013 um 01:22 schrieben Sie:
> 
>> Is is possible to push a checkout or update from a subversion server to a remote client ?
> 
> As said, there's no such mechanism in Subversion, but if you describe
> your problem more detailed, one can suggest workarounds. For example
> it shouldn't be a problem to login using ssh and initiate a client
> side update.

Re: Push ?

[Thorsten Schöning <ts...@am-soft.de>]

Guten Tag Dan White,
am Sonntag, 15. September 2013 um 01:22 schrieben Sie:

> Is is possible to push a checkout or update from a subversion server to a remote client ?

As said, there's no such mechanism in Subversion, but if you describe
your problem more detailed, one can suggest workarounds. For example
it shouldn't be a problem to login using ssh and initiate a client
side update.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning       E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme      http://www.AM-SoFT.de/

Telefon...........05151-  9468- 55
Fax...............05151-  9468- 88
Mobil..............0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: Push ?

[Ryan Schmidt <su...@ryandesign.com>]

On Sep 14, 2013, at 18:22, Dan White wrote:

> Is is possible to push a checkout or update from a subversion server to a remote client ?

Nope, clients must initiate updates. Servers don't keep any record of who checked out or updated what (expect possibly in logfiles).