You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Pietro Moras <st...@hotmail.com> on 2011/10/29 19:07:13 UTC
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.
RE: Where/How to get a Test Subversion Server
Posted by Pietro Moras <st...@hotmail.com>.
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
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
[Accidentally sent this just to Les: Les, sorry if you get two copies!]
On Sun, Oct 30, 2011 at 3:04 PM, Les Mikesell <le...@gmail.com> wrote:
> On Sun, Oct 30, 2011 at 1:26 PM, Nico Kadel-Garcia <nk...@gmail.com> 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 out of resources. I tried to
port the "gitosis" package, but got bogged down, and spent time on RPM
building instead.
Re: Where/How to get a Test Subversion Server
Posted by Les Mikesell <le...@gmail.com>.
On Sun, Oct 30, 2011 at 1:26 PM, Nico Kadel-Garcia <nk...@gmail.com> 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
lesmikesell@gmail.com
Re: Where/How to get a Test Subversion Server
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sun, Oct 30, 2011 at 12:26 PM, Les Mikesell <le...@gmail.com> wrote:
> On Sat, Oct 29, 2011 at 11:27 PM, Nico Kadel-Garcia <nk...@gmail.com> 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
Posted by Les Mikesell <le...@gmail.com>.
On Sat, Oct 29, 2011 at 11:27 PM, Nico Kadel-Garcia <nk...@gmail.com> 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
lesmikesell@gmail.com
Re: Where/How to get a Test Subversion Server
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Oct 29, 2011 at 9:56 PM, Les Mikesell <le...@gmail.com> wrote:
> On Sat, Oct 29, 2011 at 5:51 PM, Nico Kadel-Garcia <nk...@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.
Re: Where/How to get a Test Subversion Server
Posted by Les Mikesell <le...@gmail.com>.
On Sat, Oct 29, 2011 at 5:51 PM, Nico Kadel-Garcia <nk...@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 Mikesell
lesmikesell@gmail.com
Re: Where/How to get a Test Subversion Server
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Sat, Oct 29, 2011 at 2:03 PM, Les Mikesell <le...@gmail.com> wrote:
> On Sat, Oct 29, 2011 at 12:07 PM, Pietro Moras <st...@hotmail.com> 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
Posted by Les Mikesell <le...@gmail.com>.
On Sat, Oct 29, 2011 at 12:07 PM, Pietro Moras <st...@hotmail.com> 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
lesmikesell@gmail.com
Re: Where/How to get a Test Subversion Server
Posted by Stefan Sperling <st...@elego.de>.
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
Posted by Geoff Hoffman <gh...@cardinalpath.com>.
On Sat, Oct 29, 2011 at 10:52 AM, Stefan Sperling <st...@elego.de> 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 <le...@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
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
Posted by Gert Kello <ge...@gmail.com>.
>> 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
Posted by Stefan Sperling <st...@elego.de>.
On Sat, Oct 29, 2011 at 05:07:13PM +0000, 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.