Apache Subversion 1.9.0-alpha2 released

[Ben Reser]

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

http://subversion.apache.org/download/#pre-releases

The SHA1 checksums are:

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

PGP Signatures are available at:

http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.tar.bz2.asc
http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.tar.gz.asc
http://www.apache.org/dist/subversion/subversion-1.9.0-alpha2.zip.asc

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:
056F 8016 D9B8 7B1B DE41  7467 99EC 741B 5792 1ACC

This is a pre-release for what will eventually become Apache Subversion
1.9.0.  It does contain some known issues (this list is not exhaustive): 

* Several issues with FSX (it is still experimental after all).
* svnserve SASL support is broken.

A pre-release means the Subversion developers feel that this release
is ready for widespread testing by the community.  There are known issues
(and unknown ones!), so please use it at your own risk, though we do
encourage people to test this release thoroughly.  Of particular note, please
remember than persistent data, such as the working copy or repository
formats may change before the final release, and there may not be an
upgrade path from the pre-releases to the final.  In this particular case, since
many of the changes have been to the repository formats and this is
only an alpha it is highly likely that incompatible format changes will be made
before the final 1.9.0 release.

As a note to operating system distro packagers: while we wish to have this
release candidate widely tested, we do not feel that it is ready for packaging
and providing to end-users through a distro package system.  Packaging a
release candidate poses many problems, the biggest being that our policy lets
us break compatibility between the release candidate and the final release, if
we find something serious enough.  Having many users depending on a release
candidate through their distro would cause no end of pain and frustration that
we do not want to have to deal with.  However, if your distro has a branch that
is clearly labeled as containing experimental and often broken software, and
explicitly destined to consenting developers and integrators only, then we're
okay with packaging the release candidate there.  Just don't let it near the
end users please.

With all the warnings given, we would especially like feedback on the following:

* New 'svn auth' subcommand.
* New reverse 'svn blame' functionality (-r M:N with M>N).
* Improvements to the interactive conflict resolution menus.
* FSFS format 7.

If you have any thoughts about the changes made in 1.9.0-alpha2 we would really
appreciate your feedback (even if they are not about the above things). 
Getting user
feedback this early in the development process provides us an opportunity to 
make
significant changes we otherwise would not make with a release candidate.  
Feedback
on 1.9.0-alpha2 should be directed to the users@subversion.apache.org mailing 
list.

Release notes for the 1.9.x release series may be found at:

http://subversion.apache.org/docs/release-notes/1.9.html

You can find the list of changes between 1.9.0-alpha2 and earlier versions at:

http://svn.apache.org/repos/asf/subversion/tags/1.9.0-alpha2/CHANGES

Questions, comments, and bug reports to users@subversion.apache.org.

Thanks,
- The Subversion Team

Re: SVN client SSL CRL configuration

[Ben Reser]

On 4/9/14, 7:56 AM, msk...@ansuz.sooke.bc.ca wrote:
> My main question is:  how do I get the Subversion command-line client to
> read a CRL?  The ssl-authority-files configuration setting lets me specify
> my CA's root certificate in a file; is there a similar setting for the
> CRL?  I would prefer to distribute the CRL as a file (instead of a URL to
> be checked automatically); is that possible?  Or is it absolutely
> necessary to post the CRL online somewhere and specify its URL in the root
> certificate (which will require constructing a new root certificate and a
> bunch of scripts to periodically re-issue and re-post the file).  If it's
> going to necessitate changes to the root certificate and frequent ongoing
> maintenance, I might be better off just re-doing the entire public key
> infrastructure from scratch, annoying as that will be.
> 
> Note I am specifically asking about the Subversion command-line client
> running under Linux.  I already know how to configure Apache to read the
> CRL on the server side.  All I've been able to find online regarding
> *client-side* Subversion CRL use is Windows-specific.

If you haven't seen it already we published a message on this over the weekend:

https://mail-archives.apache.org/mod_mbox/subversion-announce/201404.mbox/%3C5349F1B7.1090306%40apache.org%3E

Unfortunately I missed mentioning the state of Windows where it does fall back
and support CRLs (see Bert's reply to your message).

Unfortunately, the work around I had hoped last week would work for you ended
up not working out.  Primarily because OpenSSL needs a flag set to even support
CRL checking at all and it's not set by default.

Wish we had a better option for you.  But it looks like starting with a fresh
CA is probably your best option.

Re: Recent Heartbleed OpenSSL bug may affect HTTPS Subversion servers

[Ben Reser]

On 4/12/14, 3:41 PM, Nico Kadel-Garcia wrote:
> For our own safety and benefito of combined HTTP/HTTPS servers for
> Subversion worldwide: is there a published test to verify that HTTP
> servers do not have the same flaw due to also being configured for
> SSL?

Stefan Sperling replied to you on the dev list already, but I think it's worth
answering here again since there's a different audience here.

A HTTP server that has no ports enabled to use SSL but that has mod_ssl is not
vunlerable.  This is the case because the issue only occurs when using the
heartbeat extension of TLS (which requires an SSL/TLS enabled connection).

However, servers that have both HTTP and HTTPS ports enabled may leak
information about the HTTP only traffic via the HTTPS connections.  I wouldn't
be surprised if people have servers with public facing connections that are SSL
enabled but internal only connections that do not use SSL at all.

Consider this scenario.  You have a public website with SSL enabled and a SVN
repository (not SSL enabled) that's only accessible on your own private network
(probably even on private address space).  You are using the same httpd
instance to host both.  It is possible that information ranging from
authentication details, tree structure, to even full file contents can be
leaked by the SSL connection about the HTTP SVN connections.

Essentially anything in memory of a process utilizing a vulnerable version of
OpenSSL to implement the heartbeat extension to TLS is subject to being
revealed to clients of the TLS connections.