Subversion 1.6 on Ubuntu Server 11.x

2011-06-10 Thread Geoff Hoffman
I posted about this on the Ubuntu forums but thus far nobody has replied.

When SSH'd into the box and using svn operations, I'm getting the dastardly
warning about my password is going to get stored to disk unencrypted.

I read about Subversion 1.6 security
changes
.
I read about Subversion 1.6 on Ubuntu Server over at
superuser.com
.
I read about gnome-keyring over at
stackoverflow
.

I've been doing a lot of reading on it.

I have done the following:

* installed gnome-keyring

*edited my ~/.subversion/config to turn
password-stores = gnome-keyring

edited my ~/.subversion/servers to
store-passwords = yes
store-plaintext-passwords = no

Thing is, I'm not using any GUI so it's still not working. Should I try
encfs ?

I read another post about a tool from CollabNet called keyring_tool but I
don't have it on this system. Where do I get that? I've never run into these
issues before (new distro, new svn version).

Any additional insight would be very much appreciated.


RE: Subversion 1.6 on Ubuntu Server 11.x

2011-06-10 Thread Varnau, Steve (Neoview)

From: Geoff Hoffman [mailto:ghoff...@cardinalpath.com]
Sent: Friday, June 10, 2011 3:26 PM
To: users@subversion.apache.org
Subject: Subversion 1.6 on Ubuntu Server 11.x

I posted about this on the Ubuntu forums but thus far nobody has replied.

When SSH'd into the box and using svn operations, I'm getting the dastardly 
warning about my password is going to get stored to disk unencrypted.

I read about Subversion 1.6 security 
changes<http://blogs.collab.net/subversion/2009/07/subversion-16-security-improvements/>.
I read about Subversion 1.6 on Ubuntu Server over at 
superuser.com<http://superuser.com/questions/186575/whats-the-best-way-to-store-an-encrypted-svn-password-on-ubuntu-server>.
I read about gnome-keyring over at 
stackoverflow<http://stackoverflow.com/questions/3824513/svn-encrypted-password-store>.

I've been doing a lot of reading on it.

I have done the following:

* installed gnome-keyring

*edited my ~/.subversion/config to turn
password-stores = gnome-keyring

edited my ~/.subversion/servers to
store-passwords = yes
store-plaintext-passwords = no

Thing is, I'm not using any GUI so it's still not working. Should I try encfs ?

I read another post about a tool from CollabNet called keyring_tool but I don't 
have it on this system. Where do I get that? I've never run into these issues 
before (new distro, new svn version).

Any additional insight would be very much appreciated.

You also have to run the gnome-keyring-daemon. Most of the docs assume you do 
it from a GUI, but you don't have to. Just set up some shell login script to 
start one (per user) if it is not running, and re-use the same environment 
variable values if it is already running.

This site will give you some hints, but the exercise is left to the reader.
http://live.gnome.org/GnomeKeyring/RunningDaemon

You do need to initialize your keyring, which is what the Collabnet 
keyring_tool is for.

-Steve




Re: Subversion 1.6 on Ubuntu Server 11.x

2011-06-11 Thread Nico Kadel-Garcia
On Fri, Jun 10, 2011 at 6:26 PM, Geoff Hoffman
 wrote:
> I posted about this on the Ubuntu forums but thus far nobody has replied.
> When SSH'd into the box and using svn operations, I'm getting the dastardly
> warning about my password is going to get stored to disk unencrypted.
> I read about Subversion 1.6 security changes.
> I read about Subversion 1.6 on Ubuntu Server over at superuser.com.
> I read about gnome-keyring over at stackoverflow.
> I've been doing a lot of reading on it.
> I have done the following:
> * installed gnome-keyring
> *edited my ~/.subversion/config to turn
> password-stores = gnome-keyring
> edited my ~/.subversion/servers to
> store-passwords = yes
> store-plaintext-passwords = no
> Thing is, I'm not using any GUI so it's still not working. Should I try
> encfs ?
> I read another post about a tool from CollabNet called keyring_tool but I
> don't have it on this system. Where do I get that? I've never run into these
> issues before (new distro, new svn version).
> Any additional insight would be very much appreciated.

