Bug#669111: subversion: globs in groups should be matched in order of their appearance

April 17th, 2012 - 07:40 am ET by Friedrich Delgado | Report spam
Package: subversion
Version: 1.6.12dfsg-6
Severity: wishlist

I'd like to be able to match against one particular server in our
organization which needs different client certificates than all the
others, but still have a global fallback for outside servers needing
no certificates.

The problem is that the order of matches is non-deterministic since
this monday for me (I can't see a relevant updated package, but it
used to work before).

The documentation on
http://svnbook.red-bean.com/en/1.1/...sect-1.3.1
states no order of evaluation, but since this is something I've relied
on in the past, I'd like to see it as a feature.

I'd like to use something like this

,-[ servers ]
[groups]
special = special.our-org.de
ourorg = *.our-org.de

[special]
ssl-authority-files = /home/fdf/secret/SPECIALCA.p12 # bogus self-signed CA
ssl-client-cert-file = /home/fdf/secret/special-cert.p12
ssl-client-cert-password = VerySecret

[ourorg]
ssl-client-cert-file = /home/fdf/secret/ourorg-cert.p12
ssl-client-cert-password = MoreSecret

[global]
`-


With the following file I can reproduce that glob matches are indeed
nondeterministic:

,-[ ~/dot-subversion-debian-bug/servers ]
[groups]
apache = svn.apache.org
outside = *

[apache]
neon-debug-mask = 0

[global]
neon-debug-mask = 511
`-

via:

svn ls --config-dir=~/dot-subversion-debian-bug http://svn.apache.org/repos/asf/sub...subversion 2>&1|wc -l

this will sometimes yield 32 lines (no debug output from neon) and
sometimes 2231 (lots of neon output) (Might need a couple of tries.)

So svn.apache.org sometimes matches the 'apache' group and sometimes
the 'outside' group.

while true; do svn ls --non-interactive https://special.our-org.de/repositories/our-org >/dev/null 2>&1 ; echo -n $?; done

with my "real" config above will yield a random string of 0s and 1s.

Debian Release: wheezy/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (50, 'karmic'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.3.0-1.dmz.1-liquorix-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.utf8)
Shell: /bin/sh linked to /bin/bash

Versions of packages subversion depends on:
ii libapr1 1.4.6-1
ii libc6 2.13-27
ii libsasl2-2 2.1.25.dfsg1-4
ii libsvn1 1.6.12dfsg-6

subversion recommends no packages.

Versions of packages subversion suggests:
ii db4.8-util <none>
ii patch 2.6.1-3
ii subversion-tools 1.6.17dfsg-3


Friedrich Delgado <friedel@nomaden.org>
TauPan on Ircnet and Freenode ;)



To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 2 repliesReplies Make a reply

Replies

#1 Peter Samuelson
April 17th, 2012 - 10:40 am ET | Report spam
[Friedrich Delgado]
The problem is that the order of matches is non-deterministic since
this monday for me (I can't see a relevant updated package, but it
used to work before).



I'm guessing this is the fault of apr 1.4.6, which randomizes hash
table ordering for security reasons. (Some hash tables are populated
by data controlled by untrusted users, and if the hash algorithm is
deterministic, they can unbalance it to the point of DOSing the
application.)

That is just an educated guess, I haven't investigated yet.

I agree with you that it seems like a useful feature to define some
sort of ordering, whether it be from the file, or longest match. I'll
bring it up with upstream and see what people think.

Thanks,
Peter



To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact

Similar topics