Post Master | 16 Apr 19:47 2014

using system groups in svnaccess.conf

subversion need to specify group members in the 'groups' 
section of
svnaccess.conf configuration file.
external access control system like LDAP, AD, &etc. 
requires to syncronize group
members to svnaccess.conf (for example:
subversion must query operating system for group members 
for example: on posix systems from nss (ldap, nis, 
/etc/group ...). on windows:
from AD or local groups.

authz_posixgroup_contains_user.patch is a prototype for 
posix system (getgrnam).

svnaccess.conf may be like that:

%wheel = rw
%members.test.bla-bla-bla = r

'%'-prefix means system group
Daniel Shahaf | 17 Apr 13:12 2014

Tonight's svn-role merges - bug analysis

There were 9 merges tonight (r1588145:r1588153).  The log messages were
all correct, but the Nth merge removed from STATUS the (2N)th merge's
entry.  As a result, the first merge (N=0) was correct, but the others
either removed the wrong STATUS entry or removed no entry.

I think this is due to a bug in the relatively new $parno handling.  I
believe the parno code wasn't on the VM until yesterday, even though
it's been in HEAD for a while.

The code stows $parno in the %entry structure at parse time, and then
loops over the entries in Approved and merges them.  The first merge
deletes the ($entries[0]->{parno})th paragraph from STATUS.¹  The second
merge then deletes the ($entries[1]->{parno})th paragraph from the
file... which is wrong; it should be deleting the ($entries[1]->{parno} - 1)th
paragraph instead, since the first merge has happened, and
$entries[0]->{parno} < $entries[1]->{parno}.

The fix would be to change the $parno accounting as follows: before
$entry{parno} is used, subtract from it the number of entries already
merged in this run.  (Entries are currently merged in file order, so
none of the already-merged-in-this-run entries would have a ->{parno}
greater than $entry{parno} of the entry about to be merged.)


P.S. It would be a good idea to have some sort of test suite for

¹ There is no  <at> entries array; that was just pseudosyntax for "the first entry".

(Continue reading)

Ben Reser | 15 Apr 02:29 2014

Intent to roll 1.7.17/1.8.9

I intend to roll 1.7.17 and 1.8.9 sometime next week.  Please take some time
over the next week to look at STATUS in the respective branches and vote for


Ben Reser | 14 Apr 17:56 2014

Apache Subversion 1.9.0-alpha2 released

I'm happy to announce the release of Apache Subversion 1.9.0-alpha2.
Please choose the mirror closest to you by visiting:

The SHA1 checksums are:

    c1de8633db4d8bc4b3145fec51b4079ca560f2a3 subversion-1.9.0-alpha2.tar.bz2
    2f563294e26d0ec806eef01f2e9e9231cafe3508 subversion-1.9.0-alpha2.tar.gz

PGP Signatures are available at:

For this release, the following people have provided PGP signatures:

   Ben Reser [4096R/16A0DE01] with fingerprint:
    19BB CAEF 7B19 B280 A0E2  175E 62D4 8FAD 16A0 DE01
   Bert Huijben [4096R/CCC8E1DF] with fingerprint:
    3D1D C66D 6D2E 0B90 3952  8138 C4A6 C625 CCC8 E1DF
   Branko Čibej [4096R/A347943F] with fingerprint:
    BA3C 15B1 337C F0FB 222B  D41A 1BCA 6586 A347 943F
   Johan Corveleyn [4096R/010C8AAD] with fingerprint:
    8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD
   Philip Martin [2048R/ED1A599C] with fingerprint:
    A844 790F B574 3606 EE95  9207 76D7 88E1 ED1A 599C
   Stefan Fuhrmann [4096R/57921ACC] with fingerprint:
(Continue reading)

Stefan Fuhrmann | 14 Apr 16:05 2014

Fulltext caching and server (non-)scalability

Hi all,

This is nothing new (introduced way back when in 1.6),
but I have only become aware of it during my recent
scalability testing. I think I can fix that but that won't
happen until the end of next week or so.

Scenario: Large files have been cached and now a
number of clients request these files. The critical bit
here is N clients requesting say a 1GB file each.
ra_serf may request 2 of these. It may be the same
or different files.

What happens: N x 1GB is fetched from cache, each
held in some buffer and streamed out from there.

Problem: How many of those GB-sized buffers can
your server hold before going OOM?

Solution: Fetch only chunks of a configurable size
(default 16MB) from caches that support it and limit
other caches (memcached) to 1 chunk max. per file.
Fall back to standard reconstruction from deltas
when data gets evicted from cache while some chunks
have not been delivered, yet. This can be hidden
behind our existing stream interface.

-- Stefan^2.
neels | 14 Apr 02:21 2014

[svnbench] Failed to build Revision: 1587128.

Failed to build Revision: 1587128.

Ben Reser | 13 Apr 04:08 2014

Subversion and Heartbleed

As you may have heard in the news OpenSSL has had a significant security
vulnerability [1] [2].  Subversion by way of several of our dependencies uses
OpenSSL.  On the client side the Neon and Serf HTTP libraries can use OpenSSL
(Neon can also use GNUTLS, which is not vulnerable to this issue) and on the
server side Apache HTTP Server and Cyrus SASL can use OpenSSL (though Cyrus
SASL's use of OpenSSL is not vulnerable).

As a result it is important to make sure that the OpenSSL version being used
with Subversion is not vulnerable.  It is impossible for the Subversion project
to provide vulnerable version information for Subversion since if you are
vulnerable depends on the OpenSSL used at build and/or run time.  We do not
publish binaries, so you should consult with your binary provider to make sure
you are not vulnerable.  If you've built your own version of Subversion you
should check which version you have built against and/or are using at runtime.

This specific issue lies in the implementation of a feature of the SSL/TLS
protocols.  Apache HTTP Servers running mod_ssl to provide SSL/TLS are
vulnerable.  While svnserve does support encryption via Cyrus SASL, and Cyrus
SASL does use OpenSSL to provide the encryption algorithms, it does not use it
to implement the SSL/TLS protocols.  This means that svnserve is not directly
vulnerable.  However, you can use the svnserve over tunnels and those tunnels
may be vulnerable.  For instance stunnel implements the SSL/TLS protocol and
does so via OpenSSL.  SSH based tunnels are unaffected as they do not use the
SSL/TLS protocols.  If you're using some other tunnel not mentioned here you
should check with the developers of that tunnel for details.

It is important to understand that this vulnerability is not specific to the
server side.  Clients can be vulnerable to malicious servers using the same
attack against clients.  So care should be taken to ensure that clients are not
using vulnerable OpenSSL versions as well.

The unfortunate consequence of this vulnerability is that server or client
memory may be exposed to the other side of the connection.  This has the
possibility of exposing private information that the other side of the
connection should not have.  Within the context of Subversion that means
authentication information, details about working copies, data from other
clients, private keys used with public key encryption, etc.

As a result of the above potential data disclosures, after you have upgraded to
non-vulnerable versions of the software, you may want to take additional
actions including revoking and reissuing SSL/TLS server and client certificates
and resetting user passwords.  It is understood that retrieving private keys to
certificates may be very difficult, but still possible.  Other data may be much
easier to retrieve.  As such, if these steps are necessary are largely a matter
of your risk tolerance.

If you are using HTTPS to access your Subversion repositories and do decide to
revoke your certificates you should understand that at current Subversion does
not support rejecting revoked certificates that would otherwise be trusted.
Our HTTP libraries (Neon and Serf) which we depend on for this sort of
functionality do not currently provide support for providing an external CRL
(Certificate Revocation List), retrieving CRLs from a URL in the certificate,
checking certificates via OCSP (Online Certificate Status Protocol) or handling
an OCSP response that has been stapled to the TLS handshake.

In the meantime, you can disable trusting certificates based on trust in the
Certifying Authorities to avoid accepting revoked certificates.  To do this you
will want to make some configuration changes in your server config file for
Subversion (usually at /etc/subversion/servers, ~/.subversion/servers, or
%APPDATA%\Subversion\servers, see [3] for more details).  Set
"ssl-trust-default-ca" to "no" and remove the "ssl-authority-files" setting.
By doing this Subversion will prompt for all certificates giving you details on
the certificate and a fingerprint.  You will then have the opportunity to
accept the certificate temporarily or permanently.  Server admins should let
their users know the fingerprints of the correct certificates.  This is similar
to the manner in which SSH handles validating they are talking to the server
they expect to be.

If you have already trusted certificates that are now revoked you will also
need to remove them from your authentication store for Subversion.  This will
be stored under ~/.subversion/auth/svn.ssl.server or
%APPDATA%\Subversion\auth\svn.ssl.server.  You can delete the entire directory
to remove all accepted certificates or just delete specific files within the
directory to remove just those certs.  The files are simply text files
containing some data, you should be able to read them to locate the specific
keys you which to remove.

We realize that the handling for revoked certificates is far from ideal at this
time.  We plan to improve this in the future, but are unable to provide a time
frame for such improvements.


Mayuresh Rajwadkar | 10 Apr 21:36 2014

Update documentation


I support subversion at my workplace and would usually like users to follow

The file however is outdated and points to Subversion 1.0 documentation...

Attached here is a patch, which would make the trunk point to the nightly instead of
Subversion 1.0. Yes it probably needs more information, however at least this fixes the subversion links to point to a more appropriate nightly version of the documentation instead of a really old one...


$ svn info svn-best-practices.html
Path: svn-best-practices.html
Name: svn-best-practices.html
Working Copy Root Path: /nobackup/mayuresh/projects/apache-svn/subversion-trunk
Repository Root:
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1586321
Node Kind: file
Schedule: normal
Last Changed Author: dongsheng
Last Changed Rev: 887954
Last Changed Date: 2009-12-07 10:33:55 -0500 (Mon, 07 Dec 2009)
Text Last Updated: 2014-04-10 11:02:56 -0400 (Thu, 10 Apr 2014)
Checksum: d6de0d2d58a006ff2ee98ba4e0bba051bc5f9443

Julian Foad | 10 Apr 13:59 2014

r1570642, r1585686 - Fix memcached support

Re this nomination for 1.8.x:

  * r1570642, r1585686
   Fix memcached support.
     Enabling memcached causes crashes without these fixes.
     Regression from 1.7.
     +1: stsp, philip

On trunk, it looks like the following doc fixes are required to match the code changes made in r1570642.

Index: subversion/include/private/svn_cache.h
--- subversion/include/private/svn_cache.h    (revision 1586265)
+++ subversion/include/private/svn_cache.h    (working copy)
 <at>  <at>  -188,6 +188,10  <at>  <at> 
  * if they are strings.  Cached values will be copied in and out of
  * the cache using  <at> a serialize_func and  <at> a deserialize_func, respectively.
+ * If  <at> a deserialize_func is NULL, then the data is returned as an
+ * svn_stringbuf_t; if  <at> a serialize_func is NULL, then the data is
+ * assumed to be an svn_stringbuf_t.
+ *
  * The cache stores up to  <at> a pages *  <at> a items_per_page items at a
  * time.  The exact cache invalidation strategy is not defined here,
  * but in general, a lower value for  <at> a items_per_page means more
 <at>  <at>  -230,7 +234,7  <at>  <at> 
  * other caches.   <at> a *cache_p will be allocated in  <at> a result_pool.
  * If  <at> a deserialize_func is NULL, then the data is returned as an
- * svn_string_t; if  <at> a serialize_func is NULL, then the data is
+ * svn_stringbuf_t; if  <at> a serialize_func is NULL, then the data is
  * assumed to be an svn_stringbuf_t.
  * These caches are always thread safe.
 <at>  <at>  -344,7 +348,7  <at>  <at> 
  * will be allocated in  <at> a result_pool.
  * If  <at> a deserialize_func is NULL, then the data is returned as an
- * svn_string_t; if  <at> a serialize_func is NULL, then the data is
+ * svn_stringbuf_t; if  <at> a serialize_func is NULL, then the data is
  * assumed to be an svn_stringbuf_t.
  * If  <at> a thread_safe is true, and APR is compiled with threads, all

- Julian

Branko Čibej | 9 Apr 17:51 2014

remote-only-status branch ready for review

I've finished the work on the remote-only-status branch. I'd like to ask
for a review of the changes before I merge it to trunk. I'm currently
running a full round of tests on the branch, which I've sync'd with
trunk up to r1585988; results are looking good for now.

If the tests pass, and there are no objections, I'll merge to trunk
early next week.

svn diff ^/subversion/trunk ^/subversion/branches/remote-only-status

-- Brane


Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane <at>

Daniel Shahaf | 9 Apr 10:17 2014

Auto-props not validated

With trunk <at> Monday:

% subversion/svn/svn add \
	--config-option 'config:miscellany:enable-auto-props=true' \
	--config-option 'config:auto-props:*.t=*.c=bar' \
A         foo.t
% svn pl -v foo.t
Properties on 'foo.t':
% svn propset '*.h' baz foo.t 
svn: E195011: '*.h' is not a valid Subversion property name
zsh: exit 1     svn propset '*.h' baz foo.t

It shouldn't be the case that '*.c' can be set and '*.h' can't be set.

(thanks to Geoff Field on users <at>  for making me run into this:
< <at>>)