On Tue, Jan 4, 2011 at 4:56 PM, Daniel Becroft <djcbecroft_at_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. 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,
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.
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.
Received on 2011-01-05 03:31:48 CET