Re: Where/How to get a Test Subversion Server
[Accidentally sent this just to Les: Les, sorry if you get two copies!] On Sun, Oct 30, 2011 at 3:04 PM, Les Mikesell wrote: > On Sun, Oct 30, 2011 at 1:26 PM, Nico Kadel-Garcia wrote: >> >> An ordinary newbie Subversion administrator *will not be aware* of >> these security issues. Precisely as you've shown, it's considered "not >> our problem" by the Subversion source developers. > > It's not that it is not subversion's problem, rather that it is every > application and file's problem on a system, and it is not reasonable > to include system-level security training into every application's > initial tutorial. > >>> If it hurts... >> >> Which we can successfully translate as "Not our problem". You then go >> on to give basically the same answer to the other three issues I >> raised. > > You misunderstand. It's as much every other application's problem as > subversion. No, it's *really* not. The use of HTTP/HTTPS access exposes the Subversion database to at least read, if not write access, to every other utility running under the "apache" user. Since many services tend to be published with equally "not our problem" security models, they all leave each other exposed. To turn the problem around, a poorly written "post-commit" script that does published and synchronized deployed software directories and which does using "rsync -a --delete workcopy/ /builddir/workcopy/" and doesn't handle target directories with spaces in the names carefully, could be triecked with branches with a traliing " " on the end.tricked into doing "rsync -a --delete workcopy / /builddir/workcopy /". And chaos would ensue. Sadly, I've seen something very much like this happen. (And I'm approaching NDA issues, so can't explain the magnitude of what happendd.) We were lucky we caught it early, but it was nasty. >> Unfortunately, security *IS* a big problem for source control systems, >> especially publicly exposed ones, and worse yet for ones where >> passwords may be stored in configuration data or passwords may be >> based on normal user login credentials. After all the hardwork and >> policy decisions to prevent any modification or deletion of old >> revisions, because source control is considered sancrosanct and once >> it's in source control, it should naver be modified, it violates the >> basic idea of provenance of that source control to leave it writable >> by others. > > By others? Why is having something writable by apache leaving it > writable by others? Apache has well-tested authentication mechanisms. > Is it subversion's problem if you don't use them to control access? When "$HOME/public_html" became a popular way for people to make http://hostname/~username/ accessible, and many sites enabled PHP scripting in those directories. Voila! Everything owned by apache is now writable by anyone with access to their home directory. Anytime you introduce server-side scripting to a web server, and especially when you introduce multiple applications on the web server, you expose them to each other's security issues. >> But that's "not our problem", right? You have to "trust your system", >> because "if they're on the system, you have bigger problems". I've >> been hearing that one a lot, for decades. > > Because it is undeniably true, and until you have accomplished that > part there is not much sense in wasting additional time on the > problem. If, for example, you chose or were bribed to corrupt the > systems you manage, what would stop you? And it's a great excuse for doing *nothing* about known and ongoing risks. >> It was and remains a common >> though fundamentally broken approach to security for many open source >> utilities. In particular, web-based services tend to put each other at >> risk by paying no attention to shared access to what should be >> distinct resources. > > Sharing resources securely is complicated. You have your choice of > dedicating hardware (or a VM) to a resource, or hiring a security > expert to analyze every change on a system that shares them. Which is > cheaper these days? But it really isn't subversion's problem if you > choose to allow unrelated logins and services on the same machine and > let them have write access to some of the same things. It is Subversion's problem because it is the default supported access. >> These sorts of issues are precisely why I only allow SSH key based >> access to a designated "svn" user account: that "svn" account is >> designated to repository ownership. It's also why Sourceforge does >> much the same thing, with different "users" for different >> repositories. We could explore how that's manageable, but it's a >> different subject. If Pietro or others are intersted, we could review >> it. > > Can you package this so it is reusable? And document proper > cross-platform care of the private side of the key (if there is such a > thing)? If so it would be a great addition to distribution > packaging. I've taken a few shots at it, but ran ou
Re: Where/How to get a Test Subversion Server
On Sun, Oct 30, 2011 at 1:26 PM, Nico Kadel-Garcia wrote: > > An ordinary newbie Subversion administrator *will not be aware* of > these security issues. Precisely as you've shown, it's considered "not > our problem" by the Subversion source developers. It's not that it is not subversion's problem, rather that it is every application and file's problem on a system, and it is not reasonable to include system-level security training into every application's initial tutorial. >> If it hurts... > > Which we can successfully translate as "Not our problem". You then go > on to give basically the same answer to the other three issues I > raised. You misunderstand. It's as much every other application's problem as subversion. > Unfortunately, security *IS* a big problem for source control systems, > especially publicly exposed ones, and worse yet for ones where > passwords may be stored in configuration data or passwords may be > based on normal user login credentials. After all the hardwork and > policy decisions to prevent any modification or deletion of old > revisions, because source control is considered sancrosanct and once > it's in source control, it should naver be modified, it violates the > basic idea of provenance of that source control to leave it writable > by others. By others? Why is having something writable by apache leaving it writable by others? Apache has well-tested authentication mechanisms. Is it subversion's problem if you don't use them to control access? > But that's "not our problem", right? You have to "trust your system", > because "if they're on the system, you have bigger problems". I've > been hearing that one a lot, for decades. Because it is undeniably true, and until you have accomplished that part there is not much sense in wasting additional time on the problem. If, for example, you chose or were bribed to corrupt the systems you manage, what would stop you? > It was and remains a common > though fundamentally broken approach to security for many open source > utilities. In particular, web-based services tend to put each other at > risk by paying no attention to shared access to what should be > distinct resources. Sharing resources securely is complicated. You have your choice of dedicating hardware (or a VM) to a resource, or hiring a security expert to analyze every change on a system that shares them. Which is cheaper these days?But it really isn't subversion's problem if you choose to allow unrelated logins and services on the same machine and let them have write access to some of the same things. > These sorts of issues are precisely why I only allow SSH key based > access to a designated "svn" user account: that "svn" account is > designated to repository ownership. It's also why Sourceforge does > much the same thing, with different "users" for different > repositories. We could explore how that's manageable, but it's a > different subject. If Pietro or others are intersted, we could review > it. Can you package this so it is reusable? And document proper cross-platform care of the private side of the key (if there is such a thing)? If so it would be a great addition to distribution packaging. -- Les Mikesell lesmikes...@gmail.com
RE: Where/How to get a Test Subversion Server
At last I've discovered how to get my first “svn.exe”, “svnadmin.exe”, ..., up and running. It was as simple as pie [better: trivial], once you knew it. I'll take good note of this experience and write it down into my of memories, when retired. Thank you all. - P.M.
Re: Where/How to get a Test Subversion Server
On Sun, Oct 30, 2011 at 12:26 PM, Les Mikesell wrote: > On Sat, Oct 29, 2011 at 11:27 PM, Nico Kadel-Garcia wrote: >>> >>> Yes, but the packaged linux versions pretty much just come up working >>> under http(s) with a appropriate line or two added to the packaged >>> configuration to point to the repository location, and once a network >>> server works, svnsync 'just works' to back it up from elsewhere. >> >> Les, I'm afraid that's handwaving. Like implementing Wikis and FTP >> sites, it leaves out the boobytraps. Let's look specifically at the >> HTTP setup. The one in Fedora 15's subversion-1.6.17 is pretty good, >> and I'm using it myself in the SRPM for 1.7.1 Unfortunately, it has >> the profound flaw that it explicitly recommends creating the >> repositories owned by the "apache" user. But this leaves not merely >> the Subversion database, but the *configuration* and hook scripts for >> the Subversion repository owned by the "apache" user, so any other PHP >> script or poorly secured services running on that HTTP server can edit >> *anything* in the Subversion repository, unmanaged by and unknown to >> the repository maintainer. > > So if it hurts, don't do that. It is hardly subversion's fault that > running other services under the same uid exposes all of those > services to more code that can be subverted - but you don't have to > run other services on the same machine and more specifically you don't > have to give people you don't trust administrative access to install > that code. This is turning into a security rant, a merry-go-round I've been on before for Subversion. In many setups, the "apache" user has only read access to the filesystem, including to /var/www/html and similar software repositories. In others, where additional access is needed, the ""suexec" utilities are workable. Unfortunately, for Subversion, suexec is not workable. (It relies on well-defined CGI utilities, and is incompatible with mod_dav.) It's possible to run a separate HTTP daemon on another port or a virtual IP address, but it's not well defined or supported. An ordinary newbie Subversion administrator *will not be aware* of these security issues. Precisely as you've shown, it's considered "not our problem" by the Subversion source developers. >> Worse, there are setups where both HTTP and >> SSH are used to access the same repository. And suddenly pre-commit >> and post-commit scripts can be manipulated by another HTTP "apache" >> owned process, and later get run if *root* comes in via SSH. > > If it hurts... Which we can successfully translate as "Not our problem". You then go on to give basically the same answer to the other three issues I raised. Unfortunately, security *IS* a big problem for source control systems, especially publicly exposed ones, and worse yet for ones where passwords may be stored in configuration data or passwords may be based on normal user login credentials. After all the hardwork and policy decisions to prevent any modification or deletion of old revisions, because source control is considered sancrosanct and once it's in source control, it should naver be modified, it violates the basic idea of provenance of that source control to leave it writable by others. But that's "not our problem", right? You have to "trust your system", because "if they're on the system, you have bigger problems". I've been hearing that one a lot, for decades. It was and remains a common though fundamentally broken approach to security for many open source utilities. In particular, web-based services tend to put each other at risk by paying no attention to shared access to what should be distinct resources. These sorts of issues are precisely why I only allow SSH key based access to a designated "svn" user account: that "svn" account is designated to repository ownership. It's also why Sourceforge does much the same thing, with different "users" for different repositories. We could explore how that's manageable, but it's a different subject. If Pietro or others are intersted, we could review it.
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 11:27 PM, Nico Kadel-Garcia wrote: >> >> Yes, but the packaged linux versions pretty much just come up working >> under http(s) with a appropriate line or two added to the packaged >> configuration to point to the repository location, and once a network >> server works, svnsync 'just works' to back it up from elsewhere. > > Les, I'm afraid that's handwaving. Like implementing Wikis and FTP > sites, it leaves out the boobytraps. Let's look specifically at the > HTTP setup. The one in Fedora 15's subversion-1.6.17 is pretty good, > and I'm using it myself in the SRPM for 1.7.1 Unfortunately, it has > the profound flaw that it explicitly recommends creating the > repositories owned by the "apache" user. But this leaves not merely > the Subversion database, but the *configuration* and hook scripts for > the Subversion repository owned by the "apache" user, so any other PHP > script or poorly secured services running on that HTTP server can edit > *anything* in the Subversion repository, unmanaged by and unknown to > the repository maintainer. So if it hurts, don't do that. It is hardly subversion's fault that running other services under the same uid exposes all of those services to more code that can be subverted - but you don't have to run other services on the same machine and more specifically you don't have to give people you don't trust administrative access to install that code. > Worse, there are setups where both HTTP and > SSH are used to access the same repository. And suddenly pre-commit > and post-commit scripts can be manipulated by another HTTP "apache" > owned process, and later get run if *root* comes in via SSH. If it hurts... > Looking this stuff up in Google, or in the Red Book for Subverson, is > not enough because the answers are incomplete. or disjoint, and often > contradictory The underlying and historically evident attitude is that > "security is your problem, you have to trust he machine you're working > on". Well the converse is certainly true and probably a much bigger issue. If administrative access and access to the underlying files aren't secure, all bets are off anyway and there are lots of ways for that to go wrong besides the ones you mentioned. > So summing up: simple "file:///" access is not going to properly > introduce you to these issues. In a way it does, since securing files (and keeping backups) underlies everything. -- Les Mikesell lesmikes...@gmail.com
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 9:56 PM, Les Mikesell wrote: > On Sat, Oct 29, 2011 at 5:51 PM, Nico Kadel-Garcia wrote: >> >>> Pretty much everything you can do with subversion will work with a >>> local repository and file:/// references. Do your initial >>> testing/learning that way, then decide what OS platform you want for >>> your server. I'd recommend a linux distribution where it would be >>> included in the standard system and updates, but that's a matter of >>> preference. You should not see any differences from the client side >>> regardless of the server platform. >> >> Except the vagaries of access control for svnserve, SSH, HTTP, HTTPS, >> or svn+ssh, and backup to a second server. These are in fact some of >> the most awkward features to negotiate in a shared enviornment. > > Yes, but the packaged linux versions pretty much just come up working > under http(s) with a appropriate line or two added to the packaged > configuration to point to the repository location, and once a network > server works, svnsync 'just works' to back it up from elsewhere. Les, I'm afraid that's handwaving. Like implementing Wikis and FTP sites, it leaves out the boobytraps. Let's look specifically at the HTTP setup. The one in Fedora 15's subversion-1.6.17 is pretty good, and I'm using it myself in the SRPM for 1.7.1 Unfortunately, it has the profound flaw that it explicitly recommends creating the repositories owned by the "apache" user. But this leaves not merely the Subversion database, but the *configuration* and hook scripts for the Subversion repository owned by the "apache" user, so any other PHP script or poorly secured services running on that HTTP server can edit *anything* in the Subversion repository, unmanaged by and unknown to the repository maintainer. Worse, there are setups where both HTTP and SSH are used to access the same repository. And suddenly pre-commit and post-commit scripts can be manipulated by another HTTP "apache" owned process, and later get run if *root* comes in via SSH. And *THAT* is a disaster waiting to happen Looking this stuff up in Google, or in the Red Book for Subverson, is not enough because the answers are incomplete. or disjoint, and often contradictory The underlying and historically evident attitude is that "security is your problem, you have to trust he machine you're working on". So summing up: simple "file:///" access is not going to properly introduce you to these issues.
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 5:51 PM, Nico Kadel-Garcia wrote: > >> Pretty much everything you can do with subversion will work with a >> local repository and file:/// references. Do your initial >> testing/learning that way, then decide what OS platform you want for >> your server. I'd recommend a linux distribution where it would be >> included in the standard system and updates, but that's a matter of >> preference. You should not see any differences from the client side >> regardless of the server platform. > > Except the vagaries of access control for svnserve, SSH, HTTP, HTTPS, > or svn+ssh, and backup to a second server. These are in fact some of > the most awkward features to negotiate in a shared enviornment. Yes, but the packaged linux versions pretty much just come up working under http(s) with a appropriate line or two added to the packaged configuration to point to the repository location, and once a network server works, svnsync 'just works' to back it up from elsewhere. -- Les Mikesell lesmikes...@gmail.com
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 2:03 PM, Les Mikesell wrote: > On Sat, Oct 29, 2011 at 12:07 PM, Pietro Moras wrote: >> In need of breaking the initial ice with Subversion, I wonder if you have >> any real knowledge of a Test Subversion Repository/Server where to start >> understanding, hands-on, what it's all about. >> >> Anyhow, these are the related generic—and, so far, untested—hints I've >> already collected: >> >> -- Redbean book >> >> -- CollabNet >> >> -- Subversion Edge >> >> -- Trial Subversion server at: SpringLoops.com, Beanstalkapp.com >> >> -- GUI client TortoiseSVN >> >> That said in case you know any better. > > Pretty much everything you can do with subversion will work with a > local repository and file:/// references. Do your initial > testing/learning that way, then decide what OS platform you want for > your server. I'd recommend a linux distribution where it would be > included in the standard system and updates, but that's a matter of > preference. You should not see any differences from the client side > regardless of the server platform. Except the vagaries of access control for svnserve, SSH, HTTP, HTTPS, or svn+ssh, and backup to a second server. These are in fact some of the most awkward features to negotiate in a shared enviornment.
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 01:40:11PM -0700, Geoff Hoffman wrote: > Sort of off topic of this thread, but even though I've used SVN for years, > the idea of running it locally without a server never occurred to me. I > thought 'distributed repositories' was Git's only/main benefit over SVN, > but if you have a local repository, I'm guessing you can work/commit > locally, then svn switch to your remote/work repository to commit to the > shared/compay repo? Is that right? No. In Subversion, revision numbers are per-repository. Your local repository has a distinct revision number space from the shared/company repository. So each repository is its own universe. In Git revisions are global across multiple repositories. A universe is made up of a number of repositories, each cloned from one another. The file:// access method is intended for testing purposes mostly. Though nothing prevents you from working with a repository locally via file:// for a while, and later network this same repository to the world, for instance via https.
Re: Where/How to get a Test Subversion Server
Try this on a Unix-like system: cd ~ svnadmin create /myrepo svn checkout file:///myrepo When you're done playing, rm -rf /myrepo rm -rf ~/myrepo - Original Message - From: Les Mikesell Sent: 10/30/11 04:03 AM To: Pietro Moras Subject: Re: Where/How to get a Test Subversion Server On Sat, Oct 29, 2011 at 12:07 PM, Pietro Moras wrote: > In need of breaking the initial ice with Subversion, I wonder if you have > any real knowledge of a Test Subversion Repository/Server where to start > understanding, hands-on, what it's all about. > > Anyhow, these are the related generic—and, so far, untested—hints I've > already collected: > > -- Redbean book > > -- CollabNet > > -- Subversion Edge > > -- Trial Subversion server at: SpringLoops.com, Beanstalkapp.com > > -- GUI client TortoiseSVN > > That said in case you know any better. Pretty much everything you can do with subversion will work with a local repository and file:/// references. Do your initial testing/learning that way, then decide what OS platform you want for your server. I'd recommend a linux distribution where it would be included in the standard system and updates, but that's a matter of preference. You should not see any differences from the client side regardless of the server platform. -- Les Mikesell lesmikes...@gmail.com
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 10:52 AM, Stefan Sperling wrote: > There is no need to set up a server to try out Subversion. > On Sat, Oct 29, 2011 at 11:03 AM, Les Mikesell wrote: > > Pretty much everything you can do with subversion will work with a > local repository and file:/// references. Do your initial > testing/learning that way Sort of off topic of this thread, but even though I've used SVN for years, the idea of running it locally without a server never occurred to me. I thought 'distributed repositories' was Git's only/main benefit over SVN, but if you have a local repository, I'm guessing you can work/commit locally, then svn switch to your remote/work repository to commit to the shared/compay repo? Is that right?
Re: Where/How to get a Test Subversion Server
>> In need of breaking the >> initial ice with Subversion, I wonder if you have any real knowledge >> of a Test Subversion Repository/Server where to start understanding, >> hands-on, what it's all about. > > There is no need to set up a server to try out Subversion. > > Install TortoiseSVN 1.7.1. Create a new directory C\:repos. > Right-click on that directory, pick "TortoiseSVN->Create repository here" > > This gives you a repository to play with on the local machine. > You can access it with TortoiseSVN, and other clients, with this URL: > file:///C:/repos But IF You want to test client-server way of working, be sure to select command line tools during TortoiseSvn install. Then You can create a bat file with svnserve -d -r c:\repos and when that is started, connect to server with URL svn://localhost/ Keep in mind that anyone can access the repository if they know your host/ip and can reach to it from their computer (I.e. whole internet if there is no firewall/NAT in between), so some access or firewall configuration might be needed. It is pretty easy to install svnserve as windows service also, so basically You just need TortoiseSVN to have a full set of svn server/client software. Gert
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 12:07 PM, Pietro Moras wrote: > In need of breaking the initial ice with Subversion, I wonder if you have > any real knowledge of a Test Subversion Repository/Server where to start > understanding, hands-on, what it's all about. > > Anyhow, these are the related generic—and, so far, untested—hints I've > already collected: > > -- Redbean book > > -- CollabNet > > -- Subversion Edge > > -- Trial Subversion server at: SpringLoops.com, Beanstalkapp.com > > -- GUI client TortoiseSVN > > That said in case you know any better. Pretty much everything you can do with subversion will work with a local repository and file:/// references. Do your initial testing/learning that way, then decide what OS platform you want for your server. I'd recommend a linux distribution where it would be included in the standard system and updates, but that's a matter of preference. You should not see any differences from the client side regardless of the server platform. -- Les Mikesell lesmikes...@gmail.com
Re: Where/How to get a Test Subversion Server
On Sat, Oct 29, 2011 at 05:07:13PM +, Pietro Moras wrote: > In need of breaking the > initial ice with Subversion, I wonder if you have any real knowledge > of a Test Subversion Repository/Server where to start understanding, > hands-on, what it's all about. > > Anyhow, these are the related generic—and, so far, untested—hints I've > already collected: -- Redbean book -- CollabNet -- Subversion Edge -- Trial > Subversion > server at: SpringLoops.com, Beanstalkapp.com -- GUI client > TortoiseSVNThat said in case you know any better. Thank you. - P.M. > There is no need to set up a server to try out Subversion. Install TortoiseSVN 1.7.1. Create a new directory C\:repos. Right-click on that directory, pick "TortoiseSVN->Create repository here" This gives you a repository to play with on the local machine. You can access it with TortoiseSVN, and other clients, with this URL: file:///C:/repos Please read Chapter 2 of the red-bean book before proceeding. It explains the basics quite well.
Where/How to get a Test Subversion Server
In need of breaking the initial ice with Subversion, I wonder if you have any real knowledge of a Test Subversion Repository/Server where to start understanding, hands-on, what it's all about. Anyhow, these are the related generic—and, so far, untested—hints I've already collected: -- Redbean book -- CollabNet -- Subversion Edge -- Trial Subversion server at: SpringLoops.com, Beanstalkapp.com -- GUI client TortoiseSVNThat said in case you know any better. Thank you. - P.M.