SSL v3 vulnerability
Hi, Recently, we were informed by a publishing speaking about the vulnerability of SSLv 3.0. We would like to know if Subversion 1.6 is compatible with the following protocol TLS 1.0 / TLS 1.1 / TLS 1.2 ? Thanks in advance for you quick feedback Regards, Bien Cordialement, Nicolas Calvet
Re: SSL v3 vulnerability
On Tue, Oct 21, 2014 at 02:40:32PM +, Nicolas CALVET (Ingenico Partner) wrote: Hi, Recently, we were informed by a publishing speaking about the vulnerability of SSLv 3.0. We would like to know if Subversion 1.6 is compatible with the following protocol TLS 1.0 / TLS 1.1 / TLS 1.2 ? Thanks in advance for you quick feedback Regards, Bien Cordialement, Nicolas Calvet Subversion does not use SSL directly. It uses SSL indirectly via some of its dependencies. Therefore there is nothing the Subversion project can do about SSL-related issues (apart from some aspects such as client-side certicate management, but this doesn't apply for the SSLv3 problem). You should ask the relevant projects which Subversion depends on about their implementation of SSL support. For Subversion 1.6 clients, the neon or serf library can be used to establish HTTPS connections. The default library is neon. This project's website is http://webdav.org/neon/ -- that's probably the most appropriate place for your question. I believe neon supports TLS 1.2 as long as a recent enough version of OpenSSL or GNUTLS is used by neon. For Subversion 1.8, the only client-side HTTPS option is serf. Serf has released an update (1.3.8) which disables the use of SSLv3 entirely. It uses OpenSSL so as long as a recent OpenSSL version is in use, the TLS 1.2 protocol should work fine. See http://code.google.com/p/serf/ Subversion's server-side support for HTTPS is usually implemented by the Apache HTTPD web server: http://httpd.apache.org Another place where SSL is used is the svn:// protocol if the server uses SASL with a configuration that uses SSL. Subversion then uses Cyrus-SASL for both the server and the client. The project's website is http://asg.web.cmu.edu/sasl/
svn upgrade does nothing
Hello,
I'm having a weird issue with subversion: Every command is interrupt with
this:
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/jabiason/{work}' is too old
(format 10) to work with client version '1.8.10 (r1615264)' (expects format
31). You need to upgrade the working copy first.
I run svn upgrade (even multiple times) but the problem still happens.
As a temporary solution, I checked the source out in a different directory,
but there is a little snag: For my reluctance in commiting mid change,
there are some files that are not part of the repo yet but I can't see them
because svn st is interrupted mid processing with the error above.
svn --version
svn, version 1.8.10 (r1615264)
compiled Aug 20 2014, 08:13:28 on x86_64-redhat-linux-gnu
(It is the default subversion packaged by Fedora, btw).
--
Enviado via UCSMail.
RE: svn upgrade does nothing
I suggest you do a new, clean checkout. You can just copy the dirty files into
the new working copy.
From: Julio Andre Biason [mailto:jabia...@ucs.br]
Sent: Tuesday, October 21, 2014 12:11 PM
To: users@subversion.apache.org
Subject: svn upgrade does nothing
Hello,
I'm having a weird issue with subversion: Every command is interrupt with this:
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/jabiason/{work}' is too old (format
10) to work with client version '1.8.10 (r1615264)' (expects format 31). You
need to upgrade the working copy first.
I run svn upgrade (even multiple times) but the problem still happens.
As a temporary solution, I checked the source out in a different directory, but
there is a little snag: For my reluctance in commiting mid change, there are
some files that are not part of the repo yet but I can't see them because svn
st is interrupted mid processing with the error above.
svn --version
svn, version 1.8.10 (r1615264)
compiled Aug 20 2014, 08:13:28 on x86_64-redhat-linux-gnu
(It is the default subversion packaged by Fedora, btw).
Enviado via UCSMail.
Re: svn upgrade does nothing
On Tue, Oct 21, 2014 at 02:10:39PM -0200, Julio Andre Biason wrote:
Hello,
I'm having a weird issue with subversion: Every command is interrupt with
this:
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/jabiason/{work}' is too old
(format 10) to work with client version '1.8.10 (r1615264)' (expects format
31). You need to upgrade the working copy first.
I run svn upgrade (even multiple times) but the problem still happens.
Normally 'svn upgrade' should either print nothing and succeed (allowing
the 1.8 client to operate on the working copy), or it should complain with
some error message and fail.
I can't explain the behaviour you seem to be describing (no output but
not success either).
Can you please show how you invoked the svn upgrade command exactly?
And show the current working directory where you invoked it?
It seems you edited the error message, /home/jabiason/{work} is not
a usual path. Can you please at least give something that looks like
what you're seeing? If you insist on changing paths, please change the
path's components to some nonsense but leave the paths as-is otherwise,
rather than possibly redacting entire portions of a path.
Re: svn upgrade does nothing
I run svn upgrade in two different forms:
1. First, a simple svn upgrade. No output at all. svn update after that
fails:
Updating '.':
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at
'/home/jabiason/src/work/nephalem/12514-old/nephalem/media'
is too old (format 10) to work with client version '1.8.10 (r1615264)'
(expects format 31). You need to upgrade the working copy first.
2. Then, dunno why, I tried svn upgrade . (see the dot at the end of the
command). Again, no output and svn update fails again.
Yes, {work} is my current working directory, which includes information
that I'm not comfortable sharing, even if there is no way to access, simply
because I'm working for a client and I'd have to ask him permission to
access.
If that makes you happy, /home/jabiason/foo/bar/zaz/12312, where 12312
is the branch name -- yes, it's a number and no, zaz is not branches
because I checked out only the branch I need to work. Personally, path
shouldn't affect the result of a program: It has direct access to its local
repository/data (/home/jabiason/foo/bar/zaz/12312/.svn) and there is
nothing that the base OS can't handle (otherwise I wouldn't even be able to
access my files).
On 21 October 2014 16:34, Stefan Sperling s...@elego.de wrote:
On Tue, Oct 21, 2014 at 02:10:39PM -0200, Julio Andre Biason wrote:
Hello,
I'm having a weird issue with subversion: Every command is interrupt with
this:
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/home/jabiason/{work}' is too old
(format 10) to work with client version '1.8.10 (r1615264)' (expects
format
31). You need to upgrade the working copy first.
I run svn upgrade (even multiple times) but the problem still happens.
Normally 'svn upgrade' should either print nothing and succeed (allowing
the 1.8 client to operate on the working copy), or it should complain with
some error message and fail.
I can't explain the behaviour you seem to be describing (no output but
not success either).
Can you please show how you invoked the svn upgrade command exactly?
And show the current working directory where you invoked it?
It seems you edited the error message, /home/jabiason/{work} is not
a usual path. Can you please at least give something that looks like
what you're seeing? If you insist on changing paths, please change the
path's components to some nonsense but leave the paths as-is otherwise,
rather than possibly redacting entire portions of a path.
--
Enviado via UCSMail.
Re: svn upgrade does nothing
On Tue, Oct 21, 2014 at 04:42:14PM -0200, Julio Andre Biason wrote: I run svn upgrade in two different forms: 1. First, a simple svn upgrade. No output at all. svn update after that fails: Updating '.': svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' is too old (format 10) to work with client version '1.8.10 (r1615264)' (expects format 31). You need to upgrade the working copy first. 2. Then, dunno why, I tried svn upgrade . (see the dot at the end of the command). Again, no output and svn update fails again. The current directory is the default path if not specified, so both of these invocations did the same thing (whatever they did instead of what we'd expect they'd do). What happens if you run this? svn upgrade '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' Personally, path shouldn't affect the result of a program: This expectation doesn't hold in the case of 'svn upgrade', unfortunately. It must be passed the path to the top-level directory of a working copy. I've spent quite some time in the 'svn upgrade' code in an effort to fix that but to no avail. In some situations (involving nested working copies of various formats) svn just can't make a well-informed guess. Still, if the path you pass is not a working copy root, I'd expect to see an error such as: svn: E155019: Can't upgrade '/tmp/svn-sandbox/trunk/gamma' as it is not a working copy root, the root is '/tmp/svn-sandbox/trunk' I'd like to reproduce your problem locally but so far I haven't succeeded in doing so.
Re: svn upgrade does nothing
I had pretty much the idea that svn upgrade and svn upgrade . were the same, I was just trying to scratch both options out of the list. Upgrading the directory itself fixed the problem. This makes me think (I'm saying this just seeing the behaviour, I have no idea how the code works): It seems upgrade didn't go deep into the directory structure because the root (of the local repo) was already in the latest version[1]. Does upgrade try to go recursively into all directories, checking for .svn and updating if necessary? [1] Which also makes me wonder how a single directory got behind in the update process... On 21 October 2014 16:53, Stefan Sperling s...@elego.de wrote: On Tue, Oct 21, 2014 at 04:42:14PM -0200, Julio Andre Biason wrote: I run svn upgrade in two different forms: 1. First, a simple svn upgrade. No output at all. svn update after that fails: Updating '.': svn: E155036: Please see the 'svn upgrade' command svn: E155036: The working copy at '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' is too old (format 10) to work with client version '1.8.10 (r1615264)' (expects format 31). You need to upgrade the working copy first. 2. Then, dunno why, I tried svn upgrade . (see the dot at the end of the command). Again, no output and svn update fails again. The current directory is the default path if not specified, so both of these invocations did the same thing (whatever they did instead of what we'd expect they'd do). What happens if you run this? svn upgrade '/home/jabiason/src/work/nephalem/12514-old/nephalem/media' Personally, path shouldn't affect the result of a program: This expectation doesn't hold in the case of 'svn upgrade', unfortunately. It must be passed the path to the top-level directory of a working copy. I've spent quite some time in the 'svn upgrade' code in an effort to fix that but to no avail. In some situations (involving nested working copies of various formats) svn just can't make a well-informed guess. Still, if the path you pass is not a working copy root, I'd expect to see an error such as: svn: E155019: Can't upgrade '/tmp/svn-sandbox/trunk/gamma' as it is not a working copy root, the root is '/tmp/svn-sandbox/trunk' I'd like to reproduce your problem locally but so far I haven't succeeded in doing so. -- Enviado via UCSMail.
Re: svn upgrade does nothing
On Tue, Oct 21, 2014 at 05:03:07PM -0200, Julio Andre Biason wrote: Upgrading the directory itself fixed the problem. This makes me think (I'm saying this just seeing the behaviour, I have no idea how the code works): It seems upgrade didn't go deep into the directory structure because the root (of the local repo) was already in the latest version[1]. Does upgrade try to go recursively into all directories, checking for .svn and updating if necessary? Every 'svn' operation scans upwards to find the working copy root. So 'svn upgrade' scans for a working copy root upwards from the directory you pass in. If the nearest root found is already at the latest format it has nothing to do and exits. I suppose this is exactly what happened here. The other commands you ran probably scanned upwards from a different path and therefore found a different working copy at the old format. [1] Which also makes me wonder how a single directory got behind in the update process... You likely had disjoint nested working copies in 1.6 format. If you ran 'svn checkout URL1 A' and then 'svn checkout URL2 A/B' this would happen. The same situation could be created by an svn:externals configuration. The upgrade command does not look at what is above working copies created via svn:externals because the external working copy does not know that it is considered an external by some other working copy (don't ask me why -- this is how it was implemented years ago). In the 1.7/1.8 format, there is a single .svn directory at the top-level of each working copy. Now that the upgrade is complete you should be able to tell how many working copies you've got by looking for .svn directories.
