On Sat, Oct 29, 2011 at 9:56 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Sat, Oct 29, 2011 at 5:51 PM, Nico Kadel-Garcia <nkadel_at_gmail.com> 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.
Received on 2011-10-30 05:28:29 CET