subversion binaries should be replaced through wrapper scripts to prevent users of keep on screwing their repositories

[Debian Bug Importer]

Automatically imported from Debian bug report #282468 http://bugs.debian.org/282468

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #282468 http://bugs.debian.org/282468

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Mon, 22 Nov 2004 12:28:59 +0100
From: Wilfried Goesgens <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: subversion binaries should be replaced through wrapper scripts to prevent
 users of keep on screwing their repositories

Package: subversion
Version: 1.0.9-2
Severity: serious

as the subversion book states, one should create a wrapper script
arround the subversion binaries to keep them from screwing the berkley
db and their file permission.

My scripts look like this one (as suggested in the svn book)

#!/bin/bash
umask 002
/usr/bin/svnadmin.real $@

I don't think, this hurts other access methods, but is essential for
several people working on a repository with svn+ssh/..../....

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.6
Locale: LANG=C, LC_CTYPE=C

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-17 Berkeley v4.2 Database Utilities
ii libapr0 2.0.52-1 The Apache Portable Runtime
ii libc6 2.3.2.ds1-16 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-17 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.6-8 XML parsing C library - runtime li
ii libldap2 2.1.30-3 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-0.2 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7d-4 SSL shared libraries
ii libsvn0 1.0.9-2 Shared libraries used by Subversio
ii libxml2 2.6.11-3 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.1.1-7 compression library - runtime

-- no debconf information

[Colin Watson (cjwatson)]

This is a local configuration issue; the subversion package can't hope to know
in advance how repository permissions are set up. In any case, I believe
Subversion 1.1's fsfs repository format fixes this.

[Adrian von Bidder (avbidder)]

On Monday 22 November 2004 12.28, Wilfried Goesgens wrote:
> Package: subversion
> Version: 1.0.9-2
> Severity: serious
>
>
> as the subversion book states, one should create a wrapper script
> arround the subversion binaries to keep them from screwing the berkley
> db and their file permission.

I think this is a bug in subversion - the svn binary should take care about
this, and not require a wrapper script.

if (db is g+w) { umask 002 }

and the problem would go away.

wrapper scripts are ugly and error prone and should, imho be avoided in
almost all cases.

-- vbi

--
TODO: apt-get install signify

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 23 Nov 2004 09:29:12 +0100
From: Adrian 'Dagurashibanipal' von Bidder <email address hidden>
To: <email address hidden>
Subject: Re: Bug#282468: subversion binaries should be replaced through wrapper scripts to prevent
 users of keep on screwing their repositories

--nextPart4809395.GSzdyePbF8
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday 22 November 2004 12.28, Wilfried Goesgens wrote:
> Package: subversion
> Version: 1.0.9-2
> Severity: serious
>
>
> as the subversion book states, one should create a wrapper script
> arround the subversion binaries to keep them from screwing the berkley
> db and their file permission.

I think this is a bug in subversion - the svn binary should take care about=
=20
this, and not require a wrapper script.

if (db is g+w) { umask 002 }

and the problem would go away.

wrapper scripts are ugly and error prone and should, imho be avoided in=20
almost all cases.

=2D- vbi

=2D-=20
TODO: apt-get install signify

--nextPart4809395.GSzdyePbF8
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: get my key from http://fortytwo.ch/gpg/92082481

iKcEABECAGcFAkGi9N1gGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6UzkAoKTkygXwFNYsnQkcoLipY1hA
G2HHAJ92IRFpdQwxG163gUclZzfIr1s0gg==
=39+E
-----END PGP SIGNATURE-----

--nextPart4809395.GSzdyePbF8--

[Philip Martin (philip-codematters)]

Adrian 'Dagurashibanipal' von Bidder <email address hidden> writes:

> On Monday 22 November 2004 12.28, Wilfried Goesgens wrote:
>> Package: subversion
>> Version: 1.0.9-2
>> Severity: serious
>>
>> as the subversion book states, one should create a wrapper script
>> arround the subversion binaries to keep them from screwing the berkley
>> db and their file permission.
>
> I think this is a bug in subversion - the svn binary should take care about
> this, and not require a wrapper script.

The problem with forcing umask to 002 (whether by wrappers or in the
binaries) is that it could be considered a security bug as it means a
user may inadvertently allow group write access to repositories that
should be private. It's quite likely that someone would raise a
release-critical bug demanding that their chosen umask be respected
and not forced to 002.

Even if the umask is forced to 002 problems will still arise if the
repository is accessed by some other method e.g. httpd via mod_dav_svn
or python via the bindings.

The non-BDB backend in Subversion 1.1 propogates repository
permissions to new files as such files are created by Subversion
directly.

--
Philip Martin

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 23 Nov 2004 20:38:59 +0000
From: Philip Martin <email address hidden>
To: Adrian 'Dagurashibanipal' von Bidder <email address hidden>
Cc: <email address hidden>, Wilfried Goesgens <email address hidden>
Subject: Re: Bug#282468: subversion binaries should be replaced through
 wrapper scripts to prevent users of keep on screwing their repositories

