Re: svn Farm
On Mon, Oct 18, 2010 at 12:56 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: It would be trivial to fork svn to lie and report that it only stored passwords encrypted, stick that forked client on my machine and hey presto, away I go storing my password in plaintext. If someone is *that* determined to shoot themselves in the foot, and willing to go to that much effort to do it, I don't think there's much you can do. They probably have their password on a sticky note on the bottom of their keyboard, too. ;) -- David Brodbeck System Administrator, Linguistics University of Washington
Re: svn Farm
On Fri, Oct 15, 2010 at 7:01 PM, Nico Kadel-Garcia nka...@gmail.com wrote: No. system_auth is still the NFS standard for internal use in both academic and professional environments. auth_dh has uses, but it doesn't help against any machine with allocated or cracked local root access. This isn't your local machine, it's the network wide home directory system, and there are plenty of them out there without even this step. I don't doubt that, but my point is in this particular scenario there are far bigger issues that render anything SVN does entirely moot. If I have root access to the filesystem, it doesn't matter what SSH does to try to encrypt the password, because I have full access to your account. I can just change your PATH to point to my trojaned SVN binary and grab your password that way, for example. There simply isn't any level of precaution sufficient to protect you from a rogue root user on a UNIX system. I'm not saying there aren't situations where it's a good idea to have SVN encrypt passwords, just that this isn't a very good example of one. If people can boot a LiveCD and get root access to your NFS shares, they already have the keys to the castle. -- David Brodbeck System Administrator, Linguistics University of Washington
Re: svn Farm
On Wed, Oct 20, 2010 at 4:30 PM, David Brodbeck bro...@uw.edu wrote: If I have root access to the filesystem, it doesn't matter what SSH does to try to encrypt the password... Typo. s/SSH/SVN/ -- David Brodbeck System Administrator, Linguistics University of Washington
Re: svn Farm
On 19 October 2010 02:17, Nico Kadel-Garcia nka...@gmail.com wrote: On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Add a capability called keyringenabled to Subversion and now Nico will probably be much happier... but of course he doesn't trust his users so he cannot trust that they report keyringenabled correctly... but he might be pragmatic enough to accept that as a compromise. Now, now. Don't put words in my mouth. I'm concerned about obvious and possible and documented attack vectorrs: passwords in cleartext are one of them. Eventually, any idiot can write a script that stores passwords in clear-text to mishandle local passwords or passphrase protected keys, but putting the capability in as the default behavior is extremely poor practice and should not be supported by default configuration or behavior. I don't think that keyring enabled is sufficient. A protocol shift that *requires* a better protected password and blocks the currently unsecured local password storage access would be interesting, I thought the gpg-agent changes would do that, but Stefan pointed out the flaws, dang it. the svn client would only report keyringenabled if the keyring was enabled for password storage and the client was configured to not store plaintext... perhaps plaintextpasswordstoragedisabled is a better name for the feature. svn+ssh actually works reasonably well: it just doesn't suppor the use my normal login password approach to managing user access. and that's probably a feature we could add in 1.6.14 with only minor effort (most of the work being deciding what the feature name should be ;-) ) -Stephen If it could require the client to actually *use* the keyring, I could see it. How would we support that for TortoiseSVN clients? Exposing the feature would not in an of itself force the client to use the keyring, but it would allow the server to have a start-commit hook that blocked a commit if the user had plaintext password storage enabled... so ok, if I have a client with plaintext storage enabled and I attempt a commit, there is a possibility that my password will get stored in plaintext on my system, but the start-commit hook can send back the message saying something like Your client is storing passwords in plaintext, which is against the policy for this server. To commit your changes you need to configure your client to securely store the password or else use --no-auth-cache on the command line. See http://internal-wiki-page-link for details. The wiki page can describe how to remove the plaintext passwords and how to configure a keyring. So you would not get completely secure by default, but one could have the start-commit.tmpl have code to show how to secure the system, and you would have what you require to ensure the system is secure going forward. -Stephen
Re: svn Farm
On Tue, Oct 19, 2010 at 9:46 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Exposing the feature would not in an of itself force the client to use the keyring, but it would allow the server to have a start-commit hook that blocked a commit if the user had plaintext password storage enabled... Just keep in mind that alerting users with start-commit hook only works for users that actually commit of course. You won't reach users that merely checkout/update/log/blame/... It might be a better solution to implement this check in a lower level, in the ra-protocols (naïvely, e.g. with http(s): client sends with every request a header announcing the way it stores its password). Of course, you'd like to do this without adding too much overhead (handshaking, ... for every tiny request that the client makes to the server). Maybe there is already some functionality present for protocol/feature negotiation, I don't know ... Just my 0.02€ Cheers, -- Johan
Re: svn Farm
On 19 October 2010 10:18, Johan Corveleyn jcor...@gmail.com wrote: On Tue, Oct 19, 2010 at 9:46 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Exposing the feature would not in an of itself force the client to use the keyring, but it would allow the server to have a start-commit hook that blocked a commit if the user had plaintext password storage enabled... Just keep in mind that alerting users with start-commit hook only works for users that actually commit of course. You won't reach users that merely checkout/update/log/blame/... true, but that assumes you require authentication to have read access. we do not require authentication for read, only for write It might be a better solution to implement this check in a lower level, in the ra-protocols (naïvely, e.g. with http(s): client sends with every request a header announcing the way it stores its password). Of course, you'd like to do this without adding too much overhead (handshaking, ... for every tiny request that the client makes to the server). Maybe there is already some functionality present for protocol/feature negotiation, I don't know ... Just my 0.02€ Cheers, -- Johan I agree that this would be better! -Stephen
Re: svn Farm
Johan Corveleyn wrote on Tue, Oct 19, 2010 at 11:18:20 +0200: Maybe there is already some functionality present for protocol/feature negotiation, I don't know ... All RA layers have a 'capability negotiation' support: svn_ra_has_capability() allows the client to ask the server what it supports. In ra_svn the protocol supports bidirectional capabilities (i.e., it allows the client to advertise capabilities to the server). I don't remember offhand if the ra_dav protocol supports that too.
Re: svn Farm
On 17 October 2010 08:52, Alan Barrett a...@cequrux.com wrote: On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote: What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. I'd settle for being able to block that local use on the server side: OK, so you want a feature in which the client reports to the server here are some important aspects of my configuration, and the server replies I don't like this aspect of your configuration, so I refuse to work with you. I suggest that you write up a proposal for such a feature, or begin a focused discussion about how such a feature could work and could be useful. --apb (Alan Barrett) The reality is if you don't trust the client, then you don't trust the client so how can you trust it to report what it supports correctly? It would be trivial to fork svn to lie and report that it only stored passwords encrypted, stick that forked client on my machine and hey presto, away I go storing my password in plaintext. I think that the best compromise would be for the SVN client to report its capabilities like the SVN 1.5+ clients do: You can have a start-commit hook. It can reject commits from clients that don't have the mergeinfo capability. http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.start-commit.html And that sorts out Nico's requirement for blocking the insecure 1.4 clienst in Redhat EL/CentOS Add a capability called keyringenabled to Subversion and now Nico will probably be much happier... but of course he doesn't trust his users so he cannot trust that they report keyringenabled correctly... but he might be pragmatic enough to accept that as a compromise. and that's probably a feature we could add in 1.6.14 with only minor effort (most of the work being deciding what the feature name should be ;-) ) -Stephen
Re: svn Farm
On Mon, Oct 18, 2010 at 3:56 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Add a capability called keyringenabled to Subversion and now Nico will probably be much happier... but of course he doesn't trust his users so he cannot trust that they report keyringenabled correctly... but he might be pragmatic enough to accept that as a compromise. Now, now. Don't put words in my mouth. I'm concerned about obvious and possible and documented attack vectorrs: passwords in cleartext are one of them. Eventually, any idiot can write a script that stores passwords in clear-text to mishandle local passwords or passphrase protected keys, but putting the capability in as the default behavior is extremely poor practice and should not be supported by default configuration or behavior. I don't think that keyring enabled is sufficient. A protocol shift that *requires* a better protected password and blocks the currently unsecured local password storage access would be interesting, I thought the gpg-agent changes would do that, but Stefan pointed out the flaws, dang it. svn+ssh actually works reasonably well: it just doesn't suppor the use my normal login password approach to managing user access. and that's probably a feature we could add in 1.6.14 with only minor effort (most of the work being deciding what the feature name should be ;-) ) -Stephen If it could require the client to actually *use* the keyring, I could see it. How would we support that for TortoiseSVN clients?
Re: svn Farm
On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote: What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. I'd settle for being able to block that local use on the server side: OK, so you want a feature in which the client reports to the server here are some important aspects of my configuration, and the server replies I don't like this aspect of your configuration, so I refuse to work with you. I suggest that you write up a proposal for such a feature, or begin a focused discussion about how such a feature could work and could be useful. --apb (Alan Barrett)
Re: svn Farm
On Sun, Oct 17, 2010 at 3:52 AM, Alan Barrett a...@cequrux.com wrote: On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote: What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. I'd settle for being able to block that local use on the server side: OK, so you want a feature in which the client reports to the server here are some important aspects of my configuration, and the server replies I don't like this aspect of your configuration, so I refuse to work with you. I suggest that you write up a proposal for such a feature, or begin a focused discussion about how such a feature could work and could be useful. --apb (Alan Barrett) I think the gpg-agent support will provide that by forcing people to a new authentication protocol. Won't that work?
Re: svn Farm
On Sun, Oct 17, 2010 at 12:14:12AM -0400, Nico Kadel-Garcia wrote: On Sat, Oct 16, 2010 at 10:00 AM, Stefan Sperling s...@elego.de wrote: I share Nico's concerns, and when I did (successfully) try to get the behaviour changed, the community was OK with adding a prompt, but not with dropping the feature entirely. Which I would have happily done if people had let me do it. But fair enough, the community's decision is binding, and overrules my own, personal, opinion. How did the community vote? There was no vote on this matter. We only vote when consensus cannot be reached. AFAIK this only happened once or twice in the lifetime of the project. One vote was about whitespace formatting rules in the code. the only one whose vote really counts, unless others want to write a fork. All discussion happens on the public dev@ list and everyone is invited to participate. Of course, opinions of committers tend to carry more weight than opinions of people who don't have commit access. But that is not because of random circumstance -- it's because committers have earned the trust of the community to be in that position. And often enough committers disagree with each other just like non-committers can disagree with committers. Some links into the archives regarding the plaintext password discussion: http://svn.haxx.se/dev/archive-2007-10/0525.shtml http://svn.haxx.se/dev/archive-2008-04/0685.shtml http://svn.haxx.se/dev/archive-2008-04/0832.shtml So I don't think Nico will ever get what he wants, no matter how much he'll be ranting about it or be trying to actually contribute towards getting this feature removed. Would patch files for the config files help to get it enabled by default help? I can send them. I'm not sure I understand what you want to send. Any submissions are welcome. For huge changes, sparking off a discussion within the community before doing a lot of work is a good idea, in case the idea ends up being rejected. And usually the idea gets refined quite a lot during discussion. And I suppose he won't be happy with GPG support either. I'd be happy if you'd call it it by its correct name. It's not GPG support. It's gpg-agent support, which is a local daemon for providing access to unlocked GPG keys. It's a great widget, I've used it, and I'd love to see it in the Subversion code base. It would allow admins to prevent the use of the existing older releases and enforce an upgrade to a more securite technology. Go, Dan Engel for submitting it! The server doesn't care about what the client does with the password, and the gpg-agent support won't change that. The gpg-agent password store will be optional and behave just like the gnome-keyring and kwallet stores. What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. I'd settle for being able to block that local use on the server side: that means a structural change. It will never work reliably because the client can lie about it. There has been discussion about repository-dictated configuration before. Here's a recent thread: http://svn.haxx.se/dev/archive-2010-08/0166.shtml
Re: svn Farm
Nico Kadel-Garcia wrote on Sun, Oct 17, 2010 at 08:41:51 -0400: On Sun, Oct 17, 2010 at 3:52 AM, Alan Barrett a...@cequrux.com wrote: On Sun, 17 Oct 2010, Nico Kadel-Garcia wrote: What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. I'd settle for being able to block that local use on the server side: OK, so you want a feature in which the client reports to the server here are some important aspects of my configuration, and the server replies I don't like this aspect of your configuration, so I refuse to work with you. I suggest that you write up a proposal for such a feature, or begin a focused discussion about how such a feature could work and could be useful. I think the gpg-agent support will provide that by forcing people to a new authentication protocol. Won't that work? http://article.gmane.org/gmane.comp.version-control.subversion.devel/121768
Re: svn Farm
Hi Nico, I'd love to see this deployed, and love to see the protocol updated enough to block the use of the older, less secure clients. But 1.7 has already blown well past its release date of this summer. If it's not in feature freeze, I'll be pleasantly surprised to see such a feature. And let's be clear: I started ranting about this back in. 2006? 2005? The changes have been positive, but hardly complete. I'm affraid ranting about it does not really help: it puts Subversion in a bad light, but doesn't really solve anything. So, instead of just stating what's wrong all the time, it would be nice if you started actually contributing toward the goals you think need to be achieved. By the way: there are users (lots) who are actually not at all that uncomfortable with the current situation: I'm my own sysadmin with no network disks around. There's nothing to be hidden on this system. There are many others with situations alike, so plainly removing the current support is *no* option for me, unless you offer me a password-less alternative which also doesn't introduce additional setup requirements. Bye, Erik.
Re: svn Farm
On Sat, Oct 16, 2010 at 4:43 AM, Erik Huelsmann ehu...@gmail.com wrote: Hi Nico, I'd love to see this deployed, and love to see the protocol updated enough to block the use of the older, less secure clients. But 1.7 has already blown well past its release date of this summer. If it's not in feature freeze, I'll be pleasantly surprised to see such a feature. And let's be clear: I started ranting about this back in. 2006? 2005? The changes have been positive, but hardly complete. I'm affraid ranting about it does not really help: it puts Subversion in a bad light, but doesn't really solve anything. So, instead of just stating what's wrong all the time, it would be nice if you started actually contributing toward the goals you think need to be achieved. I do. Both by explaining the real risks, and pointing out the tools that do work. (svn+ssh, and keeping your passwords for Subversion separate from your system passwords.) By the way: there are users (lots) who are actually not at all that uncomfortable with the current situation: I'm my own sysadmin with no network disks around. There's nothing to be hidden on this system. There are many others with situations alike, so plainly removing the current support is *no* option for me, unless you offer me a password-less alternative which also doesn't introduce additional setup requirements. And I'd like a pony. More seriously, doesn't introduce additional setup requirements is an amazingly high bar for real world security. The small vulnerabilities stack up to a far too common, vulnerable set up that exists world wide. More seriously,
Re: svn Farm
On Sat, Oct 16, 2010 at 10:43:01AM +0200, Erik Huelsmann wrote: Hi Nico, I'd love to see this deployed, and love to see the protocol updated enough to block the use of the older, less secure clients. But 1.7 has already blown well past its release date of this summer. If it's not in feature freeze, I'll be pleasantly surprised to see such a feature. And let's be clear: I started ranting about this back in. 2006? 2005? The changes have been positive, but hardly complete. I'm affraid ranting about it does not really help: it puts Subversion in a bad light, but doesn't really solve anything. So, instead of just stating what's wrong all the time, it would be nice if you started actually contributing toward the goals you think need to be achieved. It should be noted that, in our community, contributing towards such goals will also require compromise. Which people concerned about security are rarely willing to make (good enough isn't good enough, it needs to be as good and secure as it can possibly be). I share Nico's concerns, and when I did (successfully) try to get the behaviour changed, the community was OK with adding a prompt, but not with dropping the feature entirely. Which I would have happily done if people had let me do it. But fair enough, the community's decision is binding, and overrules my own, personal, opinion. So I don't think Nico will ever get what he wants, no matter how much he'll be ranting about it or be trying to actually contribute towards getting this feature removed. And I suppose he won't be happy with GPG support either. What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. By the way: there are users (lots) who are actually not at all that uncomfortable with the current situation: I'm my own sysadmin with no network disks around. There's nothing to be hidden on this system. There are many others with situations alike, so plainly removing the current support is *no* option for me, unless you offer me a password-less alternative which also doesn't introduce additional setup requirements. Precisely. There's no one-size-fits-all solution. Well, there is one on Windows and Mac because they have standard password stores. But in the Linux/UNIX world there isn't. Stefan
Re: svn Farm
On 10/16/10 8:53 AM, Nico Kadel-Garcia wrote: And I'd like a pony. More seriously, doesn't introduce additional setup requirements is an amazingly high bar for real world security. The small vulnerabilities stack up to a far too common, vulnerable set up that exists world wide. If you are willing to throw additional setup requirements into the mix, why not add an encrypted file system to hold your items that need to be secured. And use https with required client certificates as your transport. -- Les Mikesell lesmikes...@gmail.com
Re: svn Farm
On Sat, Oct 16, 2010 at 10:54 AM, Les Mikesell lesmikes...@gmail.com wrote: On 10/16/10 8:53 AM, Nico Kadel-Garcia wrote: And I'd like a pony. More seriously, doesn't introduce additional setup requirements is an amazingly high bar for real world security. The small vulnerabilities stack up to a far too common, vulnerable set up that exists world wide. If you are willing to throw additional setup requirements into the mix, why not add an encrypted file system to hold your items that need to be secured. And use https with required client certificates as your transport. Well, I was trying to make the point that very modest security efforts get you big advantages. For example, activating that warning before storing local passwords was very helpful. Disabling it in the default config files would be better. What you mention are interesting approaches, out of the reach of many users but available. If you've got the resources to do that, fabulous. For laptops, or Kerberos servers or GPG key repositories, I think they're great. It does nothing in the still-quite-common NFS home directory environments, or the we need to be able to share files!!! environments where users do insist on having easy access. Required SSL certificates is equivalent to SSH keys. Unless you have some sort of agent to unlock them for dynamic use without constantly typing a password or unlocking password, their primary advantage is that they restrict the access from being based on the user's password, especially their normal account password, and protect that access. And unless there is some means to generate or recover that SSL certificate for new hosts or debugging environments that can only access the Subversion server, I detect some difficlties. The problem there is that people do tend to want to have single-sign-on andn account centralization, such as LDAP based account management and back-end Kerberos management. As soon as you go there, you block the use of this kind of private certificate based access. I've actually been looking at Kerberized access to a subversion management account, in order to support svn+ssh and allow the Kerberos keys or LDAP to use Kerberos key, not password based access. The difficulty is in restricting it to non-shell login on a user account, much as the SSH public key command restrictions normally work. So I'm looking at the rssh tool to help with that, by providing a restricted shell for that svn+ssh account owner, but having difficulty unwinding the user name from the connectoin for Subversion logging and getting a good clean package. There are lighter weight approaches. Simply publishing the default configuration files for Subversion to disable password storage by default, much as it used to be enabled for silent storage by default, would be a good move: force people to *think* and do something manually before they store passwords. The failure of the make they say yes approach is borned out by the number of blank or poorly written passwords accepted by local passwd files where it warns you, but eventually allows you to store a poor or even blank password by hitting Enter enough times. (Went thorugh that again this years: demonstrated it for an NIS setup that the owner wasn't aware the users had published blank passwords in.)
Re: svn Farm
On Sat, Oct 16, 2010 at 10:00 AM, Stefan Sperling s...@elego.de wrote: It should be noted that, in our community, contributing towards such goals will also require compromise. Which people concerned about security are rarely willing to make (good enough isn't good enough, it needs to be as good and secure as it can possibly be). Certainly compromises are necessary in life. I've *been* compromising, I'm helping peoplle get svn+ssh working and publishing notes on getting it working. I share Nico's concerns, and when I did (successfully) try to get the behaviour changed, the community was OK with adding a prompt, but not with dropping the feature entirely. Which I would have happily done if people had let me do it. But fair enough, the community's decision is binding, and overrules my own, personal, opinion. How did the community vote? I'm glad to see the query, I really am. It's a step forward. But the person who owns the central repository is the only one whose vote really counts, unless others want to write a fork. Who stopped you? So I don't think Nico will ever get what he wants, no matter how much he'll be ranting about it or be trying to actually contribute towards getting this feature removed. Would patch files for the config files help to get it enabled by default help? I can send them. And I suppose he won't be happy with GPG support either. I'd be happy if you'd call it it by its correct name. It's not GPG support. It's gpg-agent support, which is a local daemon for providing access to unlocked GPG keys. It's a great widget, I've used it, and I'd love to see it in the Subversion code base. It would allow admins to prevent the use of the existing older releases and enforce an upgrade to a more securite technology. Go, Dan Engel for submitting it! What he really wants is an alternate-universe Subversion which never had the plaintext password storage feature in the first place. I'd settle for being able to block that local use on the server side: that means a structural change. Hopefully, this gpg-agent shift will provide that. Unfortunately, the 1.7 code base has already blown by its release date, and RHEL 6 is already in feature freeze. We've missed the window of opportunity: expect it to be another 4 years before the next major release and Subversion update for their core distribution. I'd still be happy to see it and be delighted to double check and submit it to RPMforge for updates. Precisely. There's no one-size-fits-all solution. Well, there is one on Windows and Mac because they have standard password stores. But in the Linux/UNIX world there isn't. Stefan
Re: svn Farm
On Thu, Oct 14, 2010 at 4:58 PM, David Brodbeck bro...@uw.edu wrote: On Thu, Oct 14, 2010 at 11:28 AM, Stefan Sperling s...@elego.de wrote: As of 1.6, Subversion asks the user before saving passwords in plaintext. 1.6 also added support for using GNOME Keyring and KDE Wallet as password stores. Yup. There are, as noted, unfortunately a lot of hassles involved with those tools in a non-GUI environment; what we really need is a lightweight, secure, standard keyring service. But getting Linux distros to standardize on *anything* is like herding cats, so I'm not holding my breath. ;) The assumption seems to be that these are things that only desktop users really want, so bundling them as part of the GUI is sufficient. I don't blame Subversion for that, though. GNOME keyring can work well in a non-GUI environment. I use it in an environment where I just SSH into a remote Linux server without any X environment. I just start gnome-keyring-daemon when I login. Not sure if KWallet has an equivalent. This even works with the ancient gnome-keyring libraries included in RHEL 4. I've also used it on Solaris. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: svn Farm
On Thu, Oct 14, 2010 at 2:28 PM, Stefan Sperling s...@elego.de wrote: On Thu, Oct 14, 2010 at 10:56:35AM -0700, David Brodbeck wrote: On Sat, Oct 9, 2010 at 6:39 AM, Nico Kadel-Garcia nka...@gmail.com wrote: Think I'm kidding? Walk into any university environment: plug in a live Linux CD. Run an nmap scan for hosts running NFS. Run showmount to detect what NFS shares are published to everyone. Go ahead and mount the shares. Look in them for home directoriies. Look in them, using your local root privileges, for Subversion passphrases. (Look for CVS passphrases and un-passphrase-protected SSH keys while you're at it.) This is why running public-facing NFS servers using auth_sys and no_root_squash is a BAD idea. If this is happening at your site, you have much more serious things to worry about than subversion passwords being stolen. For example, in your scenario it would be trivial to create an suid-root shell binary, which a local user could then run and gain root privileges. Exactly. Bad NFS configuration isn't Subversion's fault. Neither are NFS implementations that have insecure default settings, like not mapping 'root' to 'nobody' by default. No. system_auth is still the NFS standard for internal use in both academic and professional environments. auth_dh has uses, but it doesn't help against any machine with allocated or cracked local root access. This isn't your local machine, it's the network wide home directory system, and there are plenty of them out there without even this step. auth_krb5, well, if someone's that sophisticated, they'ld probably fire you or kick you off your network if they found out you were use Subversion with local password storage. no_root_squash is only relevant if you can prevent local root user access on all NFS clients. But walk into any university and most corporate networks with a live CD, and go ahead and do a very slight amount of poking for NFS servers. Not many environments have invested the work to protect against that kind of access. There are problems with plaintext passwords, no doubt. But the above scenario description is hyped up and misses the point. If you cannot trust root on a UNIX box, don't save anything of value on that box. Conversely, if you can't trust an application or the defaults for a protocol not to store passwords in clear text, don't use it. Or at least never, never, never use system passwords for it. As of 1.6, Subversion asks the user before saving passwords in plaintext. 1.6 also added support for using GNOME Keyring and KDE Wallet as password stores. Which is great. The asking for passwords was a long time coming, and I'm glad to see it. Frankly, I'd prefer to see the default configuraton disable it entirely. I can see storing a mickey mouse password for a Subversion server with mickey mouse security, designed to prevent casual access much like its CVS ancestor. But certainly never under current practices: I'm afraid that too many users believe in the we have a firewall, we trust the people we work with, we have an IT department to help if we get cracked! approach to the world. The results are... unfortunate. The keyring support is also good. But until the servers can block the use of the older clients, especially the actively supported 1.4 in RHEL and CentOS 5, which is their most recent release, it's an ongoing problem. SSH agents can work well without having to significantly udpate Subversion, and I am glad it's supported, albeit poorly on the server side. (Key management is an ongoing issue with no good software solutions published.) It looks like there will be support for using PGP to encrypt passwords soon. Maybe even in 1.7. Some code for this has already entered the repository: http://svn.apache.org/viewvc?view=revisionrevision=1005036 Hold it: PGP and GPG are different code bases, although they use the same protocol, and this is reliant on gpg-agent to keep the keys unlocked for local use. I like gpg-agent, but let's be careful about it. I'd love to see this deployed, and love to see the protocol updated enough to block the use of the older, less secure clients. But 1.7 has already blown well past its release date of this summer. If it's not in feature freeze, I'll be pleasantly surprised to see such a feature. And let's be clear: I started ranting about this back in. 2006? 2005? The changes have been positive, but hardly complete.
Re: svn Farm
On Thu, Oct 14, 2010 at 10:56:35AM -0700, David Brodbeck wrote: On Sat, Oct 9, 2010 at 6:39 AM, Nico Kadel-Garcia nka...@gmail.com wrote: Second, many working environments in the UNIX world rely on NFS based home directoies, to share working environments and configurations across a variety of machines. In such environments, *any* host that can be leveraged to local root access can su or suco to become the target user, and access their entire home directory. Think I'm kidding? Walk into any university environment: plug in a live Linux CD. Run an nmap scan for hosts running NFS. Run showmount to detect what NFS shares are published to everyone. Go ahead and mount the shares. Look in them for home directoriies. Look in them, using your local root privileges, for Subversion passphrases. (Look for CVS passphrases and un-passphrase-protected SSH keys while you're at it.) This is why running public-facing NFS servers using auth_sys and no_root_squash is a BAD idea. If this is happening at your site, you have much more serious things to worry about than subversion passwords being stolen. For example, in your scenario it would be trivial to create an suid-root shell binary, which a local user could then run and gain root privileges. Exactly. Bad NFS configuration isn't Subversion's fault. Neither are NFS implementations that have insecure default settings, like not mapping 'root' to 'nobody' by default. There are problems with plaintext passwords, no doubt. But the above scenario description is hyped up and misses the point. If you cannot trust root on a UNIX box, don't save anything of value on that box. As of 1.6, Subversion asks the user before saving passwords in plaintext. 1.6 also added support for using GNOME Keyring and KDE Wallet as password stores. It looks like there will be support for using PGP to encrypt passwords soon. Maybe even in 1.7. Some code for this has already entered the repository: http://svn.apache.org/viewvc?view=revisionrevision=1005036 Stefan
Re: svn Farm
On Thu, Oct 14, 2010 at 2:22 PM, Stefan Sperling s...@elego.de wrote: I hope the work-in-progress gpg-agent support I mentioned will fill that gap. Would using gpg-agent work for you? Quite likely. I haven't really played with gpg-agent, but I don't know of any reason it shouldn't work. -- David Brodbeck System Administrator, Linguistics University of Washington
Re: svn Farm
On Sun, Oct 10, 2010 at 4:26 PM, Les Mikesell lesmikes...@gmail.com wrote: On 10/10/10 3:12 PM, Nico Kadel-Garcia wrote: If they didn't, it would be impossible to do automated commands. There are times when you have to choose between trusting the OS to protect your files (which is, after all, one of its jobs) or not being able to do what you want. This is incorrect. There are at least 5 tools in common use to support unlocking SSH keys and making them available for other programs to use, all based on the ssh-agent built-in technology of all vaguely complete SSH software packages. The include: * Pageant, built into the Putty installer, for Windows users. * gnome-keyring, already mentioned in this thread and aimed at X sessions, possible to use for command line sessions with considerable work. * kde-wallet, similar to gnome-keyring * keychain, a popular and lightweight Perl script for just this use. * Typing eval ssh-agent and ssh-add [name of your SSH private key from the command line in the window or session you will run Subversion from. All of which require user interaction at some point. What if the machine reboots? And what do you do about other files with contents that need to be protected? Your ssh key probably isn't the only thing you'd like to keep private. [ We've drifted like crazy from the original subject: if this is getting boring or confusing, let me know. ] Well, yes. Your keys are *supposed* to be unavailable until re-authenticated if your system reboots, and it's in conflict with the idea that it should work unattended no matter what that you've just described. But then, so is having a password at all: we find ways to work around it, such as a notification email that a machine has rebooted and your keys are no longer available for your cron job automated Subversion updates tag building. There are key systems that don't normally require re-authentication, such as SSH host keys webserver SSL keys that are owned locally and owned by root. But it's not a practice used for secure web sites or critical systems such as Kerberos servers, and I've certainly done so with web servers that handled critical data, especially money and medical data. Also note that the system that holds the SSH keys, and unlocks them with a passphrase, need not be the system doing the checking out. That key holding can forward its SSH agents to connect to another host and do its work: for example, my Windows client can use Pageant and Putty to connect to a Linux server and do Subversion work with only my local client unlocking the keys. That keeps my SSH keys somewhere even safer: on my USB key, along with my svnsync m anaged copy of critical source code. If you're granting access that has to be available unattended, you've entered a problematic security environment. It's why you *absolutely should not* provide normal shell access with such an unattended key access, and you should use different keys for svn+ssh than you do for normal logins. It helps prevent people who are careless with their Subversion keys from imperiling their normal login access.
Re: svn Farm
On Sat, Oct 9, 2010 at 2:05 PM, Les Mikesell lesmikes...@gmail.com wrote: On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote: Yeah, both Subversion and SSH share the flaw of *ALLOWING* such unprotected keys to be stored locally, with no special command line arguments or special settings, and impossible to compile out of the clients with the current source trees. If they didn't, it would be impossible to do automated commands. There are times when you have to choose between trusting the OS to protect your files (which is, after all, one of its jobs) or not being able to do what you want. This is incorrect. There are at least 5 tools in common use to support unlocking SSH keys and making them available for other programs to use, all based on the ssh-agent built-in technology of all vaguely complete SSH software packages. The include: * Pageant, built into the Putty installer, for Windows users. * gnome-keyring, already mentioned in this thread and aimed at X sessions, possible to use for command line sessions with considerable work. * kde-wallet, similar to gnome-keyring * keychain, a popular and lightweight Perl script for just this use. * Typing eval ssh-agent and ssh-add [name of your SSH private key from the command line in the window or session you will run Subversion from. It's a pain in the backside, but it's fairly common practice. It wouldn't be so necessary if Subversion didn't rely on central repository access for committing any changes. but that's pretty core to the way CVS and and now Subversion work, and I don't see that going away.
Re: svn Farm
On Sat, Oct 9, 2010 at 3:05 PM, jehan procaccia jehanpr...@gmail.com wrote: Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit : svn+ssh is the most secure, but it conflcts with your desire for LDAP access. The SSH keys normally live under a single user's account, the user who owns the repository, who hsould have a locked password. You see why this conflicts with LDAP based user information and logins? No, I don't see why it conflicts ? here's again my scenario, 1) I set and manage all repositories with a unique local unix account (for example username svn !), that account issues all svn create and owns the repos filesystem directories 2) enable the server to resolve ldapusers (pam nss ldap), so that the --tunnel-user=ldapusername option (see 3 below) works. Right, all LDAP based. So rar, so good, this can be woven into the HTTPS access or, conceivably, into the svnserve based access, although I've never seen it done. 3) then add ldap users public ssh keys to the ~.ssh/authorized_keys of that unique svn manager account as in : command=svnserve -t --tunnel-user=ldapusernamessh_rsa KEYX... COMMENT The sysadmin (me ) will have to find a way to push ldapusers public keys to that unique svn manager (script/CGI ...) This is an entirely distinct access technology. It contains not a single fleck of LDAP in it it, except perhaps to publish the user account information for the svn manager account. Anything wrong in that scenario ? Wrong, no, just confused. Steps 1 and 2 have nothing to do with step 3 and can be entirely discarded.
Re: svn Farm
On 10/10/10 3:12 PM, Nico Kadel-Garcia wrote: On Sat, Oct 9, 2010 at 2:05 PM, Les Mikeselllesmikes...@gmail.com wrote: On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote: Yeah, both Subversion and SSH share the flaw of *ALLOWING* such unprotected keys to be stored locally, with no special command line arguments or special settings, and impossible to compile out of the clients with the current source trees. If they didn't, it would be impossible to do automated commands. There are times when you have to choose between trusting the OS to protect your files (which is, after all, one of its jobs) or not being able to do what you want. This is incorrect. There are at least 5 tools in common use to support unlocking SSH keys and making them available for other programs to use, all based on the ssh-agent built-in technology of all vaguely complete SSH software packages. The include: * Pageant, built into the Putty installer, for Windows users. * gnome-keyring, already mentioned in this thread and aimed at X sessions, possible to use for command line sessions with considerable work. * kde-wallet, similar to gnome-keyring * keychain, a popular and lightweight Perl script for just this use. * Typing eval ssh-agent and ssh-add [name of your SSH private key from the command line in the window or session you will run Subversion from. All of which require user interaction at some point. What if the machine reboots? And what do you do about other files with contents that need to be protected? Your ssh key probably isn't the only thing you'd like to keep private. -- Les Mikesell lesmikes...@gmail.com
Re: svn Farm
Le 09/10/2010 15:39, Nico Kadel-Garcia a écrit : On Fri, Oct 8, 2010 at 11:15 AM, Bob Archerbob.arc...@amsi.com wrote: The client should be able to store the credentials if you have it set up to do so. On windows/mac it is encrypted with OS included libraries. For Linux you need to set up gnome keyring or kde-wallet. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.credcache Warning up front: this is a long analysis, and slightly ranting. I'll shorten it up to say this is completely unreliable and misleading documentation. Let's quote it, shall we? •For other Unix-like operating systems, no standard “keychain” services exist. This is the fundamental problem, coupled with the default enabled storage of passwords and no way to prevent it on the server. However, the Subversion client knows how to store password securely using the “GNOME Keyring” and “KDE Wallet” services. Both of these tools require bulky sets of dependencies not mentioned or documented except, these days, in the on-line book. They're not installed by default, and using them from a non X session or a remote X terminal or Putty is damned akward. There are published widgets to aid this, such as the gkeyring utility, but they're not standardized yet in any UNIX or Linux distribution that I can find. So this claim is classic handwaving. Also, before storing unencrypted passwords in the ~/.subversion/auth/ caching area, the Subversion client will ask the user for permission to do so. This feature was only, finally, added in Subversion 1.6. Quite a few operating systems don't provide this recent a version: RHEL and CentOS, for example, are still stuck at Subversion 1.4. And it can't be enforced on the server, it's entirely client side optional behavior. Note that the auth/ caching area is still permission-protected so that only the user (owner) can read data from it, not the world at large. The operating system's own file permissions protect the passwords from other non-administrative users on the same system, provided they have no direct physical access to the storage media of the home directory, or backups thereof. And whowever wrote this has no idea what they're talking about. I'm going to be crude for a moment: this is complete horseshit. First, many backup systems are often enabled to allow network based recovery. After all, who would be stupid enough to put clear text passwords on their backup tapes? Second, many working environments in the UNIX world rely on NFS based home directoies, to share working environments and configurations across a variety of machines. In such environments, *any* host that can be leveraged to local root access can su or suco to become the target user, and access their entire home directory. Think I'm kidding? Walk into any university environment: plug in a live Linux CD. Run an nmap scan for hosts running NFS. Run showmount to detect what NFS shares are published to everyone. Go ahead and mount the shares. Look in them for home directoriies. Look in them, using your local root privileges, for Subversion passphrases. (Look for CVS passphrases and un-passphrase-protected SSH keys while you're at it.) This requires no internal knowledge of the remote system, and can also be done by any rootkitted system on the network. If you happen to already know the environment somewhat, just lok into any local system and take some notes. So, local physical access', my eye. The equivalent to this behavior is taping your front door key under your front door mat. After all, if they're on you porch, you trust them, right? They must be your neighbor if they're on your street! This is how many business and educational environments treat their networks: once you're inside the perimeter, you're assumed to be trusted and have tremendous access, because locking things down further requires time and money and inconvencience to the people trying to do their work. So, assuming that local physical access is required is an extremely ill-founded assumption. Now, allow me to quote the next part: Of course, for the truly paranoid, none of these mechanisms meets the test of perfection. So for those folks willing to sacrifice convenience for the ultimate in security, Subversion provides various ways of disabling its credentials caching system altogether. It's not paranoia when they *are* out to get you. And these days, with cracking kiddies wandering the world and people working in large shared networks, they are out to get you just as a hobby. And the ways of disabling its credentials caching sysem are all local client configuraton based. They are entirely reliant on owning the local installation, and *none* of them are on by default. Very few Subversion administrators have such direct control of the client base: I've run it for small and large companies and home setups, and *never* had that kind of control. Look,
Re: svn Farm
Le 09/10/2010 20:40, Nico Kadel-Garcia a écrit : svn+ssh is the most secure, but it conflcts with your desire for LDAP access. The SSH keys normally live under a single user's account, the user who owns the repository, who hsould have a locked password. You see why this conflicts with LDAP based user information and logins? No, I don't see why it conflicts ? here's again my scenario, 1) I set and manage all repositories with a unique local unix account (for example username svn !), that account issues all svn create and owns the repos filesystem directories 2) enable the server to resolve ldapusers (pam nss ldap), so that the --tunnel-user=ldapusername option (see 3 below) works. 3) then add ldap users public ssh keys to the ~.ssh/authorized_keys of that unique svn manager account as in : command=svnserve -t --tunnel-user=ldapusernamessh_rsa KEYX... COMMENT The sysadmin (me ) will have to find a way to push ldapusers public keys to that unique svn manager (script/CGI ...) Anything wrong in that scenario ? Thanks .
Re: svn Farm
On Fri, Oct 8, 2010 at 11:15 AM, Bob Archer bob.arc...@amsi.com wrote: The client should be able to store the credentials if you have it set up to do so. On windows/mac it is encrypted with OS included libraries. For Linux you need to set up gnome keyring or kde-wallet. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.credcache Warning up front: this is a long analysis, and slightly ranting. I'll shorten it up to say this is completely unreliable and misleading documentation. Let's quote it, shall we? •For other Unix-like operating systems, no standard “keychain” services exist. This is the fundamental problem, coupled with the default enabled storage of passwords and no way to prevent it on the server. However, the Subversion client knows how to store password securely using the “GNOME Keyring” and “KDE Wallet” services. Both of these tools require bulky sets of dependencies not mentioned or documented except, these days, in the on-line book. They're not installed by default, and using them from a non X session or a remote X terminal or Putty is damned akward. There are published widgets to aid this, such as the gkeyring utility, but they're not standardized yet in any UNIX or Linux distribution that I can find. So this claim is classic handwaving. Also, before storing unencrypted passwords in the ~/.subversion/auth/ caching area, the Subversion client will ask the user for permission to do so. This feature was only, finally, added in Subversion 1.6. Quite a few operating systems don't provide this recent a version: RHEL and CentOS, for example, are still stuck at Subversion 1.4. And it can't be enforced on the server, it's entirely client side optional behavior. Note that the auth/ caching area is still permission-protected so that only the user (owner) can read data from it, not the world at large. The operating system's own file permissions protect the passwords from other non-administrative users on the same system, provided they have no direct physical access to the storage media of the home directory, or backups thereof. And whowever wrote this has no idea what they're talking about. I'm going to be crude for a moment: this is complete horseshit. First, many backup systems are often enabled to allow network based recovery. After all, who would be stupid enough to put clear text passwords on their backup tapes? Second, many working environments in the UNIX world rely on NFS based home directoies, to share working environments and configurations across a variety of machines. In such environments, *any* host that can be leveraged to local root access can su or suco to become the target user, and access their entire home directory. Think I'm kidding? Walk into any university environment: plug in a live Linux CD. Run an nmap scan for hosts running NFS. Run showmount to detect what NFS shares are published to everyone. Go ahead and mount the shares. Look in them for home directoriies. Look in them, using your local root privileges, for Subversion passphrases. (Look for CVS passphrases and un-passphrase-protected SSH keys while you're at it.) This requires no internal knowledge of the remote system, and can also be done by any rootkitted system on the network. If you happen to already know the environment somewhat, just lok into any local system and take some notes. So, local physical access', my eye. The equivalent to this behavior is taping your front door key under your front door mat. After all, if they're on you porch, you trust them, right? They must be your neighbor if they're on your street! This is how many business and educational environments treat their networks: once you're inside the perimeter, you're assumed to be trusted and have tremendous access, because locking things down further requires time and money and inconvencience to the people trying to do their work. So, assuming that local physical access is required is an extremely ill-founded assumption. Now, allow me to quote the next part: Of course, for the truly paranoid, none of these mechanisms meets the test of perfection. So for those folks willing to sacrifice convenience for the ultimate in security, Subversion provides various ways of disabling its credentials caching system altogether. It's not paranoia when they *are* out to get you. And these days, with cracking kiddies wandering the world and people working in large shared networks, they are out to get you just as a hobby. And the ways of disabling its credentials caching sysem are all local client configuraton based. They are entirely reliant on owning the local installation, and *none* of them are on by default. Very few Subversion administrators have such direct control of the client base: I've run it for small and large companies and home setups, and *never* had that kind of control. Look, Subversion inherited its practice of storing password in cleartext from its ancestor, CVS. It's been
Re: svn Farm
I did just misspell sudo and tell the same story twice about opening up people's email with their stored passwords, didn't I? Remind me to re-edit *twice* before sending a rant.
Re: svn Farm
On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote: Look, Subversion inherited its practice of storing password in cleartext from its ancestor, CVS. It's been an uphill battle ever since to wallpaper over the practice: there are enough layers of wallpaper, finally, that it's almost thick enough to be a wall. It's fixed for TortoieSVN, and svn+ssh using SSH keys can work well. If you are going to rant, you should also point out that ssh keys without a passphrase and agent to manage it are not really any different than a file-stored password. If you can copy the private side of the identity key, you can get access. -- Les Mikesell lesmikes...@gmail.com
Re: svn Farm
On Sat, Oct 9, 2010 at 11:06 AM, Les Mikesell lesmikes...@gmail.com wrote: On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote: Look, Subversion inherited its practice of storing password in cleartext from its ancestor, CVS. It's been an uphill battle ever since to wallpaper over the practice: there are enough layers of wallpaper, finally, that it's almost thick enough to be a wall. It's fixed for TortoieSVN, and svn+ssh using SSH keys can work well. If you are going to rant, you should also point out that ssh keys without a passphrase and agent to manage it are not really any different than a file-stored password. If you can copy the private side of the identity key, you can get access. Yeah, both Subversion and SSH share the flaw of *ALLOWING* such unprotected keys to be stored locally, with no special command line arguments or special settings, and impossible to compile out of the clients with the current source trees. I've raised concerns about that since way, way back with ssh-1.21 and the early releases of ssh-2.0. This is why, ideally, the SSH keys for Subversion should be distinct from normal user login keys, but that can be very difficult to enforce as well.
Re: svn Farm
On 10/9/10 12:51 PM, Nico Kadel-Garcia wrote: On Sat, Oct 9, 2010 at 11:06 AM, Les Mikeselllesmikes...@gmail.com wrote: On 10/9/10 8:39 AM, Nico Kadel-Garcia wrote: Look, Subversion inherited its practice of storing password in cleartext from its ancestor, CVS. It's been an uphill battle ever since to wallpaper over the practice: there are enough layers of wallpaper, finally, that it's almost thick enough to be a wall. It's fixed for TortoieSVN, and svn+ssh using SSH keys can work well. If you are going to rant, you should also point out that ssh keys without a passphrase and agent to manage it are not really any different than a file-stored password. If you can copy the private side of the identity key, you can get access. Yeah, both Subversion and SSH share the flaw of *ALLOWING* such unprotected keys to be stored locally, with no special command line arguments or special settings, and impossible to compile out of the clients with the current source trees. If they didn't, it would be impossible to do automated commands. There are times when you have to choose between trusting the OS to protect your files (which is, after all, one of its jobs) or not being able to do what you want. -- Les Mikesell lesmikes...@gmail.com
Re: svn Farm
Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit : On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia jehan.procac...@it-sudparis.eu wrote: Le 06/10/2010 17:06, Siva Kumar a écrit : I need to provide svn service to many small groups of students. I'am looking for a tool that would help industrialize managment of repositories. I don't want to issue hundreds of svn create, vi authz , edit ssh keys for svn+ssh access etc ... Are there such tools already existing ? Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill. good point ! I've installed and run it, looks good. but now I need to find a way to link my ldap users to svn roles/authz , I still can't find how to do that wihout creating csvn local accounts for all my users :-( ... !? Unless you can guarantee that they will not use Linux or UNIX based clients, don't even consider this. The problem is that the Linux and UNIX clients, by default, continue to store passwords in clear text. They whinge about it now before storing it, but it's still an issue. Is there any reason you use 'svn' access, rather than HTTPS? The mod_dav_svn module works well, even though I detest the clear text password problem. I need my users to be able to work with svn repos both from unix shell command svn or through GUI clients (web browser, eclipse, tortoise ...) For web (http) acces, it looks good now, indeed if I set ldap users login name in the global authZ (file edit from the admin collabnet .../editAuthorization) it works fine . Now, is collabnet solution able to serve tradition unix shell comand line clients ? is there a svnserve server behind it or is apache able to serve those clients using svn protocol too ? There remains no good GUI or published toolkit for svn+ssh access configuration. This is one of Subversion's profound deficits, combined with the password issues with the Linux/UNIX clients. Various companies and groups have internal kits, including Sourceforge, but I've never seen their tools published. Too bad indeed that there is no toolkit for svn+ssh :-( Can I start aside collabnet (great and easy HTTP interface) a svnserve serving the same repostories ? If my unix collabnet server does know and authenticate my ldap users (with pam_ldap, nss etc ...) wouldn't they be able to connect to svnserve with their ldap password !?
Re: svn Farm
On Fri, Oct 8, 2010 at 4:10 AM, jehan procaccia jehan.procac...@it-sudparis.eu wrote: Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit : On Thu, Oct 7, 2010 at 12:18 PM, jehan procaccia jehan.procac...@it-sudparis.eu wrote: Le 06/10/2010 17:06, Siva Kumar a écrit : I need to provide svn service to many small groups of students. I'am looking for a tool that would help industrialize managment of repositories. I don't want to issue hundreds of svn create, vi authz , edit ssh keys for svn+ssh access etc ... Are there such tools already existing ? Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill. good point ! I've installed and run it, looks good. but now I need to find a way to link my ldap users to svn roles/authz , I still can't find how to do that wihout creating csvn local accounts for all my users :-( ... !? Unless you can guarantee that they will not use Linux or UNIX based clients, don't even consider this. The problem is that the Linux and UNIX clients, by default, continue to store passwords in clear text. They whinge about it now before storing it, but it's still an issue. Is there any reason you use 'svn' access, rather than HTTPS? The mod_dav_svn module works well, even though I detest the clear text password problem. I need my users to be able to work with svn repos both from unix shell command svn or through GUI clients (web browser, eclipse, tortoise ...) For web (http) acces, it looks good now, indeed if I set ldap users login name in the global authZ (file edit from the admin collabnet .../editAuthorization) it works fine . That's great if that's what you need. There is no way, though, to prevent your UNIX/Linux command line clients from storing their passwords in cleartext. This isn't a server problem. It's a command line client problem. Now, is collabnet solution able to serve tradition unix shell comand line clients ? is there a svnserve server behind it or is apache able to serve those clients using svn protocol too ? Subversion over HTTP is handled with the WebDAV protocol. I'm sure that svnserve protocl, run from the CollabNet packate, is using the svnserve package built into the Subversion source code. (Maybe with a few tweaks.) I've not personally taken it apart, so I don't know whether it uses its own webserver or plugs modules into Apache to run the commonly used https access. Also note: both the 'svn' and 'http' access send the passwords ovder the network in clear text. There are ways around this (such as SSH or SSL tunneling), but they're pesky to set up. Fortunately, https already has that built in. And svn+ssh not only has the tunneling, it correctly forces the clients to use SSH keys, instead of passwords that might be stored unlocked by the UNIX or Linux clients. There remains no good GUI or published toolkit for svn+ssh access configuration. This is one of Subversion's profound deficits, combined with the password issues with the Linux/UNIX clients. Various companies and groups have internal kits, including Sourceforge, but I've never seen their tools published. Too bad indeed that there is no toolkit for svn+ssh :-( I agree. If anyone finds or writes one, I'd love to see it. I'm not good at writing gui's from scratch, or I'd try to port one of the git toolkits over to Subversion for just this purpose. Can I start aside collabnet (great and easy HTTP interface) a svnserve serving the same repostories ? I've not tried it. You, or it, will have to be careful to set ownership of the repository to grant access to both the apache user for a normal webserver, if it's using the built-in Apache, or tun the Apache daemon and the svn daemon as the same user to assure consistent and controlled write access to the repository. If my unix collabnet server does know and authenticate my ldap users (with pam_ldap, nss etc ...) wouldn't they be able to connect to svnserve with their ldap password !? svnserve !=- Apache. They're serving different protocols, with different daemons. I've not personally tried to hook svnserve to LDAP/Kerberos. (Most LDAP setups use Kerberos for managing the passwords: LDAP stores the user information.) I'd review the options in the svnserve configuration settings for a normal repository: I'd be really surprised if CollabNet's version differs a lot from the normal subversion svnserve daemon: it's the management tool, and the support, you'd get and pay for from CollabNet. (This can be well worth paying for!!!) I've not taken apart the CollabNet packages: I assume they're good interfaces, CollabNet is a generally competent company and I've gotten good recommendations for it, especially to get commercial support for more recent releases on operating systems like RHEL where the vendor's published subversion is so stable it's dangerously obsolete. (They used to host the public wiki's and websites for it, a very good example of how to handle open source projects.)
Re: svn Farm
On Fri, Oct 8, 2010 at 2:09 PM, Nico Kadel-Garcia nka...@gmail.com wrote: On Fri, Oct 8, 2010 at 4:10 AM, jehan procaccia jehan.procac...@it-sudparis.eu wrote: Le 08/10/2010 02:19, Nico Kadel-Garcia a écrit : Unless you can guarantee that they will not use Linux or UNIX based clients, don't even consider this. The problem is that the Linux and UNIX clients, by default, continue to store passwords in clear text. They whinge about it now before storing it, but it's still an issue. Is there any reason you use 'svn' access, rather than HTTPS? The mod_dav_svn module works well, even though I detest the clear text password problem. I need my users to be able to work with svn repos both from unix shell command svn or through GUI clients (web browser, eclipse, tortoise ...) For web (http) acces, it looks good now, indeed if I set ldap users login name in the global authZ (file edit from the admin collabnet .../editAuthorization) it works fine . That's great if that's what you need. There is no way, though, to prevent your UNIX/Linux command line clients from storing their passwords in cleartext. This isn't a server problem. It's a command line client problem. Hi Nico, Slightly OT for this thread, but it may interest you to know that very recently some initiatives were started to include gpg-agent support in svn (just two days ago a feature branch was created to work on that functionality). I don't know any details about it myself (just read the posts on the dev list), but maybe that's the sort of improvement that would help to solve the cached-passwords-in-cleartext problem for UNIX/Linux? See these recent threads from the dev-list: - http://svn.haxx.se/dev/archive-2010-10/0099.shtml - http://svn.haxx.se/dev/archive-2010-10/0149.shtml Cheers, -- Johan
Re: svn Farm
On Fri, Oct 8, 2010 at 08:09, Nico Kadel-Garcia nka...@gmail.com wrote: Also note: both the 'svn' and 'http' access send the passwords ovder the network in clear text. There are ways around this (such as SSH or SSL tunneling), but they're pesky to set up. Fortunately, https already has that built in. HTTP Digest Authentication does not send the password in cleartext, it sends an MD5 hash. Yes, the hash is sent in cleartext, but that is not exactly the same as sending the *password* in cleartext. If you configure your svnserve to use SASL, it can use several methods of encryption for authentication. http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl I understand that you're very concerned with security shortcomings, but you're leaving out important details that may make the system appear less secure than it really can be with proper configuration.
Re: svn Farm
Le 08/10/2010 14:54, Andy Levy a écrit : On Fri, Oct 8, 2010 at 08:09, Nico Kadel-Garcianka...@gmail.com wrote: Also note: both the 'svn' and 'http' access send the passwords ovder the network in clear text. There are ways around this (such as SSH or SSL tunneling), but they're pesky to set up. Fortunately, https already has that built in. HTTP Digest Authentication does not send the password in cleartext, it sends an MD5 hash. Yes, the hash is sent in cleartext, but that is not exactly the same as sending the *password* in cleartext. If you configure your svnserve to use SASL, it can use several methods of encryption for authentication. http://svnbook.red-bean.com/en/1.5/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sasl I understand that you're very concerned with security shortcomings, but you're leaving out important details that may make the system appear less secure than it really can be with proper configuration. After all, I think I might consider svn+ssh for large scale svn unix command line acces. here's the scenario, 1) I set and manage all repositories with a unique local unix account (for example username svn !), that account issues all svn create and owns the repos filesystem directories 2) enable the server to resolve ldapusers (pam nss ldap), so that the --tunnel-user=ldapusername option (see 3 below) works. 3) then add ldap users public ssh keys to the authorized_keys of that unique svn manager account as in : command=svnserve -t --tunnel-user=ldapusernamessh_rsa KEYX COMMENT 4) write a script / web GUI that enable users to push their key in the ~svn/.ssh/authorized_key 5) copy a centraly managed authz file in every repos/conf/authz file, if I understand well svnserve there's no such AuthzSVNAccessFile central authz directive as in apache DAV svn !? Does this scenario make sense ? I agree step 4 will take some time ... thanks for you remarks .
RE: svn Farm
Now, is collabnet solution able to serve tradition unix shell comand line clients ? is there a svnserve server behind it or is apache able to serve those clients using svn protocol too ? BTW: If you have http(s) access you don't also need svn protocol. The svn command line client supports http(s) just fine. BOb
Re: svn Farm
Le 08/10/2010 15:59, Bob Archer a écrit : Now, is collabnet solution able to serve tradition unix shell comand line clients ? is there a svnserve server behind it or is apache able to serve those clients using svn protocol too ? BTW: If you have http(s) access you don't also need svn protocol. The svn command line client supports http(s) just fine. BOb Damn it ! I didn't realized it was possible ... I though svn command line tool could only talk to svnserve (svn or svn+ssh URLs) . Indeed, svn + ldaps URL might simplify my project . However, I already see a usage diffulty, any time I issue a svn command line, I'am asked to enter my password (apache authN !) , is there a workaround to that authN password call ? with svn+ssh I could push ssh public keys once for all . thanks .
RE: svn Farm
Le 08/10/2010 15:59, Bob Archer a écrit : Now, is collabnet solution able to serve tradition unix shell comand line clients ? is there a svnserve server behind it or is apache able to serve those clients using svn protocol too ? BTW: If you have http(s) access you don't also need svn protocol. The svn command line client supports http(s) just fine. BOb Damn it ! I didn't realized it was possible ... I though svn command line tool could only talk to svnserve (svn or svn+ssh URLs) . Indeed, svn + ldaps URL might simplify my project . However, I already see a usage diffulty, any time I issue a svn command line, I'am asked to enter my password (apache authN !) , is there a workaround to that authN password call ? with svn+ssh I could push ssh public keys once for all . thanks . The client should be able to store the credentials if you have it set up to do so. On windows/mac it is encrypted with OS included libraries. For Linux you need to set up gnome keyring or kde-wallet. http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.serverconfig.netmodel.credcache BOb
Re: svn Farm
Le 06/10/2010 17:06, Siva Kumar a écrit : I need to provide svn service to many small groups of students. I'am looking for a tool that would help industrialize managment of repositories. I don't want to issue hundreds of svn create, vi authz , edit ssh keys for svn+ssh access etc ... Are there such tools already existing ? Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill. good point ! I've installed and run it, looks good. but now I need to find a way to link my ldap users to svn roles/authz , I still can't find how to do that wihout creating csvn local accounts for all my users :-( ... !?
RE: svn Farm
Le 06/10/2010 17:06, Siva Kumar a écrit : I need to provide svn service to many small groups of students. I'am looking for a tool that would help industrialize managment of repositories. I don't want to issue hundreds of svn create, vi authz , edit ssh keys for svn+ssh access etc ... Are there such tools already existing ? Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill. good point ! I've installed and run it, looks good. but now I need to find a way to link my ldap users to svn roles/authz , I still can't find how to do that wihout creating csvn local accounts for all my users :-( ... !? Oh man, I thought edge did that for you and provided a web UI to set it up. Which is why I was considering moving to it when 1.7 came out. Not so? BOb
svn Farm
hello, I need to provide svn service to many small groups of students. I'am looking for a tool that would help industrialize managment of repositories. I don't want to issue hundreds of svn create, vi authz , edit ssh keys for svn+ssh access etc ... Are there such tools already existing ? FYI, - all my users are in a common ldap directory, - users will use both https and svn+ssh to acces repos - eventually, it would be great for http if we could benefit from our http SSO (jasig CAS). regards .
Re: svn Farm
I need to provide svn service to many small groups of students. I'am looking for a tool that would help industrialize managment of repositories. I don't want to issue hundreds of svn create, vi authz , edit ssh keys for svn+ssh access etc ... Are there such tools already existing ? Subversion Edge(http://www.open.collab.net/go/csvne2_r2a/) might fit your bill.
