On Wed, Jan 5, 2011 at 12:31 PM, Nico Kadel-Garcia <nka...@gmail.com>wrote:
> On Tue, Jan 4, 2011 at 4:56 PM, Daniel Becroft <djcbecr...@gmail.com> > wrote: > > > svnadmin create .\repository > > svnserve -r . > > > > and a repository is created and served via svnserve. With the above > > defaults, a third step is required, which can get tedious. I'd propose > > enabling svnserve by default, and it can then be disabled if required. > This > > also maintains the ease of creating test scripts to try and reproduce > > issues. > > It's *too* easy. And that's a problem .... why? > Since the default svnserve.conf is very permissive, > and because default svnserve is on an unprivileged port so any user > can serve anyone else's "readable" repository to outside access, > The port that it runs on by default is irrelevant. svnserve can be started to run on 'any' open port, so why does the default port matter? If someone wanted to, they could run svnserve on port 80. > without the original author's knowledge or explicit consent. The > default permissions of "svnadmin create" and "svnadmin hotcopy" are > much too permissive, and the concatenation of separate "the admin > should set these if they want" options creates a quite noticeable > security risk. > I think the notion of "too permissive" is the problem. My definition is going to be different from yours, which is going to be different to the man on the corner. I don't have an issue with adding something to lock down a given repository from not being served by svnserve, but I'm questing why it should be restricted _by default_. As a user, if I wanted to try using SVN for the first time, the simpler it is to setup a repository and use it, the better. And, as I mentioned before, this is also applicable when creating and destroying sandpit repositories to reproduce bugs or test ideas. All I'm asking for, is that 'svnadmin create' (both with and without this proposed change) should create a repository that can be served using the provided svnserve, without modifying any configuration files. Add a new configuration file, or new command-line options to switch it off, but leave the default alone. > Stefan's more sophisticated "let's set up a configuration file that > restricts forms of access" is interesting, but would be at least 2 > years away from release given the burden of other critical issues in > subversion-1.7 planned changes, and would be awkward to backport to > "enterprise" systems such as the extremely out of date > subversion-1.4.x on RHEL 5. >