Adrian 'Dagurashibanipal' von Bidder <email address hidden> writes:

> On Monday 22 November 2004 12.28, Wilfried Goesgens wrote:
>> Package: subversion
>> Version: 1.0.9-2
>> Severity: serious
>>
>> as the subversion book states, one should create a wrapper script
>> arround the subversion binaries to keep them from screwing the berkley
>> db and their file permission.
>
> I think this is a bug in subversion - the svn binary should take care about
> this, and not require a wrapper script.

The problem with forcing umask to 002 (whether by wrappers or in the
binaries) is that it could be considered a security bug as it means a
user may inadvertently allow group write access to repositories that
should be private. It's quite likely that someone would raise a
release-critical bug demanding that their chosen umask be respected
and not forced to 002.

Even if the umask is forced to 002 problems will still arise if the
repository is accessed by some other method e.g. httpd via mod_dav_svn
or python via the bindings.

The non-BDB backend in Subversion 1.1 propogates repository
permissions to new files as such files are created by Subversion
directly.

--
Philip Martin

[Adrian von Bidder (avbidder)]

On Tuesday 23 November 2004 21.38, Philip Martin wrote:
> Adrian 'Dagurashibanipal' von Bidder <email address hidden> writes:
> > On Monday 22 November 2004 12.28, Wilfried Goesgens wrote:
> >> Package: subversion
> >> Version: 1.0.9-2
> >> Severity: serious
> >>
> >> as the subversion book states, one should create a wrapper script
> >> arround the subversion binaries to keep them from screwing the berkley
> >> db and their file permission.
> >
> > I think this is a bug in subversion - the svn binary should take care
> > about this, and not require a wrapper script.
>
> The problem with forcing umask to 002 (whether by wrappers or in the
> binaries) is that it could be considered a security bug as it means a
> user may inadvertently allow group write access to repositories that
> should be private.

That's why my pseudocode reads:

> > if (db is g+w) { umask 002 }

So, no private repositories will become group writable just so.

> The non-BDB backend in Subversion 1.1 propogates repository
> permissions to new files as such files are created by Subversion
> directly.

For me, as subversion users, files in the db are 'created by subversion
directly', too. As a user, I regard svn as a black box, and when I set the
subversion repository g+w, svn has no business messing around with this.

Same goes for the group ownership - new files should be created with the
same group as the other files in the repository.

There's no security issue that I can see here: all that happens is that new
files get the same ownership and permissions as the existing files, no
access permission is given that does not already exist.

Imagine an editor which would save files with permissions & ~umask after
every edit, and change group ownership to whatever is the default group of
the current user.

greetings
-- vbi

--
TODO: apt-get install signify

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 24 Nov 2004 08:40:13 +0100
From: Adrian 'Dagurashibanipal' von Bidder <email address hidden>
To: Philip Martin <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#282468: subversion binaries should be replaced through wrapper scripts to prevent
 users of keep on screwing their repositories

--nextPart1389794.hRnnf5KygB
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 23 November 2004 21.38, Philip Martin wrote:
> Adrian 'Dagurashibanipal' von Bidder <email address hidden> writes:
> > On Monday 22 November 2004 12.28, Wilfried Goesgens wrote:
> >> Package: subversion
> >> Version: 1.0.9-2
> >> Severity: serious
> >>
> >> as the subversion book states, one should create a wrapper script
> >> arround the subversion binaries to keep them from screwing the berkley
> >> db and their file permission.
> >
> > I think this is a bug in subversion - the svn binary should take care
> > about this, and not require a wrapper script.
>
> The problem with forcing umask to 002 (whether by wrappers or in the
> binaries) is that it could be considered a security bug as it means a
> user may inadvertently allow group write access to repositories that
> should be private.

That's why my pseudocode reads:

> > if (db is g+w) { umask 002 }

So, no private repositories will become group writable just so.

> The non-BDB backend in Subversion 1.1 propogates repository
> permissions to new files as such files are created by Subversion
> directly.

=46or me, as subversion users, files in the db are 'created by subversion=20
directly', too. As a user, I regard svn as a black box, and when I set the=
=20
subversion repository g+w, svn has no business messing around with this.

Same goes for the group ownership - new files should be created with the=20
same group as the other files in the repository.

There's no security issue that I can see here: all that happens is that new=
=20
files get the same ownership and permissions as the existing files, no=20
access permission is given that does not already exist.

Imagine an editor which would save files with permissions & ~umask after=20
every edit, and change group ownership to whatever is the default group of=
=20
the current user.

greetings
=2D- vbi

=2D-=20
TODO: apt-get install signify

--nextPart1389794.hRnnf5KygB
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: get my key from http://fortytwo.ch/gpg/92082481

iKcEABECAGcFAkGkOuJgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h
aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw
NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6WbYAoKH8ORRlE/+HtwPhCBrlNFMz
d6QhAJ4hu9H2ZXbxseUXR6Fa/DtBi27MXA==
=ttG4
-----END PGP SIGNATURE-----