I have *never* gotten the gnome keyrings working well with Subversion.
I'm afraid there are a lot of subtly distinct implementations of the
necessary toolchain out therem abd the lot of them tend to be pretty
fragile.

Frankly, I find it more effective, and safer, to use SSH keys and a
key agent as necessary, with a key specifically dedicated to the SVN
access. This can be mandated with "SVN_SSH='ssh -l username -i
keyname'" to avoid using other keys.

The stored SSH public keys on the remote server can even be set to
restrict access to only svnserve tunneling, even to read-only access.
Coupled with the kind of single svn user account setup described in
passing in the "Red Book", it's a better security model than giving
all SVN clients shell access to the server.


Re: Subversion 1.6 on Ubuntu Server 11.x

2011-06-11 Thread Geoff Hoffman
On Sat, Jun 11, 2011 at 8:27 AM, Nico Kadel-Garcia  wrote:

> On Fri, Jun 10, 2011 at 6:26 PM, Geoff Hoffman
>  wrote:
> > I posted about this on the Ubuntu forums but thus far nobody has replied.
> > When SSH'd into the box and using svn operations, I'm getting the
> dastardly
> > warning about my password is going to get stored to disk unencrypted.
> > I read about Subversion 1.6 security changes.
> > I read about Subversion 1.6 on Ubuntu Server over at superuser.com.
> > I read about gnome-keyring over at stackoverflow.
> > I've been doing a lot of reading on it.
> > I have done the following:
> > * installed gnome-keyring
> > *edited my ~/.subversion/config to turn
> > password-stores = gnome-keyring
> > edited my ~/.subversion/servers to
> > store-passwords = yes
> > store-plaintext-passwords = no
> > Thing is, I'm not using any GUI so it's still not working. Should I try
> > encfs ?
> > I read another post about a tool from CollabNet called keyring_tool but I
> > don't have it on this system. Where do I get that? I've never run into
> these
> > issues before (new distro, new svn version).
> > Any additional insight would be very much appreciated.
>
> I have *never* gotten the gnome keyrings working well with Subversion.
> I'm afraid there are a lot of subtly distinct implementations of the
> necessary toolchain out therem abd the lot of them tend to be pretty
> fragile.
>
>
Hmm.



> Frankly, I find it more effective, and safer, to use SSH keys and a
> key agent as necessary, with a key specifically dedicated to the SVN
> access. This can be mandated with "SVN_SSH='ssh -l username -i
> keyname'" to avoid using other keys.
>


I don't mind doing this, but is this something that goes in .bash_profile?

And would I then use svn+ssh://localhost/svn/repo/etc
instead of http://localhost/svn/repo/etc?





> The stored SSH public keys on the remote server can even be set to
> restrict access to only svnserve tunneling, even to read-only access.
> Coupled with the kind of single svn user account setup described in
> passing in the "Red Book", it's a better security model than giving
> all SVN clients shell access to the server.
>


Re: Subversion 1.6 on Ubuntu Server 11.x

2011-06-11 Thread Nico Kadel-Garcia
On Sat, Jun 11, 2011 at 12:57 PM, Geoff Hoffman
 wrote:

>> Frankly, I find it more effective, and safer, to use SSH keys and a
>> key agent as necessary, with a key specifically dedicated to the SVN
>> access. This can be mandated with "SVN_SSH='ssh -l username -i
>> keyname'" to avoid using other keys.
>
>
> I don't mind doing this, but is this something that goes in .bash_profile?
> And would I then use svn+ssh://localhost/svn/repo/etc
> instead of http://localhost/svn/repo/etc?

Depends on your shell. .bashrc is good on Linux boxes with the default
shell of "bash". It's especially useful to configure when sudo'ing to
root environments, using hte "$SUDO_USER" setting. If willing to take
the thought out risks, one can even enable sudo to propagate the
"SVN_SSH" and "SSH_AUTH_SOCK" environment variables for just such
usage. This makes committing changes as a root user noticeably easier
and safer.

I still run into people who prefer tcsh or zsh or ksh, so the exact
implementation is sensitive.