Subversion Authorization without authz
Hi all, I was wondering what is required to implement an alternative authorization mechanism (aside from the authz approach) possibly using MySQL or another database? I'm aware of setting up Subversion with Apache using mod authz_svn_db. http://web.fhnw.ch/technik/projekte/i/fruehling09/BieliHaller/downloads/downloads/Dokumente/PDF/AdminGuide.pdf but I'm interested in whether anybody has done this without Apache via some Subversion code changes? Many thanks, Jon.
Re: Troubleshooting Gnome keyring
On Mon, Dec 17, 2012 at 8:17 PM, Aubrey Barnard wrote: > I am having trouble getting Subversion to work with the Gnome keyring and > would like some advice on how to troubleshoot the situation. At this point I > have tried everything I can find (Google, these archives), so I need to find > how/where things are failing. > > I am using the svn+ssh protocol to access a server within my organization. > Even with what I understand is the proper configuration, I am still prompted > for my SSH password and Subversion never mentions a keyring or asks for a > keyring password. The environment is RHEL 6, so I expected this to work > out-of-the-box with the default svn. More information is below. Subversion does not really do any authentication when you use SSH, so there are no credentials for it to cache and none of those settings come into play. When you use SSH, the authentication process is managed by your SSH client. I think most Unix users use something like ssh-agent to manage their keys and I believe there are flavors of that which interact with a GUI such as GNOME. -- Thanks Mark Phippard http://markphip.blogspot.com/
Semantics of locking a "revision"
Hello, if I co a working copy with -rREV with REV older than HEAD, I am able to get a lock on any file. But it seems to me, that the lock is never published to the server as no "svn info URL" shows an existing lock on the file on any working revision, while the lock is existing in my wc (displayed by svn status / info). So what is the purpose of having an isolated lock in my wc? Did I miss something? Best regards, J. Ruhe p.s. Using svn 1.7.6 (win32 cygwin client), svn 1.7.7 (debian server)
Re: Semantics of locking a "revision"
On Tue, Dec 18, 2012 at 05:14:18PM +, Julian Ruhe wrote: > Hello, > > if I co a working copy with -rREV with REV older than HEAD, I am able to get > a lock on any file. But it seems to me, that the lock is never published to > the server as no "svn info URL" shows an existing lock on the file on any > working revision, while the lock is existing in my wc (displayed by svn > status / info). > > So what is the purpose of having an isolated lock in my wc? Did I miss > something? > > Best regards, > J. Ruhe > > p.s. Using svn 1.7.6 (win32 cygwin client), svn 1.7.7 (debian server) With a 1.7.x build of Subversion, in a simple test over ra_local (i.e. a file:// URL) I get this: Updated to revision 1. $ svn lock alpha svn: warning: W160042: Lock failed: newer version of '/trunk/alpha' exists $ svn up -r2 Updating '.': At revision 2. $ svn lock alpha svn: warning: W160042: Lock failed: newer version of '/trunk/alpha' exists $ svn up -rHEAD Updating '.': Ualpha Updated to revision 3. $ svn lock alpha 'alpha' locked by user 'stsp'. So obviously I cannot reproduce the issue. Can you please provide more details? Are you sure the file you're trying to lock is out-of-date? Which repository access method are you using (http://, svn://, ...)?
Re: Troubleshooting Gnome keyring
On Tue, Dec 18, 2012 at 11:09 AM, Mark Phippard wrote: > On Mon, Dec 17, 2012 at 8:17 PM, Aubrey Barnard wrote: > >> I am having trouble getting Subversion to work with the Gnome keyring and >> would like some advice on how to troubleshoot the situation. At this point I >> have tried everything I can find (Google, these archives), so I need to find >> how/where things are failing. >> >> I am using the svn+ssh protocol to access a server within my organization. >> Even with what I understand is the proper configuration, I am still prompted >> for my SSH password and Subversion never mentions a keyring or asks for a >> keyring password. The environment is RHEL 6, so I expected this to work >> out-of-the-box with the default svn. More information is below. > > Subversion does not really do any authentication when you use SSH, so > there are no credentials for it to cache and none of those settings > come into play. > > When you use SSH, the authentication process is managed by your SSH > client. I think most Unix users use something like ssh-agent to > manage their keys and I believe there are flavors of that which > interact with a GUI such as GNOME. But the "gnome-keyring" is supposed to manage this for you with Gnome up and running. Aubry, which Subversion are you using? I've published, SRPM tools at https://github.com/nkadel/subversion-1.6.18-srpm which you may find useful to build a fully equipped Subveriosn 1.6.18, compatible with Red Hat's, but with all the latest features such as gnome-keyring support as much as can be activated with RHEL 5. Alternatively, jump to RHEL 6 or Scientific Linux 6, both of with have better support for such modern tools.
Re: Subversion Authorization without authz
On Tue, Dec 18, 2012 at 6:52 AM, Jonathan Holloway wrote: > Hi all, > > I was wondering what is required to implement an alternative authorization > mechanism (aside from the authz approach) possibly using MySQL or another > database? svn+ssh works pretty well, and avoids the "storing password in plain text for Linux clients" problem. Any authentication technology for HTTPS based access which links to a more central authentication system with stored passwords is at risk of users using the same password for other applications, such as email or login, and leaving their passwords stored in clear text in $HOME/.subversion/. > I'm aware of setting up Subversion with Apache using mod authz_svn_db. > > http://web.fhnw.ch/technik/projekte/i/fruehling09/BieliHaller/downloads/downloads/Dokumente/PDF/AdminGuide.pdf > > but I'm interested in whether anybody has done this without Apache via some > Subversion code changes? Possibly, but it suffers from the issues I just mentioned. Unless you have high confidence in local filesystem security, and can assure that passwords used in the LDAP or database are not used elsewhere, you face exactly this security issue. (Note that I'm really a broken record about this. Many Subversion users and admins have confidence in their local filesystems. Due to NFS home directories and offsite backups, I have no such confidence.)