--nextPart1389794.hRnnf5KygB--

[Steve Langasek (vorlon)]

# not a policy violation that I can see, and not an issue that makes
# subversion unusable
severity 282468 important
thanks

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 27 Nov 2004 22:42:57 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: Downgrading

# not a policy violation that I can see, and not an issue that makes
# subversion unusable
severity 282468 important
thanks

[Charles Fry (debian-frogcircus)]

Package: subversion
Version: 1.0.9-2
Followup-For: Bug #282468

I agree that this is very important.

Even if the scripts aren't wrapped by default (although I don't
personally see that as being a problem), debconf should at least provide
the option of wrapping the scripts.

Charles

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (90, 'testing'), (80, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1um
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-17 Berkeley v4.2 Database Utilities
ii libapr0 2.0.52-3 The Apache Portable Runtime
ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-17 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.8-1 XML parsing C library - runtime li
ii libldap2 2.1.30-3 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-0.2 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7e-2 SSL shared libraries
ii libsvn0 1.0.9-2 Shared libraries used by Subversio
ii libxml2 2.6.11-5 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.2-3 compression library - runtime

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 21 Jan 2005 21:07:58 -0500
From: Charles Fry <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: subversion: at least have wrapper option

Package: subversion
Version: 1.0.9-2
Followup-For: Bug #282468

I agree that this is very important.

Even if the scripts aren't wrapped by default (although I don't
personally see that as being a problem), debconf should at least provide
the option of wrapping the scripts.

Charles

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (90, 'testing'), (80, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1um
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-17 Berkeley v4.2 Database Utilities
ii libapr0 2.0.52-3 The Apache Portable Runtime
ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-17 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.8-1 XML parsing C library - runtime li
ii libldap2 2.1.30-3 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-0.2 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7e-2 SSL shared libraries
ii libsvn0 1.0.9-2 Shared libraries used by Subversio
ii libxml2 2.6.11-5 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.2-3 compression library - runtime

-- no debconf information

[John McCutchan (ttb)]

Package: subversion
Version: 1.1.4-1
Followup-For: Bug #282468

This really needs to be done. It is a huge pain, and everytime the
packages get updated, I have to re-fix this. Please convert all svn
binaries to wrapper scripts that set the proper umask.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-18 Berkeley v4.2 Database Utilities
ii libapr0 2.0.54-2 the Apache Portable Runtime
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.8-3 XML parsing C library - runtime li
ii libldap2 2.1.30-6 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-1 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7e-3 SSL shared libraries
ii libsvn0 1.1.4-1 shared libraries used by Subversio
ii libxml2 2.6.16-7 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.2-4 compression library - runtime

-- no debconf information

[Florian Weimer (fw)]

* John McCutchan:

> This really needs to be done. It is a huge pain, and everytime the
> packages get updated, I have to re-fix this. Please convert all svn
> binaries to wrapper scripts that set the proper umask.

What is the proper umask? It's different for different people. Can't
you use the FSFS backend and set proper repository permissions so that
the umask doesn't matter?

[John McCutchan (ttb)]

On Mon, 2005-04-25 at 08:50 +0200, Florian Weimer wrote:
> What is the proper umask? It's different for different people. Can't
> you use the FSFS backend and set proper repository permissions so that
> the umask doesn't matter?

The proper umask is 002. That might not work for EVERYONE, but for the
vast majority 002 is correct. I did not know about FSFS backend, I will
look into it. Maybe the FSFS backend should be made default for Debian?

--
John McCutchan <email address hidden>

[Florian Weimer (fw)]

* John McCutchan:

> On Mon, 2005-04-25 at 08:50 +0200, Florian Weimer wrote:
>> What is the proper umask? It's different for different people. Can't
>> you use the FSFS backend and set proper repository permissions so that
>> the umask doesn't matter?
>
> The proper umask is 002.

Even if adduser/homedir-permission is true?

> That might not work for EVERYONE, but for the vast majority 002 is
> correct.

So why it's not the system default? 8-)

[John McCutchan (ttb)]

On Tue, 2005-04-26 at 09:00 +0200, Florian Weimer wrote:
> * John McCutchan:
>
> > On Mon, 2005-04-25 at 08:50 +0200, Florian Weimer wrote:
> >> What is the proper umask? It's different for different people. Can't
> >> you use the FSFS backend and set proper repository permissions so that
> >> the umask doesn't matter?
> >
> > The proper umask is 002.
>
> Even if adduser/homedir-permission is true?

Huh?

>
> > That might not work for EVERYONE, but for the vast majority 002 is
> > correct.
>
> So why it's not the system default? 8-)

Because what works best for /svnroot doesn't work best for all
directories!

--
John McCutchan <email address hidden>

[Michal Pasternak (michal-pasternak)]

Package: subversion
Version: 1.1.4-2
Followup-For: Bug #282468

I vote for this bug. Without wrapper scripts it is pretty hard (and, from a
practical point of view: _impossible_) to use subversion repository, as
everything breaks, due to wrong chmod.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10booyaka
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-2) (ignored: LC_ALL set to pl_PL.ISO8859-2)

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-18 Berkeley v4.2 Database Utilities
ii libapr0 2.0.54-4 the Apache Portable Runtime
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.8-3 XML parsing C library - runtime li
ii libldap2 2.1.30-7 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-2 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7g-1 SSL shared libraries
ii libsvn0 1.1.4-2 shared libraries used by Subversio
ii libxml2 2.6.16-7 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.2-4 compression library - runtime

-- no debconf information

[Florian Weimer (fw)]

* Michal Pasternak:

> I vote for this bug. Without wrapper scripts it is pretty hard (and, from a
> practical point of view: _impossible_) to use subversion repository, as
> everything breaks, due to wrong chmod.

Please investigate the FSFS backend, with proper directory permissions
(i.e. GID inheritance).

Sharing Berkeley DB repositories likely introduces security
vulnerabilities.

[Debian Bug Importer (debzilla)]

Message-Id: <E1DPszj-00035n-00@vertex>
Date: Sun, 24 Apr 2005 22:06:43 -0400
From: John McCutchan <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: subversion: second

Package: subversion
Version: 1.1.4-1
Followup-For: Bug #282468

This really needs to be done. It is a huge pain, and everytime the
packages get updated, I have to re-fix this. Please convert all svn
binaries to wrapper scripts that set the proper umask.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.11.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-18 Berkeley v4.2 Database Utilities
ii libapr0 2.0.54-2 the Apache Portable Runtime
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.8-3 XML parsing C library - runtime li
ii libldap2 2.1.30-6 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-1 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7e-3 SSL shared libraries
ii libsvn0 1.1.4-1 shared libraries used by Subversio
ii libxml2 2.6.16-7 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.2-4 compression library - runtime

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 25 Apr 2005 08:50:21 +0200
From: Florian Weimer <email address hidden>
To: John McCutchan <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#282468: subversion: second

* John McCutchan:

> This really needs to be done. It is a huge pain, and everytime the
> packages get updated, I have to re-fix this. Please convert all svn
> binaries to wrapper scripts that set the proper umask.

What is the proper umask? It's different for different people. Can't
you use the FSFS backend and set proper repository permissions so that
the umask doesn't matter?

[Debian Bug Importer (debzilla)]

Message-Id: <1114448005.11732.3.camel@vertex>
Date: Mon, 25 Apr 2005 12:53:25 -0400
From: John McCutchan <email address hidden>
To: Florian Weimer <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#282468: subversion: second

On Mon, 2005-04-25 at 08:50 +0200, Florian Weimer wrote:
> What is the proper umask? It's different for different people. Can't
> you use the FSFS backend and set proper repository permissions so that
> the umask doesn't matter?

The proper umask is 002. That might not work for EVERYONE, but for the
vast majority 002 is correct. I did not know about FSFS backend, I will
look into it. Maybe the FSFS backend should be made default for Debian?

--
John McCutchan <email address hidden>

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 26 Apr 2005 09:00:51 +0200
From: Florian Weimer <email address hidden>
To: John McCutchan <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#282468: subversion: second

* John McCutchan:

> On Mon, 2005-04-25 at 08:50 +0200, Florian Weimer wrote:
>> What is the proper umask? It's different for different people. Can't
>> you use the FSFS backend and set proper repository permissions so that
>> the umask doesn't matter?
>
> The proper umask is 002.

Even if adduser/homedir-permission is true?

> That might not work for EVERYONE, but for the vast majority 002 is
> correct.

So why it's not the system default? 8-)

[Debian Bug Importer (debzilla)]

Message-Id: <1114527199.30864.0.camel@vertex>
Date: Tue, 26 Apr 2005 10:53:19 -0400
From: John McCutchan <email address hidden>
To: Florian Weimer <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#282468: subversion: second

On Tue, 2005-04-26 at 09:00 +0200, Florian Weimer wrote:
> * John McCutchan:
>
> > On Mon, 2005-04-25 at 08:50 +0200, Florian Weimer wrote:
> >> What is the proper umask? It's different for different people. Can't
> >> you use the FSFS backend and set proper repository permissions so that
> >> the umask doesn't matter?
> >
> > The proper umask is 002.
>
> Even if adduser/homedir-permission is true?

Huh?

>
> > That might not work for EVERYONE, but for the vast majority 002 is
> > correct.
>
> So why it's not the system default? 8-)

Because what works best for /svnroot doesn't work best for all
directories!

--
John McCutchan <email address hidden>

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 19 May 2005 06:00:20 +0200
From: Michal Pasternak <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: subversion: Wrapper scripts are a must.

Package: subversion
Version: 1.1.4-2
Followup-For: Bug #282468

I vote for this bug. Without wrapper scripts it is pretty hard (and, from a
practical point of view: _impossible_) to use subversion repository, as
everything breaks, due to wrong chmod.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10booyaka
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-2) (ignored: LC_ALL set to pl_PL.ISO8859-2)

Versions of packages subversion depends on:
ii db4.2-util 4.2.52-18 Berkeley v4.2 Database Utilities
ii libapr0 2.0.54-4 the Apache Portable Runtime
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [
ii libexpat1 1.95.8-3 XML parsing C library - runtime li
ii libldap2 2.1.30-7 OpenLDAP libraries
ii libneon24 0.24.7.dfsg-2 An HTTP and WebDAV client library
ii libssl0.9.7 0.9.7g-1 SSL shared libraries
ii libsvn0 1.1.4-2 shared libraries used by Subversio
ii libxml2 2.6.16-7 GNOME XML library
ii patch 2.5.9-2 Apply a diff file to an original
ii zlib1g 1:1.2.2-4 compression library - runtime

-- no debconf information

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 19 May 2005 15:20:07 +0200
From: Florian Weimer <email address hidden>
To: Michal Pasternak <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#282468: subversion: Wrapper scripts are a must.

* Michal Pasternak:

> I vote for this bug. Without wrapper scripts it is pretty hard (and, from a
> practical point of view: _impossible_) to use subversion repository, as
> everything breaks, due to wrong chmod.

Please investigate the FSFS backend, with proper directory permissions
(i.e. GID inheritance).

Sharing Berkeley DB repositories likely introduces security
vulnerabilities.

[Max Bowsher (maxb-ukf)]

severity 242368 important
merge 282468 242368 259226
stop

I don't really agree with the severity raise, I'm just setting a uniform
severity so I can merge the bugs

Max.

[Max Bowsher (maxb-ukf)]

severity 292358 important
merge 282468 242368 259226 292358
stop

I don't really agree with the severity raise, I'm just setting a uniform
severity so I can merge the bugs

Max.

[Debian Bug Importer (debzilla)]

Message-ID: <0ddd01c5c8c7$bbfaa560$5304a8c0@chimaera>
Date: Tue, 4 Oct 2005 10:41:01 +0100
From: "Max Bowsher" <email address hidden>
To: <email address hidden>
Subject:

severity 242368 important
merge 282468 242368 259226
stop

I don't really agree with the severity raise, I'm just setting a uniform
severity so I can merge the bugs

Max.

[Debian Bug Importer (debzilla)]

Message-ID: <0df101c5c8c9$d5904230$5304a8c0@chimaera>
Date: Tue, 4 Oct 2005 10:56:03 +0100
From: "Max Bowsher" <email address hidden>
To: <email address hidden>
Subject:

severity 292358 important
merge 282468 242368 259226 292358
stop

I don't really agree with the severity raise, I'm just setting a uniform
severity so I can merge the bugs

Max.

[Peters-guest (peters-guest)]

tags 242368 pending
tags 259226 pending
tags 282468 pending
tags 292358 pending
thanks

Author: peters-guest
Date: 2006-04-21 09:10:45 +0000 (Fri, 21 Apr 2006)
New Revision: 557

Added:
   trunk/debian/man/svnwrap.1
   trunk/debian/svnwrap.sh
Modified:
   trunk/debian/changelog
   trunk/debian/rules
   trunk/debian/subversion-tools.manpages
   trunk/debian/subversion.README.Debian
Log:
New tool /usr/bin/svnwrap for subversion-tools.
This sets umask 002 unconditionally then runs whatever client binary
you ask for. I hope it solves more problems than it causes. :/

Modified: trunk/debian/changelog
===================================================================
--- trunk/debian/changelog 2006-04-21 05:22:23 UTC (rev 556)
+++ trunk/debian/changelog 2006-04-21 09:10:45 UTC (rev 557)
@@ -14,6 +14,9 @@
   * rules: add -V'libsvn0 (>= 1.3.0)' to dh_makeshlibs to loosen the
     shlibs file a bit. Upstream guarantees that the library ABI won't be
     augmented during any single x.y.* cycle.
+ * svnwrap.sh, man/svnwrap.1: new script for subversion-tools package to
+ optionally wrap subversion client commands with 'umask 002'.
+ (Closes: #242368, #259226, #282468, #292358)

  -- Peter Samuelson <email address hidden> Wed, 19 Apr 2006 17:14:31 -0500

Added: trunk/debian/man/svnwrap.1
===================================================================
--- trunk/debian/man/svnwrap.1 2006-04-21 05:22:23 UTC (rev 556)
+++ trunk/debian/man/svnwrap.1 2006-04-21 09:10:45 UTC (rev 557)
@@ -0,0 +1,98 @@
+.\" svnwrap.1
+.\" Copyright 2006 by Peter Samuelson
+.\" Permission is granted to everyone to use and distribute this work,
+.\" without limitation, modified or unmodified, in any way, for any purpose.
+.TH SVNWRAP 1 "2006-04-21"
+.\"
+.SH NAME
+svnwrap - Umask wrapper for subversion client commands
+.\"
+.SH SYNOPSIS
+.B svnwrap
+.RB { program }
+.RI [ args... ]
+.\"
+.SH DESCRIPTION
+.B svnwrap
+is a simple shell script to work around permission problems when
+sharing Subversion repositories between multiple local users.
+.B svnwrap
+can be used either by specifying the
+.B subversion
+client command explicitly on the command line, or by invoking it by the
+same name as the client command in question, via a symlink.
+.PP
+.B svnwrap
+sets the
+.I umask
+to 002, then launches the appropriate
+.B subversion
+client command. For complicated reasons, this is needed when using the
+clients with
+.IR BDB -format
+repositories, but not for
+.IR FSFS -format
+ones.
+.\"
+.SH EXAMPLES
+To create a new BDB-format shared repository (note that FSFS-format
+shared repositories should also be created this way):
+.PP
+svnwrap\ svnadmin\ create\ \-\-fs\-type=bdb
+.I /path/to/repo
+.br
+chgrp\ \-R
+.I shared_group\ /path/to/repo
+.PP
+The following line in
+.I /etc/inetd.conf
+can be used to serve
+.I svn://
+URLs:
+.PP
+svn\ stream\ tcp\ nowait
+.I my_svn_user
+/usr/bin/svnwrap\ svnserve\ \-i\ \-r
+.I /srv/svn
+.PP
+The following commands enable use of
+.B svnwrap
+for local
+.I file:///
+and remote
+.I svn+ssh://
+URLs:
+.PP
+ln\ \-s\ /usr/bin/svnwrap\ /usr/local/bin/svn
+.br
+ln\ \-s\ /usr/bin/svnwrap\ /usr/local/bin/svnserve
+.PP
+.B svn
+is used for local
+....

[Peter Samuelson (peter-p12n)]

Thanks for your patience, everybody, while we've been busy doing other
things than fixing this very long-standing bug, which was reported four
times and relegated for a long time to a corner labeled "hmmm, what
*should* we do with this one, anyway?"

I just wrote and documented a little '/usr/bin/svnwrap' script to set
the umask to 002 before executing other svn client binaries. I will
include it in next upload (1.3.1-3) in the 'subversion-tools' package.
You can see the details in 'man svnwrap', but the short version is, if
you do the following:

  ln -s /usr/bin/svnwrap /usr/local/bin/svn
  ln -s /usr/bin/svnwrap /usr/local/bin/svnserve

that should take care of <file:///> and <svn+ssh://> URLs, and if you
use an inetd.conf line that runs '/usr/bin/svnwrap svnserve -i' instead
of just '/usr/bin/svnserve -i', that should take care of <svn://> URLs.
If you launch svnserve as a daemon (as opposed to inetd) ... well, do
the obvious thing.

NOTE NOTE NOTE: there's a security implication to doing this with
/usr/local/bin/svn (for file:/// access): it affects users' local
working copies, not just the repositories. This, by the way, is the
reason upstream has never "fixed" this issue properly by just setting
the umask inside the subversion binaries themselves. (I can explain
further, including why this only affects bdb repos - anyone interested
should probably reply privately.)

Peter

[Troy Heber (troyh)]

Source: subversion
Source-Version: 1.3.1-3

We believe that the bug you reported is fixed in the latest version of
subversion, which is due to be installed in the Debian FTP archive:

libapache2-svn_1.3.1-3_i386.deb
  to pool/main/s/subversion/libapache2-svn_1.3.1-3_i386.deb
libsvn-core-perl_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-core-perl_1.3.1-3_i386.deb
libsvn-doc_1.3.1-3_all.deb
  to pool/main/s/subversion/libsvn-doc_1.3.1-3_all.deb
libsvn-javahl_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-javahl_1.3.1-3_i386.deb
libsvn-ruby1.8_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-ruby1.8_1.3.1-3_i386.deb
libsvn-ruby_1.3.1-3_all.deb
  to pool/main/s/subversion/libsvn-ruby_1.3.1-3_all.deb
libsvn0-dev_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn0-dev_1.3.1-3_i386.deb
libsvn0_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn0_1.3.1-3_i386.deb
python-subversion_1.3.1-3_i386.deb
  to pool/main/s/subversion/python-subversion_1.3.1-3_i386.deb
subversion-tools_1.3.1-3_all.deb
  to pool/main/s/subversion/subversion-tools_1.3.1-3_all.deb
subversion_1.3.1-3.diff.gz
  to pool/main/s/subversion/subversion_1.3.1-3.diff.gz
subversion_1.3.1-3.dsc
  to pool/main/s/subversion/subversion_1.3.1-3.dsc
subversion_1.3.1-3_i386.deb
  to pool/main/s/subversion/subversion_1.3.1-3_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Troy Heber <email address hidden> (supplier of updated subversion package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 05 May 2006 18:14:57 -0600
Source: subversion
Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev
Architecture: source all i386
Version: 1.3.1-3
Distribution: unstable
Urgency: medium
Maintainer: Guilherme de S. Pastore <email address hidden>
Changed-By: Troy Heber <email address hidden>
Description:
 libapache2-svn - apache modules for Subversion (aka. svn)
 libsvn-core-perl - perl bindings for Subversion (aka. svn)
 libsvn-doc - development documentation for Subversion (aka. svn) libraries
 libsvn-javahl - java bindings for Subversion (aka. svn)
 libsvn-ruby - ruby modules for interfacing with Subversion (aka. svn)
 libsvn-ruby1.8 - ruby modules for interfacing with Subversion (aka. svn)
 libsvn0 - shared libraries used by Subversion (aka. svn)
 libsvn0-dev - development files for Subversion (aka. svn) libraries
 python-subversion - python modules for interfacing with Subversion (aka. svn)
 subversion - advanced version control system (aka. svn)
 subversion-tools - assorted tools related to Subversion (aka. svn)
Closes: 242368 259226 282468 290774 292358 335528 359315 363983
Changes:
 subversio...

[Troy Heber (troyh)]

Source: subversion
Source-Version: 1.3.1-3

We believe that the bug you reported is fixed in the latest version of
subversion, which is due to be installed in the Debian FTP archive:

libapache2-svn_1.3.1-3_i386.deb
  to pool/main/s/subversion/libapache2-svn_1.3.1-3_i386.deb
libsvn-core-perl_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-core-perl_1.3.1-3_i386.deb
libsvn-doc_1.3.1-3_all.deb
  to pool/main/s/subversion/libsvn-doc_1.3.1-3_all.deb
libsvn-javahl_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-javahl_1.3.1-3_i386.deb
libsvn-ruby1.8_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-ruby1.8_1.3.1-3_i386.deb
libsvn-ruby_1.3.1-3_all.deb
  to pool/main/s/subversion/libsvn-ruby_1.3.1-3_all.deb
libsvn0-dev_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn0-dev_1.3.1-3_i386.deb
libsvn0_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn0_1.3.1-3_i386.deb
python-subversion_1.3.1-3_i386.deb
  to pool/main/s/subversion/python-subversion_1.3.1-3_i386.deb
subversion-tools_1.3.1-3_all.deb
  to pool/main/s/subversion/subversion-tools_1.3.1-3_all.deb
subversion_1.3.1-3.diff.gz
  to pool/main/s/subversion/subversion_1.3.1-3.diff.gz
subversion_1.3.1-3.dsc
  to pool/main/s/subversion/subversion_1.3.1-3.dsc
subversion_1.3.1-3_i386.deb
  to pool/main/s/subversion/subversion_1.3.1-3_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Troy Heber <email address hidden> (supplier of updated subversion package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 05 May 2006 18:14:57 -0600
Source: subversion
Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev
Architecture: source all i386
Version: 1.3.1-3
Distribution: unstable
Urgency: medium
Maintainer: Guilherme de S. Pastore <email address hidden>
Changed-By: Troy Heber <email address hidden>
Description:
 libapache2-svn - apache modules for Subversion (aka. svn)
 libsvn-core-perl - perl bindings for Subversion (aka. svn)
 libsvn-doc - development documentation for Subversion (aka. svn) libraries
 libsvn-javahl - java bindings for Subversion (aka. svn)
 libsvn-ruby - ruby modules for interfacing with Subversion (aka. svn)
 libsvn-ruby1.8 - ruby modules for interfacing with Subversion (aka. svn)
 libsvn0 - shared libraries used by Subversion (aka. svn)
 libsvn0-dev - development files for Subversion (aka. svn) libraries
 python-subversion - python modules for interfacing with Subversion (aka. svn)
 subversion - advanced version control system (aka. svn)
 subversion-tools - assorted tools related to Subversion (aka. svn)
Closes: 242368 259226 282468 290774 292358 335528 359315 363983
Changes:
 subversio...

[Troy Heber (troyh)]

Source: subversion
Source-Version: 1.3.1-3

We believe that the bug you reported is fixed in the latest version of
subversion, which is due to be installed in the Debian FTP archive:

libapache2-svn_1.3.1-3_i386.deb
  to pool/main/s/subversion/libapache2-svn_1.3.1-3_i386.deb
libsvn-core-perl_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-core-perl_1.3.1-3_i386.deb
libsvn-doc_1.3.1-3_all.deb
  to pool/main/s/subversion/libsvn-doc_1.3.1-3_all.deb
libsvn-javahl_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-javahl_1.3.1-3_i386.deb
libsvn-ruby1.8_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-ruby1.8_1.3.1-3_i386.deb
libsvn-ruby_1.3.1-3_all.deb
  to pool/main/s/subversion/libsvn-ruby_1.3.1-3_all.deb
libsvn0-dev_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn0-dev_1.3.1-3_i386.deb
libsvn0_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn0_1.3.1-3_i386.deb
python-subversion_1.3.1-3_i386.deb
  to pool/main/s/subversion/python-subversion_1.3.1-3_i386.deb
subversion-tools_1.3.1-3_all.deb
  to pool/main/s/subversion/subversion-tools_1.3.1-3_all.deb
subversion_1.3.1-3.diff.gz
  to pool/main/s/subversion/subversion_1.3.1-3.diff.gz
subversion_1.3.1-3.dsc
  to pool/main/s/subversion/subversion_1.3.1-3.dsc
subversion_1.3.1-3_i386.deb
  to pool/main/s/subversion/subversion_1.3.1-3_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Troy Heber <email address hidden> (supplier of updated subversion package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 05 May 2006 18:14:57 -0600
Source: subversion
Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev
Architecture: source all i386
Version: 1.3.1-3
Distribution: unstable
Urgency: medium
Maintainer: Guilherme de S. Pastore <email address hidden>
Changed-By: Troy Heber <email address hidden>
Description:
 libapache2-svn - apache modules for Subversion (aka. svn)
 libsvn-core-perl - perl bindings for Subversion (aka. svn)
 libsvn-doc - development documentation for Subversion (aka. svn) libraries
 libsvn-javahl - java bindings for Subversion (aka. svn)
 libsvn-ruby - ruby modules for interfacing with Subversion (aka. svn)
 libsvn-ruby1.8 - ruby modules for interfacing with Subversion (aka. svn)
 libsvn0 - shared libraries used by Subversion (aka. svn)
 libsvn0-dev - development files for Subversion (aka. svn) libraries
 python-subversion - python modules for interfacing with Subversion (aka. svn)
 subversion - advanced version control system (aka. svn)
 subversion-tools - assorted tools related to Subversion (aka. svn)
Closes: 242368 259226 282468 290774 292358 335528 359315 363983
Changes:
 subversio...

[Troy Heber (troyh)]

Source: subversion
Source-Version: 1.3.1-3

We believe that the bug you reported is fixed in the latest version of
subversion, which is due to be installed in the Debian FTP archive:

libapache2-svn_1.3.1-3_i386.deb
  to pool/main/s/subversion/libapache2-svn_1.3.1-3_i386.deb
libsvn-core-perl_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-core-perl_1.3.1-3_i386.deb
libsvn-doc_1.3.1-3_all.deb
  to pool/main/s/subversion/libsvn-doc_1.3.1-3_all.deb
libsvn-javahl_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-javahl_1.3.1-3_i386.deb
libsvn-ruby1.8_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn-ruby1.8_1.3.1-3_i386.deb
libsvn-ruby_1.3.1-3_all.deb
  to pool/main/s/subversion/libsvn-ruby_1.3.1-3_all.deb
libsvn0-dev_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn0-dev_1.3.1-3_i386.deb
libsvn0_1.3.1-3_i386.deb
  to pool/main/s/subversion/libsvn0_1.3.1-3_i386.deb
python-subversion_1.3.1-3_i386.deb
  to pool/main/s/subversion/python-subversion_1.3.1-3_i386.deb
subversion-tools_1.3.1-3_all.deb
  to pool/main/s/subversion/subversion-tools_1.3.1-3_all.deb
subversion_1.3.1-3.diff.gz
  to pool/main/s/subversion/subversion_1.3.1-3.diff.gz
subversion_1.3.1-3.dsc
  to pool/main/s/subversion/subversion_1.3.1-3.dsc
subversion_1.3.1-3_i386.deb
  to pool/main/s/subversion/subversion_1.3.1-3_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Troy Heber <email address hidden> (supplier of updated subversion package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Fri, 05 May 2006 18:14:57 -0600
Source: subversion
Binary: libsvn-core-perl libsvn0 libsvn-javahl libsvn-doc libsvn-ruby libapache2-svn libsvn-ruby1.8 python-subversion subversion-tools subversion libsvn0-dev
Architecture: source all i386
Version: 1.3.1-3
Distribution: unstable
Urgency: medium
Maintainer: Guilherme de S. Pastore <email address hidden>
Changed-By: Troy Heber <email address hidden>
Description:
 libapache2-svn - apache modules for Subversion (aka. svn)
 libsvn-core-perl - perl bindings for Subversion (aka. svn)
 libsvn-doc - development documentation for Subversion (aka. svn) libraries
 libsvn-javahl - java bindings for Subversion (aka. svn)
 libsvn-ruby - ruby modules for interfacing with Subversion (aka. svn)
 libsvn-ruby1.8 - ruby modules for interfacing with Subversion (aka. svn)
 libsvn0 - shared libraries used by Subversion (aka. svn)
 libsvn0-dev - development files for Subversion (aka. svn) libraries
 python-subversion - python modules for interfacing with Subversion (aka. svn)
 subversion - advanced version control system (aka. svn)
 subversion-tools - assorted tools related to Subversion (aka. svn)
Closes: 242368 259226 282468 290774 292358 335528 359315 363983
Changes:
 subversio...