Re: Authentication problem with clients > 1.7.22

[Lieven Govaerts]

Op donderdag 28 juli 2016 heeft Stefan Sperling  het
volgende geschreven:

> On Wed, Jul 27, 2016 at 06:56:46PM +0200, Krzysztof Smiechowicz wrote:
> > Hi All,
> >
> > We are having problems accessing our svn server via https with client
> newer
> > than 1.7.22 - 1.8.16 and 1.9.3 to be specific. The problem is that the
> newer
> > clients come up with authentication request during svn checkout which
> after
> > entering correct password fails. The authentication comes at random
> moments
> > during checkout. The difference we could spot so far was that 1.7.22 was
> > using ra_neon and newer clients are using ra_serf for HTTPS.
>
> My guess is that you need to increase the MaxKeepAliveRequests setting
> in httpd.conf on the SVN server.
>
> Once the MaxKeepAliveRequests limit is reached the server closes the
> connection so the client opens a new one and authenticates again.
>
> Serf-based clients send a lot more requests than Neon-based clients.
> It seems the Neon-based clients do not trigger the limit in your
> situations, while Serf-based clients do.
>
>
Ra_serf first opens one connection during checkout, and then opens more
connections to get the data when needed. My guess is that the authn request
comes when opening those 2nd, 3rd connections, not when the server
initiates a connection close.

The fact that serf sends more requests and therefore uses multiple
connections should not make svn ask for credentials multiple times, they
are cached in memory for Basic and Digest authentication. So there seems to
be something wrong.

As a workaround, it's possible to make svn use one single connection for
checkout, update and merge by setting SVNAllowBulkUpdates to Prefer in the
apache configuration file.
See:
https://subversion.apache.org/docs/release-notes/1.8.html#neon-deleted
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.perf.bulk-updates

Hth,

Lieven

> AAROS/AROS/arch/all-pc/boot/grub2-aros/configure
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/Makefile.common
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/Makefile.in
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/Makefile.extra-dist
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/i386-cygwin-img-ld.sc
> > A
> AROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/boot_menu_nw.png
> > A
> AROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/boot_menu_e.png
> > A
> AROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/terminal_box_sw.png
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/theme.txt
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/slider_n.png
> > Authentication realm:  AROS TRAC+SVN
> > Password for 'guest':
> >
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/Makefile.in
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/Makefile.extra-dist
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/conf/i386-cygwin-img-ld.sc
> > A
> AROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/boot_menu_nw.png
> > A
> AROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/boot_menu_e.png
> > A
> AROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/terminal_box_sw.png
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/theme.txt
> > AAROS/AROS/arch/all-pc/boot/grub2-aros/themes/starfield/slider_n.png
> > Authentication realm:  AROS TRAC+SVN
> > Password for 'guest': *
> >
> > svn: E120190: Error retrieving REPORT: An error occurred during
> authentication
> >
> > The server is running subversion 1.8.10 on Debian 8.
> >
> > Any help is appreciated
> >
> > Best regards,
> > Krzysztof
>

Re: subversion checksum error

[Lieven Govaerts]

On Fri, Oct 31, 2014 at 4:26 PM, Ruben Lopez rlope...@gmail.com wrote:
 I found my problem, my antivirus program Panda, intercepted my http
 connections and I was getting corrupted files, the files include part of the
 next file (some extra bytes). For now i uninstall Panda Antivirus.

Good to know that your problem is solved, thanks for following up with
this information.

Lieven

 Thanks

 Ruben

Re: svn always fails with E120171, but only from some clients

[Lieven Govaerts]

On Fri, Oct 24, 2014 at 4:49 PM, Sean McBride s...@rogue-research.com wrote:
 Hi there,

 On some computers only, 'svn info' is always giving:

 svn: E120171: Error running context: An error occurred during SSL 
 communication

 when connecting to our own svn server.  This worked previously, but stopped 
 working (I think) after our self-signed certificate expired and was therefore 
 replaced.  First we replaced it with another self-signed cert, then we 
 replaced it with a purchased wildcard cert.

 - I reproduce this with svn 1.8.10 (Wandisco binaries on OS X) on the client.

I've seen such SSL failures on Mac's before. It was caused by not
having an up to date OpenSSL library installed. Not all distributions
of svn do that apparently (e.g. Homebrew).

Older OpenSSL versions don't always support recent X509 certificates,
a (well known) example is the use of SHA-256 as signature hash
algorithm, where older OpenSSL versions support SHA-1, but not
SHA-256.

 - Server runs 1.7.18 (Wandisco binaries on OS X).
 - I have deleted ~/.subversion on the client, no help.
 - I created an entire new user account on the client machine, no help.
 - visiting https://my.server.com/path/to/repository in a browser (tried 
 several) prompts for authentication, succeeds, and shows the expected files.
 - I ran openssl s_client -showcerts -connect my.server.com:443 and it 
 reports at the end:
   Verify return code: 0 (ok)

 I'm now feeling pretty stuck. :(  Any suggestions on what this problem is, or 
 how I can diagnose it further?


Personally I've always stuck with using svn from Mac Ports; which
automatically installs the latest OpenSSL.

Lieven

 PS: First post to this list, please be gentle. :)

 Thanks,

 --
 
 Sean McBride, B. Eng s...@rogue-research.com
 Rogue Researchwww.rogue-research.com
 Mac Software Developer  Montréal, Québec, Canada

Re: SVN 1.8 timeout fix

[Lieven Govaerts]

On Wed, Oct 15, 2014 at 2:10 PM,  paul.gil...@l-3com.com wrote:
 There is no proxy between the client and server. As my original email stated, 
 I could see using netstat that there were tcp connections left in the 
 FIN_WAIT_2 state and the Apache documentation suggests this could be a bug in 
 the client. Also as the Apache documentation suggested, disabling KeepAlive 
 resolved the issue.  See http://httpd.apache.org/docs/2.0/misc/fin_wait_2.html

The hypothesis stated here is that serf isn't closing its connections
correctly when they are closed by the server, on Windows. While I
don't think anything is wrong with that part of the serf code, serf
testing is mostly done by using short-lived processes so if there's an
issue it might not be very visible. I'll have a look later.


 Whatever the problem is, when I disable Keepalive I can't browse the 
 repositories from a browser. 
 http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate
  suggests it is a serf bug.

That's not what that mail suggests. It talks about an old bug where
svn+serf can't authenticate to a server using the Digest
authentication scheme when that server is configured with KeepAlive
off. That issue was a) solved a long time ago, and b) as others have
said is unrelated to what you're seeing.

Lieven


 -Original Message-
 From: Philip Martin [mailto:philip.mar...@wandisco.com]
 Sent: Wednesday, October 15, 2014 8:01 AM
 To: Gillis, Paul @ ESG - WSS - Insight
 Cc: users@subversion.apache.org
 Subject: Re: SVN 1.8 timeout fix

 paul.gil...@l-3com.com writes:

 When I initially used the default skelta-mode, small checkouts and
 commits worked perfectly fine. Large checkouts or commits would begin
 normally but the file transfer rate would quickly drop to 0 and the
 operation would time out.  Increasing MaxKeepAliveRequests to 1000
 didn't help.  When I disabled KeepAlive, it solved the problem.

 I don't know what would cause that.  A skelta-mode checkout uses a large 
 number of small requests while a bulk-mode checkout uses a small number of 
 large requests.  Is there an HTTP proxy between the client and server?

 However, with KeepAlive disabled, I discovered we can't browse
 repositories from a web browser. Apparently, this is a know serf bug.
 http://grokbase.com/t/subversion/users/136n5tvzx1/tsvn-and-svn-1-8-0-cannot-digest-authenticate.

 serf is a client-side library.  There is no way a serf bug can affect a web 
 browser (I'm guessing you have not written your own web browser that uses 
 serf :)  You must be seeing some other problem.

 --
 Philip Martin | Subversion Committer
 WANdisco // *Non-Stop Data*

Re: Proxy settings in SVN

[Lieven Govaerts]

Hi,

On Thu, Sep 11, 2014 at 11:03 PM, Vaux, John jv...@phoenixchildrens.com wrote:
 Hello all,

 It’s my first time posting to this list and I am not
 subscribed so please CC me on any replies.



 I’m having difficulty with the proxy settings in Windows
 version of svn (I’m using the WANdisco compiled version).  It seems as
 though no matter what I put in the appdata\roaming\subversion\servers file
 the settings are ignored and the svn is defaulting to the windows control
 panel settings.  This would be fine but we utilize a proxy.pac autoconfigure
 and require proxy authentication.  Between those two settings for whatever
 reason svn seems to be unable to deal with the proxy’s request for
 authentication.  I’ve tcpdumped the connection information from the proxy
 itself and it looks like svn just isn’t answering.



 The basic gist of the stream goes like this:

 Source  Dest   Protocol
 Length  Message

 clientIP proxyIPHTTP
 121 CONNECT www.svnrepository.tld:443 HTTP/1.1

 proxyIPclientIP HTTP
 236 HTTP/1.1 407 authenticationrequired  (text/html)

 clientIP proxyIPHTTP
 217 CONNECT www.svnrepository.tld:443 HTTP/1.1 ,
 NTLMSSP_NEGOTIATE

 proxyIPclientIP HTTP
 252 HTTP/1.1 407 authenticationrequired ,
 NTLMSSP_CHALLENGE (text/html)



 And then silence.

What do you mean with silence? Does the svn client hang? Does it exit
with an error?

  The app correctly interprets the first 407 and tries
 connecting again but this time with an NTLMSSP_NEGOTIATE but when the proxy
 comes back with a CHALLENGE svn never responds with credentials.  I worked
 with my proxy vendor and we tried to find ways around it but short of
 turning off authentication they are chalking it up to a bug in the HTTP
 client implementation.  Any help would be much appreciated.


We'll probably need serf log output to find out in detail what's
happening. Alas in serf 1.3.x logging can only be enabled at
compile-time, so you'll need to either build serf + svn manually, or
maybe one of the Windows devs (Ivan? Bert?) can provide you with a
Windows 1.8 client with serf logging enabled?

Lieven



 John Vaux

 Enterprise Infrastructure Architect

 Information Technology Services

 Phoenix Children's Hospital

 Office: 602-933-2592

 Mobile: 602-501-3052

 jv...@phoenixchildrens.com



 
 This transmission, including any attachments, is for the sole use of the
 intended recipient (s) and may contain information that is confidential,
 proprietary, legally privileged, or otherwise protected by law from
 disclosure. Any unauthorized review, use, copying, disclosure, or
 distribution is prohibited. If you are not the intended recipient, or the
 person responsible for delivering this to an addressee, you should notify
 the sender immediately by telephone or by reply e-mail, and destroy all
 copies of the original message.

Re: Sporadic E120171: Error running context: An error occurred during SSL communication

[Lieven Govaerts]

Hi,

On Mon, Jul 21, 2014 at 3:30 PM, Niemann, Hartmut
hartmut.niem...@siemens.com wrote:
 Hello!



 Our svn server is hosted on a virtual server managed by some subcontractor.
 (Redhead enterprise linux, AFAIK).

 When committing, we get too often the following errors.



 In tortoise SVN en example message is:

 „Command: Commit

 Error: Übertragen schlug fehl (Details folgen):

 Error: Fehler beim Ausführen des Kontextes: An error occurred during SSL
 communication

 Completed!“



 On the command line it looks like

 D:\PRJ\DPS\binsvn commit -m CTRL_SH ignorieren eventmemory.py

 Sendingeventmemory.py

 svn: E120171: Commit failed (details follow):

 svn: E120171: Error running context: An error occurred during SSL
 communication



 There are some variants of these messages, obviously at different stages of
 the process.


It's difficult to tell from this error message, but does your server
require the use of client certificates?
IOW, do you have the 'ssl-client-cert-file' config set in your
~/.subversion/servers file?

If that's the case, you might run into an OpenSSL issue that's
triggered by serf (the http library svn uses). More details here:
https://code.google.com/p/serf/issues/detail?id=135 .

The error happens when a server requests a renegotiation (to ask for
your client certificate) while HTTP requests are waiting in its
in-buffer to be read.


 As far as I know a restart of the apache web server does help, but after a
 few hours of use

 these errors come back.

 It feels like some resource is not properly freed, and when the server runs
 out of i would like to know what,

 this error comes. Sometimes it helps to wait for 15 minutes and retry.



 Who can tell me, what this message means and what to do about it?

 What would I need to tell the server admins?


If it's solved when restarting the server, then this would be a server
error, but I can't remember seeing such a problem mentioned on this
list. In any case it's interesting to see the apache access and error
logs at the time you're seeing this error message.

If my guess about the client certificates is right, you'll see this
error in the apache logs: Re-negotiation handshake failed: Not
accepted by client!?

To get more info in the server logs try logging with log level trace8.

hth,

Lieven


 Mit freundlichen Grüßen
 Dr. Hartmut Niemann

 Siemens AG
 Infrastructure  Cities Sector
 Rail Systems Division
 Locomotives and Components
 IC RL LOC EN CCI 1
 Werner-von-Siemens-Str. 67
 91052 Erlangen, Deutschland
 Tel: +49 9131 7-34264
 Fax: +49 9131 7-26254
 mailto:hartmut.niem...@siemens.com

 Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;
 Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Klaus Helmrich, Hermann
 Requardt, Siegfried Russwurm, Ralf P. Thomas; Sitz der Gesellschaft: Berlin
 und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300,
 München, HRB 6684; WEEE-Reg.-Nr. DE 23691322

Re: SVN 1.8 Kerberos Client problems

[Lieven Govaerts]

Hi Nico,

On Tue, Jul 8, 2014 at 3:57 PM, Nicolai Scheer nicolai.sch...@gmail.com wrote:
 Hi,

 I did an update to svn 1.8.9 on our server yesterday and am now
 running into problems whilst updating the corresponding windows
 client.

 Server details:

 CentOS 6.5 x64
 SVN 1.8.9, compiled on my own
 Apache 2.2.15
 Authentication using mod_auth_kerb to windows domain

 Client:
 Windows Server 2008
 TSVN 1.7.13

 Everything ran fine so far. I then upgraded to TSVN 1.8.7 which ships
 with svn 1.8.9 binaries.
 Now, on every repository involving action I get kerberos errors in my
 apache log:

 [Tue Jul 08 15:08:10 2014] [error] [client 192.168.1.152]
 gss_accept_sec_context() failed: No credentials were supplied, or the
 credentials were unavailable or inaccessible (, Unknown error)

 Strange thing is, TSVN works fine from a user perspective (no error
 displayed whatsoever...). I then tried to use the svn command line
 binaries, same result, evrythings works, but apache error log is DOSed
 with these error entries.

That's because you have this directive in your apache config:
 KrbMethodK5Passwd on

With this configuration, mod_auth_kerb will offer both Negotiate and
Basic authentication. Your logs show that Negotiate authentication
fails, but in this case svn will automatically fall back to Basic
authentication, which succeeds.

 I tried to either prefer or deny BulkUpdates on the server, nothing changes.

This option has nothing to do with authentication, it specifies how -
after authentication succeeded - svn+serf will communicate with
mod_dav_svn.

 Since subversion 1.8 comes with serf, it might have do to with the way
 serf handles kerberos.

Not unlikely.

 From the linux cmd (on the svn server itself), I can use kerberos
 (kinit + svn command afterwards) just fine, without any errors popping
 up in the apache log.


Which GSSAPI implementation are you using on the server? MIT? Heimdal?
Which versions?

 Our browsers (IE, Chrome, FF) worked fine all the time using kerberos,
 before and after upgrading svn on the server.

 TSVN 1.7.13 works as well, so do the svn binaries shipped this version.

 I'm quite stuck, because I do not know where to start. To my mind
 kerberos is set up correctly because all clients work, except svn 1.8


Serf on Windows uses Microsoft's SSPI API to handle Negotiate
authentication. We know this works well with Windows based servers
(e.g. VisualSVN) that also use SSPI on the server side.
Serf on Linux/Mac uses GSSAPI and one of its implementations. This
works well with other *nix servers.

It's likely that the combination client on Windows with
server+mod_auth_kerb on Linux hasn't seen as much testing as the cross
platform combinations, and that certain scenario's are not supported
well.

Debugging this stuff will not be easy. Most likely you'll find some
more information in the Kerberos implementation logging, which is
configured in your krb5.conf file. On my system the log file is
/var/log/krb5.log. Try to increase the log level to get more detailed
error information.

The best alternative is to find out what's going over the wire.
Disable your SSL configuration and set KrbMethodK5Passwd to off  (on a
test server) and use Wireshark to trace all traffic between your
Windows client and svn server. Wireshark on Windows can decode the
SPNego tokens in the Authorization headers (at least for NTLM but I
suppose for Kerberos also). This allows you to see if all info is
correct (domain, username etc). If you want you can send me the
wireshark trace privately and I'll have a look.

 I thought I could solve the problem by falling back to BulkUpdate, but
 it does not seem to help.

 Any suggestions are appreciated!

 Greetings

 Nico


hth,

Lieven

 PS:

 svn apache config :

 SVNInMemoryCacheSize 131072
 SVNCacheTextDeltas On
 SVNCacheFullTexts On
 SVNCompressionLevel 6
 SVNCacheRevProps On
 Location /repos
 SSLRequireSSL
 DAV svn

 SVNListParentPath On
 SVNParentPath /var/local/svn/repos

 # Kerberos authentification
 AuthType Kerberos
 AuthName Realm
 KrbServiceName HTTP
 KrbLocalUserMapping on
 KrbAuthRealms REALM.INTERN
 KrbMethodNegotiate on
 KrbMethodK5Passwd on
 Krb5KeyTab /etc/httpd/kerberos/keytab
 KrbVerifyKDC on

 require valid-user

 AuthzSVNAccessFile /var/local/svn/auth/svn_authz
 SVNPathAuthz short_circuit
 /Location

Re: Update from 1.8.5 to 1.8.8 breaks my self-signed numeric IP certificate

[Lieven Govaerts]

On Tue, Mar 4, 2014 at 8:17 AM, Lieven Govaerts l...@apache.org wrote:
 Hi Daniel.

 On Tue, Mar 4, 2014 at 1:46 AM, Daniel Widdis wid...@gmail.com wrote:
 Hi, Lieven.  No worries about sending the key... I can generate a new one
 if/when this gets resolved!

 In regard to the serf1 conversation, I'm using the latest version on
 macports, 1.3.2.  I can work to try to get 1.3.4 loaded somehow but
 understand that may not be required.

 Yes it is, I think upgrading to serf 1.3.3 will solve this problem
 for you. Also, I can confirm that macports has serf 1.3.4:
 http://www.macports.org/ports.php?by=librarysubstr=serf1


 Here's the output of the openssl command you requested.  This is using a
 self-signed cert that works with 1.8.5 and fails with 1.8.8.

 danielwiddis ~ $ openssl s_client -connect 192.168.100.59:443
 CONNECTED(0003)
 depth=0 CN = 192.168.100.59
 verify error:num=20:unable to get local issuer certificate
 verify return:1
 depth=0 CN = 192.168.100.59
 verify error:num=21:unable to verify the first certificate
 verify return:1

 Interesting. I was convinced you could only get the second error with
 chains of length  1, but that assumption is clearly invalid.

 This does point in the direction of the two issues Bert fixed in serf
 1.3.3 + svn 1.8.8:
 1. The second error is error
 X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE. Before serf 1.3.3 this
 code wasn't recognized, so serf returned it as unknown cert error.
 Svn doesn't allow a user to permanently trust a cert with unknown
 errors.
 2. You get two verification errors at depth 0, which means the svn
 server credentials callback is called twice.
 Since svn 1.8.8, you'll get two prompts:
 - the first allows you to permanently accept the unable to get local
 issuer certificate,
 - the second prompt's behaviour will depend on svn/serf version
   - svn 1.8.8 with serf 1.3.3: you can temporarily accept the unknown error
   - svn 1.8.8 with serf  1.3.3: you should be able to permanently
 accept the issuer is not trusted error

Of course, if you permanently trust the cert in the first prompt, you
won't see the second prompt anymore because svn will answer that from
the cache.

 So in summary, try upgrading to serf  1.3.3, it should solve your issue.

 Lieven

 ---
 Certificate chain
  0 s:/CN=192.168.100.59
i:/CN=192.168.100.59
 ---
 Server certificate
 -BEGIN CERTIFICATE-
 MIIC2TCCAcGgAwIBAgIJAPKhN26bz/IrMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNV
 BAMTDjE5Mi4xNjguMTAwLjU5MB4XDTE0MDMwMTAyMjExNloXDTI0MDIyNzAyMjEx
 NlowGTEXMBUGA1UEAxMOMTkyLjE2OC4xMDAuNTkwggEiMA0GCSqGSIb3DQEBAQUA
 A4IBDwAwggEKAoIBAQDhpux+KA5HmT78yVFLiasC87R/TelmFlm64UimUllPJuQ/
 n8Hwf+2Zinju675LZByPzAnV7qBhJa17o6RO73alUM1zBdK2Aow4TbJR7hbs5iaa
 6W8z8GeCL4vo8pg7RHaTtiLu8+fiSgtR9A7+pSl7v91NhpEC9amd5HT95HQnJrD6
 QssZEboKSqzWetR/uKjtG9/7VvIQW/kg4GLPHGC4uvQEbQhvClDDaIQ2b6Oxr6Zy
 JTxjuzGh+GlewUOVfT0P6LphFVFZj5Q4XgnhUQcOp4dG2w7B+MokwDksHq/g0Mfy
 tdPuZs+DxrB3NmTDV2yUK/CMjaf391VVGnf0zq7zAgMBAAGjJDAiMAsGA1UdDwQE
 AwIEMDATBgNVHSUEDDAKBggrBgEFBQcDATANBgkqhkiG9w0BAQUFAAOCAQEAEor/
 UEO6OKabsQhcAqi6cyjhbEbiDAM78IAQYD6HdY1+XQWNb3P+JxBoojKLJfcC5Lgf
 7kvwWj3F0jeByxsHxcaNGmwEAnr1apuDZNb9o6++oHsMI5Cb8CznSjEUgsKhk8cK
 dfH66dd2wHuPyrNVrKrkDFexvwuZ92NkT/WhCZkrWPUXz+F4dolAiIxvgNQkGSgc
 aSUA/f9owl0/PJYOV542etU/fPTlwvAklsE8wMFPXwOyzWr/kueAYUSkKgN9/Vv4
 2cw7VXXQmQjUGaKW2XQ12TIhtP5jRSpLevT9Dwp9LoCl5aq49gz+aUEWtRt0Vobm
 U2pyvf2Ke++z7j+eBA==
 -END CERTIFICATE-
 subject=/CN=192.168.100.59
 issuer=/CN=192.168.100.59
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 1611 bytes and written 518 bytes
 ---
 New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol  : TLSv1
 Cipher: DHE-RSA-AES256-SHA
 Session-ID:
 004AEB4377EDD3362C1D36B88B51B21F6033065CDEBBC5EA78D0575242CDF6C3
 Session-ID-ctx:
 Master-Key:
 68784FE78DC7C4374FF2CEF0EC59AF4B8570EB75DC62806F987863DA4771C4D86D5ADCA9A7D112C51B403202BA26029A
 Key-Arg   : None
 PSK identity: None
 PSK identity hint: None
 SRP username: None
 TLS session ticket:
  - d8 1e ea f1 26 96 70 cc-02 37 2c 9d df 47 0d 8a .p..7,..G..
 0010 - b5 4d 77 32 3c 7a e7 21-fc eb 3e 8f e9 da 36 d2 .Mw2z.!.6.
 0020 - 1a da cb 52 64 92 ff f4-f5 54 7d e0 82 13 f4 b1 ...RdT}.
 0030 - 74 77 3d 41 98 a5 38 a8-2a 9a 77 e4 ed 74 38 78 tw=A..8.*.w..t8x
 0040 - ff f6 36 55 75 5c 07 4c-c8 58 bd ea cc 31 09 72 ..6Uu\.L.X...1.r
 0050 - c3 b5 6d 65 fa a0 64 7a-f9 e0 dd c1 9f a4 f2 f8 ..me..dz
 0060 - 9f e6 38 08 22 af 37 23-ca c5 1a d9 9b dd 9b 24 ..8..7#...$
 0070 - 19 77 c0 83 f8 a5 cc 70-fa c6 9d d9 da 67 9e 9a .w.p.g..
 0080 - 48 43 93 a0 86 1a 95 8d-f1 f5 a8 5e 23 07 16 41 HC.^#..A
 0090 - 49 99 c9 e1 5e c3 fa 70-71 bb d8 16 2d 61 01 ab I...^..pq...-a..
 00a0 - 2e 8d a5 eb 2e 31 f7 81-61 6f ab ee 39 2c e4 12 .1..ao..9

Re: Update from 1.8.5 to 1.8.8 breaks my self-signed numeric IP certificate

[Lieven Govaerts]

Hi Daniel,

On Sat, Mar 1, 2014 at 5:06 AM, Daniel Widdis wid...@gmail.com wrote:
 I recently upgraded from 1.8.5 to 1.8.8 via macports. The new version
 refused to permanently accept my self-signed certificate, citing an unknown
 error.

 Certificates generated on Windows 2008 Server using VisualSVN 2.7.4.

 Hostname is a numeric IP on a VPN (192.168.100.59)

 Client is Mac OS X 10.9.1 (Mavericks) with svn installed via Macports:
   subversion @1.8.5_1+universal (active)  this setup works
   subversion @1.8.8_0+no_bdb+universal  this setup fails

 Under 1.8.8:
 $ svn update
 Updating '.':
 Error validating server certificate for 'https://192.168.100.59:443':
  - The certificate has an unknown error.
 Certificate information:
  - Hostname: 192.168.100.59
  - Valid: from Mar  1 02:21:16 2014 GMT until Feb 27 02:21:16 2024 GMT
  - Issuer:
  - Fingerprint: BE:C4:65:B6:0E:BD:5C:EE:F4:DB:A9:E1:EB:AE:B6:BC:43:F2:E7:5E
 (R)eject or accept (t)emporarily? t
 At revision 46.

Could you send:
- the output of:
  $ openssl s_client -connect 192.168.100.59:443
- and/or create a self signed key + cert using your method that fails
with svn 1.8.8 ?

This should give us the necessary extra info to simulate your issue.

Note: since you're using a self signed certificate this log/key-cert
pair shouldn't contain any private info, but if you prefer you can
send them to me privately.


 Under 1.8.5 with no other changes:
 $ svn update
 Updating '.':
 At revision 46.


regards,

Lieven

Re: Update from 1.8.5 to 1.8.8 breaks my self-signed numeric IP certificate

[Lieven Govaerts]

Hi Daniel.

On Tue, Mar 4, 2014 at 1:46 AM, Daniel Widdis wid...@gmail.com wrote:
 Hi, Lieven.  No worries about sending the key... I can generate a new one
 if/when this gets resolved!

 In regard to the serf1 conversation, I'm using the latest version on
 macports, 1.3.2.  I can work to try to get 1.3.4 loaded somehow but
 understand that may not be required.

Yes it is, I think upgrading to serf 1.3.3 will solve this problem
for you. Also, I can confirm that macports has serf 1.3.4:
http://www.macports.org/ports.php?by=librarysubstr=serf1


 Here's the output of the openssl command you requested.  This is using a
 self-signed cert that works with 1.8.5 and fails with 1.8.8.

 danielwiddis ~ $ openssl s_client -connect 192.168.100.59:443
 CONNECTED(0003)
 depth=0 CN = 192.168.100.59
 verify error:num=20:unable to get local issuer certificate
 verify return:1
 depth=0 CN = 192.168.100.59
 verify error:num=21:unable to verify the first certificate
 verify return:1

Interesting. I was convinced you could only get the second error with
chains of length  1, but that assumption is clearly invalid.

This does point in the direction of the two issues Bert fixed in serf
1.3.3 + svn 1.8.8:
1. The second error is error
X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE. Before serf 1.3.3 this
code wasn't recognized, so serf returned it as unknown cert error.
Svn doesn't allow a user to permanently trust a cert with unknown
errors.
2. You get two verification errors at depth 0, which means the svn
server credentials callback is called twice.
Since svn 1.8.8, you'll get two prompts:
- the first allows you to permanently accept the unable to get local
issuer certificate,
- the second prompt's behaviour will depend on svn/serf version
  - svn 1.8.8 with serf 1.3.3: you can temporarily accept the unknown error
  - svn 1.8.8 with serf  1.3.3: you should be able to permanently
accept the issuer is not trusted error

So in summary, try upgrading to serf  1.3.3, it should solve your issue.

Lieven

 ---
 Certificate chain
  0 s:/CN=192.168.100.59
i:/CN=192.168.100.59
 ---
 Server certificate
 -BEGIN CERTIFICATE-
 MIIC2TCCAcGgAwIBAgIJAPKhN26bz/IrMA0GCSqGSIb3DQEBBQUAMBkxFzAVBgNV
 BAMTDjE5Mi4xNjguMTAwLjU5MB4XDTE0MDMwMTAyMjExNloXDTI0MDIyNzAyMjEx
 NlowGTEXMBUGA1UEAxMOMTkyLjE2OC4xMDAuNTkwggEiMA0GCSqGSIb3DQEBAQUA
 A4IBDwAwggEKAoIBAQDhpux+KA5HmT78yVFLiasC87R/TelmFlm64UimUllPJuQ/
 n8Hwf+2Zinju675LZByPzAnV7qBhJa17o6RO73alUM1zBdK2Aow4TbJR7hbs5iaa
 6W8z8GeCL4vo8pg7RHaTtiLu8+fiSgtR9A7+pSl7v91NhpEC9amd5HT95HQnJrD6
 QssZEboKSqzWetR/uKjtG9/7VvIQW/kg4GLPHGC4uvQEbQhvClDDaIQ2b6Oxr6Zy
 JTxjuzGh+GlewUOVfT0P6LphFVFZj5Q4XgnhUQcOp4dG2w7B+MokwDksHq/g0Mfy
 tdPuZs+DxrB3NmTDV2yUK/CMjaf391VVGnf0zq7zAgMBAAGjJDAiMAsGA1UdDwQE
 AwIEMDATBgNVHSUEDDAKBggrBgEFBQcDATANBgkqhkiG9w0BAQUFAAOCAQEAEor/
 UEO6OKabsQhcAqi6cyjhbEbiDAM78IAQYD6HdY1+XQWNb3P+JxBoojKLJfcC5Lgf
 7kvwWj3F0jeByxsHxcaNGmwEAnr1apuDZNb9o6++oHsMI5Cb8CznSjEUgsKhk8cK
 dfH66dd2wHuPyrNVrKrkDFexvwuZ92NkT/WhCZkrWPUXz+F4dolAiIxvgNQkGSgc
 aSUA/f9owl0/PJYOV542etU/fPTlwvAklsE8wMFPXwOyzWr/kueAYUSkKgN9/Vv4
 2cw7VXXQmQjUGaKW2XQ12TIhtP5jRSpLevT9Dwp9LoCl5aq49gz+aUEWtRt0Vobm
 U2pyvf2Ke++z7j+eBA==
 -END CERTIFICATE-
 subject=/CN=192.168.100.59
 issuer=/CN=192.168.100.59
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 1611 bytes and written 518 bytes
 ---
 New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
 Server public key is 2048 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol  : TLSv1
 Cipher: DHE-RSA-AES256-SHA
 Session-ID:
 004AEB4377EDD3362C1D36B88B51B21F6033065CDEBBC5EA78D0575242CDF6C3
 Session-ID-ctx:
 Master-Key:
 68784FE78DC7C4374FF2CEF0EC59AF4B8570EB75DC62806F987863DA4771C4D86D5ADCA9A7D112C51B403202BA26029A
 Key-Arg   : None
 PSK identity: None
 PSK identity hint: None
 SRP username: None
 TLS session ticket:
  - d8 1e ea f1 26 96 70 cc-02 37 2c 9d df 47 0d 8a .p..7,..G..
 0010 - b5 4d 77 32 3c 7a e7 21-fc eb 3e 8f e9 da 36 d2 .Mw2z.!.6.
 0020 - 1a da cb 52 64 92 ff f4-f5 54 7d e0 82 13 f4 b1 ...RdT}.
 0030 - 74 77 3d 41 98 a5 38 a8-2a 9a 77 e4 ed 74 38 78 tw=A..8.*.w..t8x
 0040 - ff f6 36 55 75 5c 07 4c-c8 58 bd ea cc 31 09 72 ..6Uu\.L.X...1.r
 0050 - c3 b5 6d 65 fa a0 64 7a-f9 e0 dd c1 9f a4 f2 f8 ..me..dz
 0060 - 9f e6 38 08 22 af 37 23-ca c5 1a d9 9b dd 9b 24 ..8..7#...$
 0070 - 19 77 c0 83 f8 a5 cc 70-fa c6 9d d9 da 67 9e 9a .w.p.g..
 0080 - 48 43 93 a0 86 1a 95 8d-f1 f5 a8 5e 23 07 16 41 HC.^#..A
 0090 - 49 99 c9 e1 5e c3 fa 70-71 bb d8 16 2d 61 01 ab I...^..pq...-a..
 00a0 - 2e 8d a5 eb 2e 31 f7 81-61 6f ab ee 39 2c e4 12 .1..ao..9,..
 00b0 - b3 46 b2 8c 9a dc a7 3d-2e a2 64 48 2b 14 b1 5e .F.=..dH+..^

 Start Time: 1393893584
 Timeout   : 300 (sec)
 Verify return code: 21 (unable to verify the first certificate)
 ---
 closed




 On 3/3/14, 4:48 PM, Lieven

Re: Slow VM, svn client drops connection with FIN packet

[Lieven Govaerts]

Hi Stu,

On Mon, Dec 23, 2013 at 6:11 PM,  stuartm.cod...@gmail.com wrote:
 On Tuesday, December 17, 2013 10:32:34 AM UTC-5, Branko Čibej wrote:

 On 17.12.2013 16:19, Stuart MacDonald wrote:
  The Wireshark trace shows clearly and conclusively this is a bug in
  the client. The client drops the connection by sending a FIN packet
  unexpectedly.

 It could be waiting for a response from the proxy that never reaches the
 client, and dropping the connection after a timeout.

 Regardless, you should still try to reproduce this with the latest
 client (ideally, both latest 1.7 and 1.8) to determine if the problem
 has been fixed. Especially in 1.8, there have been a lot of improvements
 in the HTTP protocol driver.


 I'm using WANdisco's packages to test with, as it turned out to be easier to
 get those set up than to compile from source with all the optional bits I
 need.

 I have seen the exact same issue on 1.7.14:
 svn: E175002: REPORT of '/svn/repos/name/!svn/me': Could not read response
 body: connection was closed by server (http://server)
 and the Wireshark capture shows the client sending a [FIN, ACK] to close the
 connection, despite it only being a fraction of a second since the last
 server traffic. This always occurs just after the TCP window opening up
 again, not sure if that's significant.

 This *also* occurs on 1.8.5, although the error message is more informative:
 svn: E120106: ra_serf: The server sent a truncated HTTP response body.
 The Wireshark capture is *exactly* *identical*; after some server traffic,
 the TCP window opens up and the client sends a [FIN, ACK] to close the
 connection.

to be clear, you've tested:
- svn 1.7.13 with ra_neon, svn 1.7.14 with ra_neon and 1.8.5 with ra_serf.
- to an svn 1.7.7 server
- over http, with nginx 1.0.5. as intermediate proxy
- running 'svn up'
- on an Ubuntu guest (version __) using Virtualbox (version
__) on host OS .

Can you fill in the blanks?

The error The server sent a truncated HTTP response body. you're
seeing from ra_serf, means that ra_serf is busy reading a response
from the server but all data isn't arriving.

We have seen this caused by proxies tampering with the response data.
In this case I suppose the connection is shut down unexpectedly first,
which ra_serf interprets as 'the connection closed, but I didn't get
all data for this response yet = error.

 Having taken a closer look at the network captures; the failure pattern is
 always:
 - 1380 byte packets from the server
 - an ACK from the client
 - a TCP window update from the client (the window hadn't gone to 0 in any
 cases, this is just a regular update)
 - in one case there's another window update from the client
 - a delay of 0 - 4 seconds where there is no traffic in either direction
 - the client sends the [FIN, ACK]


 Now, I'm not sure what constitutes a truncated HTTP response body, as the
 traffic looks the same in both cases, large blocks of encoded data. So I
 think the 1.8.x error message is also incorrect, but possibly less incorrect
 than the 1.7.x error message.


Your setup has many different layers so many possible failing components.
From your transcript of the wireshark trace it looks like the
connection is shut down on the client side (like you said).

You have tested two versions of subversion, each with their own http
client implementation (serf and neon). Both libraries have been
implemented completely independently by different people, without
sharing code. I find it difficult to believe that both libraries have
the same bug, but ok, it's not impossible.

In case of serf I can add that if serf would actively drop the
connection due to a timeout, you'd see a different error message. In
fact, I've searched for error E120106 and it's only raised when a
clean EOF is returned from the network layer, whereas in case of error
(TCP RST) the nw layer returns a ECONNABORTED or ECONNRESET status
code.

So, my first guess would be a problem with either the guest OS, or
with the Virtualbox network code (the latter I think is more likely).

 What's the next step?

1. If you like and are allowed to, you can send me the wireshark .pcap
file privately (replace username/passwd/basic/digest authn headers
with X, but keep the same # of chars!).
Also, the debug logging of both http client libraries would be nice:
- For svn 1.7.x put neon-debug-mask=255 in your servers file.
- For 1.8.5 this won't work anymore, you'll have to compile serf from
source to enable debugging (flags CONN_VERBOSE, SOCK_VERBOSE,
SOCK_MSG_VERBOSE in serf_private.h).

Maybe with this information I can confirm my reasoning or find another
potential cause.

2. I'd also test this same operation on a physical machine, with the
same OS and/or with a different OS.

3. Regardless of this issue, the upgrade of nginx is important for svn
1.8.5, as older versions of nginx have problems with serf's use of
HTTP 1.1 features. There's a fallback mechanism now, but at the cost
of some reduced 

Re: svn 1.8 client segmentation fault when checking out Subversion trunk repository

[Lieven Govaerts]

On Tue, Oct 8, 2013 at 8:35 PM, Martin Zibricky mzibr.pub...@gmail.comwrote:

 Hi everyone,

 I'm trying to compile svn 1.8.3 with lsbcc (Linux Standard Base).

 Everything compiles fine but when trying to checkout Subversion trunk
 ( http://svn.apache.org/repos/asf/subversion/trunk/ )
 the svn client crashes with the segmentation fault in the middle of
 checkout
 and I get broken working copy.

 This is the GDB output with enabled debugging output
 --enable-maintainer-mode
 option:

 ---
 $ gdb env/local/tools/svn/1.8.3/bin/svn
 GNU gdb (GDB) 7.4.1-debian
 Copyright (C) 2012 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later 
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as x86_64-linux-gnu.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /home/user/env/local/tools/svn/1.8.3/bin/svn...done.
 (gdb) run co http://svn.apache.org/repos/asf/subversion/trunk//tmp/KKLL
 Starting program: /home/user/env/local/tools/svn/1.8.3/bin/svn co
 http://svn.apache.or
 g/repos/asf/subversion/trunk/ /tmp/KKLL
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
 A/tmp/KKLL/notes
 A/tmp/KKLL/notes/obliterate
 A/tmp/KKLL/notes/obliterate/fspec-cc1
 A/tmp/KKLL/notes/obliterate/fspec-dd1
 A/tmp/KKLL/notes/obliterate/hooks
 A/tmp/KKLL/notes/obliterate/presentations
 A/tmp/KKLL/notes/wc-ng
 A/tmp/KKLL/CHANGES
 A/tmp/KKLL/gen-make.py
 A/tmp/KKLL/autogen.sh
 A/tmp/KKLL/aclocal.m4
 A/tmp/KKLL/NOTICE
 A/tmp/KKLL/get-deps.sh
 A/tmp/KKLL/Makefile.in
 A/tmp/KKLL/LICENSE
 A/tmp/KKLL/build.conf
 A/tmp/KKLL/win-tests.py
 A/tmp/KKLL/COMMITTERS
 A/tmp/KKLL/notes/obliterate/design-repos.html
 A/tmp/KKLL/notes/obliterate/fspec-cc1/cc1-dir-ops.svg
 A/tmp/KKLL/notes/obliterate/fspec-cc1/cc1-file-ops.svg
 A/tmp/KKLL/notes/obliterate/fspec-cc1/cc1-fspec.txt
 A/tmp/KKLL/notes/tree-conflicts
 A/tmp/KKLL/notes/feedback
 A/tmp/KKLL/notes/wc-ng/modularization

 Program received signal SIGSEGV, Segmentation fault.
 0x7676486b in impl_pollset_poll (pollset=0x6bf050,
 timeout=optimized
 out, num=0x7fffdb94,
 descriptors=0x7fffdb98) at poll/unix/epoll.c:284
 284 pollset-p-result_set[j] = *fdptr;
 (gdb) backtrace
 #0  0x7676486b in impl_pollset_poll (pollset=0x6bf050,
 timeout=optimized out,
 num=0x7fffdb94, descriptors=0x7fffdb98) at
 poll/unix/epoll.c:284
 #1  0x74948cf6 in serf_context_run ()
from
 /home/user/env/local/tools/svn/1.8.3/lib/../../../../lib/libserf-1.so.3
 #2  0x74b73988 in finish_report (report_baton=0x651e90,
 pool=optimized
 out)
 at subversion/libsvn_ra_serf/update.c:2850
 #3  0x778ff0aa in svn_wc_crawl_revisions5 (wc_ctx=0x69d638,
 local_abspath=local_abspath@entry=0x64f338 /tmp/KKLL,
 reporter=0x74d82ef0,
 report_baton=0x651e90, restore_files=restore_files@entry=1,
 depth=depth@entry=svn_depth_unknown,
 honor_depth_exclude=1, depth_compatibility_trick=0, use_commit_times=0,
 cancel_func=0x4180a0 svn_cl__check_cancel, cancel_baton=0x0,
 notify_func=0x412d30 notify,
 notify_baton=0x69d778, scratch_pool=0x64f228) at
 subversion/libsvn_wc/adm_crawler.c:845
 #4  0x77bcc726 in update_internal (result_rev=result_rev@entry
 =0x0,
 conflicted_paths=conflicted_paths@entry=0x650780,
 local_abspath=local_abspath@entry=0x64f338 /tmp/KKLL,
 anchor_abspath=0x650850 /tmp/KKLL,
 revision=revision@entry=0x7fffdf00,
 depth=depth@entry=svn_depth_unknown, depth_is_sticky=0,
 ignore_externals=0,
 allow_unver_obstructions=0, adds_as_modification=1,
 timestamp_sleep=0x7fffe064,
 notify_summary=1, ctx=0x69d580, pool=0x64f228) at
 subversion/libsvn_client/update.c:459
 #5  0x77bccc44 in svn_client__update_internal
 (result_rev=result_rev@entry=0x0,
 local_abspath=local_abspath@entry=0x64f338 /tmp/KKLL,
 revision=revision@entry=0x7fffe0f0,
 depth=depth@entry=svn_depth_unknown,
 depth_is_sticky=depth_is_sticky@entry=1,
 ignore_externals=ignore_externals@entry=0, allow_unver_obstructions=0,
 adds_as_modification=1,
 make_parents=0, innerupdate=0, timestamp_sleep=0x7fffe064,
 ctx=0x69d580,
 pool=0x64f228)
 at subversion/libsvn_client/update.c:595
 #6  0x77b97ebd in svn_client__checkout_internal
 (result_rev=result_rev@entry=0x0,
 url=url@entry=0x69e5f8 
 http://svn.apache.org/repos/asf/subversion/trunk;,
 local_abspath=0x64f338 /tmp/KKLL, peg_revision=0x7fffe100,
 revision=0x7fffe0f0,
 

Re: svn: warning: W120171: Error running context: An error occurred during SSL communication

[Lieven Govaerts]

Hi,

On Tue, Sep 24, 2013 at 4:33 PM, Niemann, Hartmut
hartmut.niem...@siemens.com wrote:
 Hello!



 What is going wrong if I get

 svn: warning: W120171: Error running context: An error
 occurred during SSL communication

 five out of six times I try to update a repository or to do some other
 subversion command?


the error code comes from the serf library, more specifically this is
error SERF_ERROR_SSL_COMM_FAILED.
It indicates that the OpenSSL library reported an error during ssl/tls
communication. It should be unrelated to certificate validation as
that's another error code.


 (This is Tortoise SVN/64

 TortoiseSVN 1.8.2, Build 24708 - 64 Bit , 2013/08/27 19:20:39

 Subversion 1.8.3, -release

 apr 1.4.8
 apr-util 1.5.2
 serf 1.3.1
 OpenSSL 1.0.1e 11 Feb 2013
 zlib 1.2.8



 and it’s command line tool


 svn, version 1.8.3 (r1516576)

compiled Aug 27 2013, 22:13:03 on x86-microsoft-windows [...]

 * ra_serf : Module for accessing a repository via WebDAV protocol using
 serf.

   - using serf 1.3.1
   - handles 'http' scheme
   - handles 'https' scheme
 on Windows 7)



 The problems started yesterday (tsvn 1.8.1, about 3 out of 4 tries failed),
 today nothing works.


Was something in the server configuration related to ssl/tls modified?
Or, do you use a proxy server that was changed recently?

 I upgraded to 1.8.3, tried both the gui and the command line version.

 Where do I have to look for the cause of this failure?


First of all check the apache access and error logs, if the server
raised an ssl alert it should be in the logs.
Second, run wireshark.
  If you're using a proxy, check that the ssl tunnel setup was done
correctly. Also check that the proxy is not configured to close the
connection after the first request (Connection:Close header on the
response to the CONNECT request).
  Check if there are ssl alerts, check if it's the client or the
server that closed the connection, check if session initialisation was
successful.
Third, get yourself a build of serf with logging activated (#define
SSL_VERBOSE 1), send the logs to the list or to me privately, should
give us a lot of info to analyse what's wrong.

Lieven


 Mit freundlichen Grüßen
 Dr. Hartmut Niemann

 Siemens AG
 Infrastructure  Cities Sector
 Rail Systems Division
 Locomotives and Components
 IC RL LOC EN LE 8
 Werner-von-Siemens-Str. 67
 91052 Erlangen, Deutschland
 Tel: +49 9131 7-34264
 Fax: +49 9131 7-26254
 mailto:hartmut.niem...@siemens.com

 Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;
 Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus
 Helmrich, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y.
 Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München,
 Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB
 6684; WEEE-Reg.-Nr. DE 23691322

Re: svn 1.8 causing locks to be broken on update

[Lieven Govaerts]

On Wed, Aug 14, 2013 at 11:30 PM, Johan Corveleyn jcor...@gmail.com wrote:
 On Wed, Aug 14, 2013 at 12:05 PM, Felipe Alvarez
 felipe.alva...@gmail.com wrote:

 I have the same issue.

 It happens when I run 1.8.1 windows client with 1.6.9 https
 repository sever. I haven't tried so many combinations ATM,
 but here are some observations:

 1.8.1 client run with 1.6.9 https:// repo server gives this issue.
 1.8.1 client run with 1.6.9 generated file:/// repositories are OK.
 1.8.1 client run with 1.7.6 generated file:/// repositories are OK.
 1.7.6 client run with 1.6.9 https:// repo server is OK.

 Whether the WC is freshly checked out by 1.8.1 client, or upgraded
 from 1.7.6 checked out WC did not change the results.

 How's the case for the original poster? Do we see something
 in common?

 # I'm reading this ML through the archives.
 --
 Hiroharu


 Hi Hiroharu

 You are indeed correct. We have done a very similar experiment here, too. We
 tried all of the above scenarios you gave. But our older client was 1.6.15,
 and we did not use https, we used http (apache 2.2)

 With the help of my colleague we have done some testing with svn 1.8.1
 (windows 7 and Ubuntu) client and svn 1.6.15 (redhat 5.5) client.

 Using the file:/// method in all cases works fine (locks NOT broken). All
 other methods also work fine, including http. Of the tests we made, the one
 which breaks the locks is: client 1.8.1; repository made with svn 1.6.15;
 protocol HTTP (apache 2.2).

 One method that we have not yet tried is: client 1.8.1; repo with svn client
 1.8.1; protocol HTTP

 How do I enabled debugging in .subversion/config or .subversion/servers? It
 used to be something like neon-debug but that's no longer available since
 1.8.1 (or 1.8)


 As of 1.8 SVN only uses the serf library for http communication, and
 no longer the neon library (before 1.8, both were part of svn, but
 neon was the default library).

 Unfortunately there is no runtime-switch (yet) to enable debug output
 with svn+serf. There is already an open enhancement request for this
 [1].

 You can enable debug logging with serf by rebuilding (see [2]).

A FYI to Johan: note that there are two levels of abstraction here:
- serf: the http library that's now used instead of neon: implements
the http protocol and sends/receives bytes over the network
- ra_serf: the subversion ra module that uses serf to communicate with
a mod_dav_svn module in an apache server via XML request/reply
messaging

If there's an issue that looks like missing or corrupted data,
connection or authentication problems then we look to the serf
library. The logging you refer to is then a good way to start
gathering info on what's going wrong.

However in this case it seems that the communication itself is ok, but
there's a potential issue in how ra_serf drives the communication
(i.e. the content of the xml requests). Serf logging will not help
here as it's a level too deep. A simple wireshark trace can help, once
the exact reproduction recipe is known.
(serf can also log request and reply output, even with https, but it's
easier to use wireshark)

Lieven

 With your combined input, this issue really starts to look like a
 serf-related issue.
 - Succeeds with file://
 - Fails with http(s), but only with 1.8 clients, not with older clients.

 To double check that it's serf-related, perhaps one of you could try
 with 1.7+serf, and see if that fails as well. You can enable serf with
 1.7 by specifying http-library=serf in the servers configuration file,
 or by passing
 --config-option servers:global:http-library=serf
 on the command line.

 Perhaps it's time to open an issue in the issue tracker for this.

 [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4407 (Provide
 serf equivalent of neon-debug-mask)

 [2] http://svn.haxx.se/users/archive-2013-07/0344.shtml

 --
 Johan

Re: Proxy error on SVN 1.8.1

[Lieven Govaerts]

Hi,

On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier
guillaume.lasn...@hybris.com wrote:
 Hi all,
 When issuing the following command, I get the following error:

 $ svn -v log
 svn: E120107: Unable to connect to a repository at URL
 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform'
 svn: E120107: Error running context: The proxy server returned an error
 while setting up the SSL tunnel.


I was able to reproduce this issue with serf trunk, reported this as
serf issue 120:
https://code.google.com/p/serf/issues/detail?id=120

The trigger is that the proxy server is configured to close the
connection after each response. In apache that would be the KeepAlive
Off flag.

It's not clear what the actual root cause is, but now that we can
reproduce it we should be able to fix this soon.

thanks for the provided info!

Lieven

 I am using subversion 1.8.1 on Mac OS X installed with homebrew.
 I have configured the proxy the following way in ~/.subversion/servers :

 [groups]
 # group1 = *.collab.net
 # othergroup = repository.blarggitywhoomph.com
 # thirdgroup = *.example.com
 mygroup = *.myhost.mydomain

 # Information for my group:
 [mygroup]
 http-proxy-host = 192.168.xxx.xxx
 http-proxy-port = 1234
 http-proxy-username = john
 http-proxy-password = doe


 This configuration used to work with subversion 1.7.

 Do have any idea?

 --

 Guillaume Lasnier

Re: Proxy error on SVN 1.8.1

[Lieven Govaerts]

Hi,

On Wed, Jul 31, 2013 at 11:30 AM, Guillaume Lasnier
guillaume.lasn...@hybris.com wrote:
 Hi Lieven,
 Please find attached the tcpdump that dumps traffic between my laptop and
 the proxy. The only information I could get about the proxy is that it's
 an ISA server.

from the trace I don't really see what's going on, the proxy returns
200 Connection Established so the ssl tunnel was setup correctly,
including proxy authentication.

Now I see that homebrew provides serf 1.2.1, also for Subversion 1.8.1
(*). Serf 1.3.0 is available which includes many fixes for the ssl
tunnel and authentication code. So I propose that you test with serf
1.3.0 first. You'll have to build svn and serf manually or wait for
the homebrew project to update serf to 1.3.0.

Note: your username and password can be extract from the trace you
sent, I suggest you change them.

Lieven

(*) https://github.com/mxcl/homebrew/commits/master/Library/Formula/serf.rb


 Regards

 --
 Guillaume Lasnier



 On 7/29/13 7:01 PM, Lieven Govaerts l...@apache.org wrote:

Hi,

On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier
guillaume.lasn...@hybris.com wrote:
 Hi all,
 When issuing the following command, I get the following error:

 $ svn -v log
 svn: E120107: Unable to connect to a repository at URL
 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform'
 svn: E120107: Error running context: The proxy server returned an error
 while setting up the SSL tunnel.

That error indicates the proxy returned an error to the CONNECT
request that svn uses to initiate the ssl tunnel.
What proxy server do you use? KeepAlive off? Specific authentication?

I think the easiest way to find out what's going on is to trace the
network traffic. Can you make a trace with fiddler or wireshark?


 I am using subversion 1.8.1 on Mac OS X installed with homebrew.
 I have configured the proxy the following way in ~/.subversion/servers :

 [groups]
 # group1 = *.collab.net
 # othergroup = repository.blarggitywhoomph.com
 # thirdgroup = *.example.com
 mygroup = *.myhost.mydomain

 # Information for my group:
 [mygroup]
 http-proxy-host = 192.168.xxx.xxx
 http-proxy-port = 1234
 http-proxy-username = john
 http-proxy-password = doe


 This configuration used to work with subversion 1.7.

Configuration looks ok, and if it has worked before then we should be
able to make it work in 1.8.1 too.

Lieven


 Do have any idea?

 --

 Guillaume Lasnier

Re: SVN 1.8.1 Errors - Show Log and Commit New Files

[Lieven Govaerts]

Hi,

On Fri, Aug 2, 2013 at 2:06 AM, Geoff Field geoff_fi...@aapl.com.au wrote:
 I have recently updated to TSVN 1.8.1, which of course uses SVN 1.8.1 as its 
 command-line basis.  Our server has been running 1.2 and has not been changed 
 (apart from Windows updates) for a LONG time.

 (Yes, I know 1.2 is very old.  However, we're an automotive company and 
 changes to our tools can result in issues with customer approvals.  
 Nonetheless, an upgrade is on the to-do list.)

A 1.8 client should have no problem communicating with any svn 1.x
server, so if that doesn't hold anymore for a 1.2 server then that's a
bug we want to fix.

 Having said that, there are now MANY people posting to the TSVN mailing list 
 about these two issues.

 My platforms are 32-bit Windows 7 and Windows XP, but it has also been 
 reported on 64-bit Windows.


 First issue: When doing a Show Log, the client says it can't contact the 
 server and asks if people (including us) want to go offline, then puts up an 
 HTTP 501 error.

 Second issue: When committing new files, we get the message that one of them 
 'already exists'.  I've found as a workaround that doing a clean checkout to 
 a NEW directory, then copying everything across and running a commit will 
 work - once.


 After discussions on the TSVN mailing list, I've run command-line versions of 
 both, with the following results (edited to hide customer names):

 C:\Customersvn log -v ./
 svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
 '/Subversio
 n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'

 svn: E27: Additional errors:
 svn: E27: The requested report is unknown.

For this part of your issue, I'm interested in seeing a network trace
(wireshark, fiddler) between your client and server. If that's
possible for you, you can send them privately. Filter out any
unrelated traffic and basic/digest authentication headers if possible.

Lieven

 C:\Customersvn commit ./ -m Committing via command line
 Adding  (bin)  DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDrlLimits.xlsx
 svn: E155011: Commit failed (details follow):
 svn: E155011: File 
 'C:\Customer\DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDr
 lLimits.xlsx' is out of date
 svn: E175005: File 'OtherInputFiles/CustomerDrlLimits.xlsx' already exists

 C:\Customersvn --version
 svn, version 1.8.1 (r1503906)
compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows

 Copyright (C) 2013 The Apache Software Foundation.
 This software consists of contributions made by many people;
 see the NOTICE file for more information.
 Subversion is open source software, see http://subversion.apache.org/

 The following repository access (RA) modules are available:

 * ra_svn : Module for accessing a repository using the svn network protocol.
   - with Cyrus SASL authentication
   - handles 'svn' scheme
 * ra_local : Module for accessing a repository on local disk.
   - handles 'file' scheme
 * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
   - handles 'http' scheme
   - handles 'https' scheme

 Regards,

 Geoff

Re: SVN 1.8.1 Errors - Show Log and Commit New Files

[Lieven Govaerts]

On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin
philip.mar...@wandisco.com wrote:
 Philip Martin philip.mar...@wandisco.com writes:

 Lieven Govaerts l...@apache.org writes:

 C:\Customersvn log -v ./
 svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
 '/Subversio
 n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'

 svn: E27: Additional errors:
 svn: E27: The requested report is unknown.

Geoff, can you log an issue in our issue tracker with reference to
this mail thread?
http://subversion.tigris.org/issue-tracker.html

 For this part of your issue, I'm interested in seeing a network trace
 (wireshark, fiddler) between your client and server. If that's
 possible for you, you can send them privately. Filter out any
 unrelated traffic and basic/digest authentication headers if possible.

 That's easy to reproduce using 1.1.4 mod_dav_svn:

 svnadmin create repo --compatible-version 1.1
 svn mkdir -mm file://`pwd`/repo/A
 svn co http://localhost/repo/A wc
 svn log -v wc

 The client is sending a get-location-segments REPORT request which is
 new in 1.5 and not supported by earlier mod_dav_svn.

 In libsvn_ra/ra-loader.c:svn_ra_get_location_segments the failure of the
 get-location-segments REPORT is expected to generate
 SVN_ERR_RA_NOT_IMPLEMENTED:

   if (err  (err-apr_err == SVN_ERR_RA_NOT_IMPLEMENTED))
 {
   svn_error_clear(err);

   /* Do it the slow way, using get-logs, for older servers. */
   err = svn_ra__location_segments_from_log(session, path,
peg_revision, start_rev,
end_rev, receiver,
receiver_baton, pool);
 }

 but libsvn_ra_serf is returning SVN_ERR_RA_DAV_REQUEST_FAILED

 (gdb) p err[0]
 $3 = {apr_err = 175002, message = 0x76f85e7d traced call,
   child = 0x77f300a0, pool = 0x77f30028,
   file = 0x75a4ab60 
 ../src/subversion/libsvn_ra_serf/getlocationsegments.c, line = 205}
 (gdb) p err[0].child[0]
 $4 = {apr_err = 175002,
   message = 0x77f300f0 Unexpected HTTP status 501 'Method Not 
 Implemented' on '/obj/repo/!svn/bc/1/A'\n, child = 0x77f30140, pool = 
 0x77f30028,
   file = 0x75a4edf0 ../src/subversion/libsvn_ra_serf/util.c, line = 
 2440}

Can you test if attached patch fixes this issue?

Lieven


 --
 Philip Martin | Subversion Committer
 WANdisco | Non-Stop Data
Index: subversion/libsvn_ra_serf/util.c
===
--- subversion/libsvn_ra_serf/util.c(revision 1510435)
+++ subversion/libsvn_ra_serf/util.c(working copy)
@@ -2434,6 +2434,10 @@ svn_ra_serf__error_on_status(serf_status_line slin
   server or an intermediate proxy does not accept 
   chunked encoding. Try setting 'http-chunked-requests' 
   to 'auto' or 'no' in your client configuration.));
+  case 501:
+return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
+ _(The requested feature is not supported by 
+   '%s'), path);
 }
 
   if (sline.code = 300)

Re: SVN 1.8.1 Errors - Show Log and Commit New Files

[Lieven Govaerts]

On Mon, Aug 5, 2013 at 7:08 PM, Philip Martin
philip.mar...@wandisco.com wrote:
 Lieven Govaerts l...@apache.org writes:

 Can you test if attached patch fixes this issue?

 Index: subversion/libsvn_ra_serf/util.c
 ===
 --- subversion/libsvn_ra_serf/util.c  (revision 1510435)
 +++ subversion/libsvn_ra_serf/util.c  (working copy)
 @@ -2434,6 +2434,10 @@ svn_ra_serf__error_on_status(serf_status_line slin
server or an intermediate proxy does not accept 
chunked encoding. Try setting 
 'http-chunked-requests' 
to 'auto' or 'no' in your client configuration.));
 +  case 501:
 +return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
 + _(The requested feature is not supported 
 by 
 +   '%s'), path);
  }

if (sline.code = 300)

 Yes, it does.  It also affects mergeinfo:

 $ svn1.8 mergeinfo ^/ wc
 svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
 '/obj/repo/!svn/bc/1/A'
 svn: E27: Additional errors:
 svn: E27: The requested report is unknown.

 $ subversion/svn/svn mergeinfo ^/ wc
 svn: E27: Retrieval of mergeinfo unsupported by 
 'http://localhost:/obj/repo/A'


To be clear, this mergeinfo error is to be expected, and this patch
has improved the error message. Or did you see a regression here?
Lieven

 --
 Philip Martin | Subversion Committer
 WANdisco | Non-Stop Data

Re: Proxy error on SVN 1.8.1

[Lieven Govaerts]

Hi,

On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier
guillaume.lasn...@hybris.com wrote:
 Hi all,
 When issuing the following command, I get the following error:

 $ svn -v log
 svn: E120107: Unable to connect to a repository at URL
 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform'
 svn: E120107: Error running context: The proxy server returned an error
 while setting up the SSL tunnel.

That error indicates the proxy returned an error to the CONNECT
request that svn uses to initiate the ssl tunnel.
What proxy server do you use? KeepAlive off? Specific authentication?

I think the easiest way to find out what's going on is to trace the
network traffic. Can you make a trace with fiddler or wireshark?


 I am using subversion 1.8.1 on Mac OS X installed with homebrew.
 I have configured the proxy the following way in ~/.subversion/servers :

 [groups]
 # group1 = *.collab.net
 # othergroup = repository.blarggitywhoomph.com
 # thirdgroup = *.example.com
 mygroup = *.myhost.mydomain

 # Information for my group:
 [mygroup]
 http-proxy-host = 192.168.xxx.xxx
 http-proxy-port = 1234
 http-proxy-username = john
 http-proxy-password = doe


 This configuration used to work with subversion 1.7.

Configuration looks ok, and if it has worked before then we should be
able to make it work in 1.8.1 too.

Lieven


 Do have any idea?

 --

 Guillaume Lasnier

Re: Problem with SSL Client auth and libserf

[Lieven Govaerts]

Hi,

On Thu, Jul 25, 2013 at 4:25 PM, Bernd May
be...@net.t-labs.tu-berlin.de wrote:
 Hello,

 I am experiencing re-negotiation issues namely connection closed when
 trying to use a subversion client =1.8 against an svn server running

 Debian Wheezy
 apache 2.2.22
 libapache 1.8.1
 subversion 1.8.1
 openssl 1.0.1e

 with ssl client auth.

[..]

 [Thu Jul 25 16:20:12 2013] [info] [client myip] Requesting connection
 re-negotiation
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O
 error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3]
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(764): [client
 myip] Performing full renegotiation: complete handshake protocol
 (client does support secure renegotiation)
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL:
 Handshake: start
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: SSL renegotiate ciphers
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: SSLv3 write hello request A
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: SSLv3 flush data
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: SSLv3 write hello request C
 [Thu Jul 25 16:20:12 2013] [info] [client myip] Awaiting
 re-negotiation handshake
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL:
 Handshake: start
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: before accept initialization
 [Thu Jul 25 16:20:22 2013] [info] [client myip] Request body read timeout
 [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O
 error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3]
 [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_kernel.c(1903): OpenSSL:
 Exit: error in SSLv3 read client hello B
 [Thu Jul 25 16:20:22 2013] [error] [client myip] Re-negotiation
 handshake failed: Not accepted by client!?
 [Thu Jul 25 16:20:22 2013] [debug] mod_deflate.c(615): [client myip]
 Zlib: Compressed 0 to 2 : URL /svn/bernd


This renegotiation issue was solved on serf trunk in r2078, details in
the ticket you opened:
https://code.google.com/p/serf/issues/detail?id=114

r2078 applies cleanly to the serf 1.3.x branch, so if you can validate
the fix before I backport it to 1.3.x that'd be much appreciated!

thanks,

Lieven


 --
 Technische Universität Berlin - FGINET

 Bernd May

 System Administration
 Sekr. TEL 16
 Ernst-Reuter-Platz 7
 10587 BERLIN
 GERMANY

 Mobile: 0160/90257737
 E-Mail: be...@inet.tu-berlin.de
 WWW:inet.tu-berlin.de

Re: Problem with SSL Client auth and libserf

[Lieven Govaerts]

Hi,

On Thu, Jul 25, 2013 at 4:25 PM, Bernd May
be...@net.t-labs.tu-berlin.de wrote:
 Hello,

 I am experiencing re-negotiation issues namely connection closed when
 trying to use a subversion client =1.8 against an svn server running

 Debian Wheezy
 apache 2.2.22
 libapache 1.8.1
 subversion 1.8.1
 openssl 1.0.1e

 with ssl client auth.

 I have now spent about 4 hours of searching through old ssl client auth
 errors in the openssl issues, subversion maillinglist and tried the
 following combinations of client libraries and binaries against the
 server mentioned above:

 * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1
 * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e

 Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive
 the following error on the client side, regardless of the openssl version:

 svn: E120108: Unable to connect to a repository at URL
 'https://example.com/svn/myrepo'
 svn: E120108: Error running context: The server unexpectedly closed the
 connection.

 Disabling the 'SSLVerifyClient Require' directive yields a successful
 listing of the svn content, so this really appears to be related to
 client auth.
 Using an svn client with libneon also yields a successful repository
 listing so this points quite directly at libserf.

 On the server side the error messages in debug mode look like this:

 ... initial ssl connection setup completes ...
 [Thu Jul 25 16:20:12 2013] [info] Initial (No.1) HTTPS request received
 for child 77 (server inet-svn.net.t-labs.tu-berlin.de:443)
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(510): [client
 myip] Changed client verification type will force renegotiation
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1554): [client
 myip] filling buffer, max size 131072 bytes
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1606): [client
 myip] total of 131 bytes in buffer, eos=1
 [Thu Jul 25 16:20:12 2013] [info] [client myip] Requesting connection
 re-negotiation
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O
 error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3]
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(764): [client
 myip] Performing full renegotiation: complete handshake protocol
 (client does support secure renegotiation)
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL:
 Handshake: start
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: SSL renegotiate ciphers
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: SSLv3 write hello request A
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: SSLv3 flush data
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: SSLv3 write hello request C
 [Thu Jul 25 16:20:12 2013] [info] [client myip] Awaiting
 re-negotiation handshake
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1866): OpenSSL:
 Handshake: start
 [Thu Jul 25 16:20:12 2013] [debug] ssl_engine_kernel.c(1874): OpenSSL:
 Loop: before accept initialization
 [Thu Jul 25 16:20:22 2013] [info] [client myip] Request body read timeout
 [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_io.c(1908): OpenSSL: I/O
 error, 5 bytes expected to read on BIO#7fa9ced2a820 [mem: 7fa9ced082c3]
 [Thu Jul 25 16:20:22 2013] [debug] ssl_engine_kernel.c(1903): OpenSSL:
 Exit: error in SSLv3 read client hello B
 [Thu Jul 25 16:20:22 2013] [error] [client myip] Re-negotiation
 handshake failed: Not accepted by client!?
 [Thu Jul 25 16:20:22 2013] [debug] mod_deflate.c(615): [client myip]
 Zlib: Compressed 0 to 2 : URL /svn/bernd


Renegotiation has been tested in serf, maybe it doesn''t work in all cases.


 So either the client sent garbage or not what the server expects or
 there is some kind of hiccup in the server libraries?

 If anyone could point me to a way to further debug this or a solution,
 I'd be very gracious

Enabling logging in serf will probably give you more detailed info on
the failure on the client side.
Logging can be activated by setting these flags in serf_private.h and
then rebuilding serf:
#define SSL_VERBOSE 1
#define CONN_VERBOSE 1
#define SOCK_VERBOSE 1


If you're using serf 1.2.1 you'll get a lot of log lines (100k+) but
the info you'll need will be at the end. Alternatively you can upgrade
to serf 1.3.0 where ssl logging has been cleaned up. You can send the
log files to the list or to me privately, I'll have a look.

Lieven

 --
 Technische Universität Berlin - FGINET

 Bernd May

 System Administration
 Sekr. TEL 16
 Ernst-Reuter-Platz 7
 10587 BERLIN
 GERMANY

 Mobile: 0160/90257737
 E-Mail: be...@inet.tu-berlin.de
 WWW:inet.tu-berlin.de

Re: Problem with SSL Client auth and libserf

[Lieven Govaerts]

Hi Bernd,

On Thu, Jul 25, 2013 at 5:56 PM, Lieven Govaerts l...@apache.org wrote:
 Hi,

 On Thu, Jul 25, 2013 at 4:25 PM, Bernd May
 be...@net.t-labs.tu-berlin.de wrote:
 Hello,

 I am experiencing re-negotiation issues namely connection closed when
 trying to use a subversion client =1.8 against an svn server running

 Debian Wheezy
 apache 2.2.22
 libapache 1.8.1
 subversion 1.8.1
 openssl 1.0.1e

 with ssl client auth.

 I have now spent about 4 hours of searching through old ssl client auth
 errors in the openssl issues, subversion maillinglist and tried the
 following combinations of client libraries and binaries against the
 server mentioned above:

 * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1
 * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e

 Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive
 the following error on the client side, regardless of the openssl version:

 svn: E120108: Unable to connect to a repository at URL
 'https://example.com/svn/myrepo'
 svn: E120108: Error running context: The server unexpectedly closed the
 connection.

 Disabling the 'SSLVerifyClient Require' directive yields a successful
 listing of the svn content, so this really appears to be related to
 client auth.
 Using an svn client with libneon also yields a successful repository
 listing so this points quite directly at libserf.

[..]


 Enabling logging in serf will probably give you more detailed info on
 the failure on the client side.
 Logging can be activated by setting these flags in serf_private.h and
 then rebuilding serf:
 #define SSL_VERBOSE 1
 #define CONN_VERBOSE 1
 #define SOCK_VERBOSE 1


 If you're using serf 1.2.1 you'll get a lot of log lines (100k+) but
 the info you'll need will be at the end. Alternatively you can upgrade
 to serf 1.3.0 where ssl logging has been cleaned up. You can send the
 log files to the list or to me privately, I'll have a look.


the logs you sent (via private mail) did contain all the requested
info, but it's not enough to analyse the root cause.

However, I can reproduce this by accessing my test repo with svn trunk
and serf trunk over https, with the SSLVerifyClient Require line
added to the server config. My server setup does not require client
certificates, so that is not a factor here.

Would you mind summarising this problem in a ticket in the serf issue
tracker at https://code.google.com/p/serf/issues/list ? I'll see what
I can find.

Lieven

 --
 Technische Universität Berlin - FGINET

 Bernd May

 System Administration
 Sekr. TEL 16
 Ernst-Reuter-Platz 7
 10587 BERLIN
 GERMANY

 Mobile: 0160/90257737
 E-Mail: be...@inet.tu-berlin.de
 WWW:inet.tu-berlin.de

Re: Problem with SSL Client auth and libserf

[Lieven Govaerts]

On Thu, Jul 25, 2013 at 8:53 PM, Lieven Govaerts l...@apache.org wrote:
 Hi Bernd,

 On Thu, Jul 25, 2013 at 5:56 PM, Lieven Govaerts l...@apache.org wrote:
 Hi,

 On Thu, Jul 25, 2013 at 4:25 PM, Bernd May
 be...@net.t-labs.tu-berlin.de wrote:
 Hello,

 I am experiencing re-negotiation issues namely connection closed when
 trying to use a subversion client =1.8 against an svn server running

 Debian Wheezy
 apache 2.2.22
 libapache 1.8.1
 subversion 1.8.1
 openssl 1.0.1e

 with ssl client auth.

 I have now spent about 4 hours of searching through old ssl client auth
 errors in the openssl issues, subversion maillinglist and tried the
 following combinations of client libraries and binaries against the
 server mentioned above:

 * svn client 1.6.9, 1.6.16, 1.6.17, 1.7.11, 1.8.0, 1.8.1
 * Openssl 0.9.8g, 0.9.8.k, 0.9.8o, 1.0.0, 1.0.0e

 Whenver I use the newer subversion clients (v1.8 and 1.8.1) I receive
 the following error on the client side, regardless of the openssl version:

 svn: E120108: Unable to connect to a repository at URL
 'https://example.com/svn/myrepo'
 svn: E120108: Error running context: The server unexpectedly closed the
 connection.

 Disabling the 'SSLVerifyClient Require' directive yields a successful
 listing of the svn content, so this really appears to be related to
 client auth.
 Using an svn client with libneon also yields a successful repository
 listing so this points quite directly at libserf.

 [..]


 Enabling logging in serf will probably give you more detailed info on
 the failure on the client side.
 Logging can be activated by setting these flags in serf_private.h and
 then rebuilding serf:
 #define SSL_VERBOSE 1
 #define CONN_VERBOSE 1
 #define SOCK_VERBOSE 1


 If you're using serf 1.2.1 you'll get a lot of log lines (100k+) but
 the info you'll need will be at the end. Alternatively you can upgrade
 to serf 1.3.0 where ssl logging has been cleaned up. You can send the
 log files to the list or to me privately, I'll have a look.


 the logs you sent (via private mail) did contain all the requested
 info, but it's not enough to analyse the root cause.

 However, I can reproduce this by accessing my test repo with svn trunk
 and serf trunk over https, with the SSLVerifyClient Require line
 added to the server config. My server setup does not require client
 certificates, so that is not a factor here.

This last sentence doesn't make a lot of sense, it doesn't work
because I hadn't configured my client certificate. I still can't get
it to work with a valid client certificate matching the server certs,
so need to look further.
L.

 Would you mind summarising this problem in a ticket in the serf issue
 tracker at https://code.google.com/p/serf/issues/list ? I'll see what
 I can find.

 Lieven

 --
 Technische Universität Berlin - FGINET

 Bernd May

 System Administration
 Sekr. TEL 16
 Ernst-Reuter-Platz 7
 10587 BERLIN
 GERMANY

 Mobile: 0160/90257737
 E-Mail: be...@inet.tu-berlin.de
 WWW:inet.tu-berlin.de

Re: svnsync crashes on a huge commit

[Lieven Govaerts]

Hi Anatoly,


can you build a custom version of the serf library used by your svn
client to enable logging?

Attached patch should enable the logging needed, I hope it should
clarify the original  internal malfunction error you reported
earlier.
You can send the log output to me privately, probably will be a big file.

On Thu, Jul 11, 2013 at 12:04 PM, Anatoly Zapadinsky
zapadin...@gmail.com wrote:
 I've increased swap size to 8gb, increased opened files handles limit to
 200k and ran the process at night when the server is not very busy.

 Finally svnsync form a revision copy in db, but hang after it. It didn't
 print Committed revision just hanged on a set of dots after Transmitting
 file data. I've killed it and ran svnadmin verify. The revision copy
 seems to be fine. And it was successfully packed by svnadmin pack at the end
 of mirroring process.

 svnsync is a buggy crap! I guarantee this. And no one cares. No one going to
 opened an issue.

I propose *you* open an issue in the issue tracker
(http://subversion.tigris.org/issue-tracker.html). We'll need some
more information though, especially the platform of both your client
and server, and the exact svnsync init and svnsync sync commands you
use (without username  password info, that's not needed).

regards,

Lieven



 On Tue, Jul 9, 2013 at 3:30 PM, Anatoly Zapadinsky zapadin...@gmail.com
 wrote:

 svnsync failed to sync repository with a single commit containing 56000
 files. This commit handled perfectly by console svn and tortoise svn. We can
 checkout this folder structure and so on. But when I tried to sync this
 commit to the local mirror repository it fails.
 32 bit version of svnsync crashed with out of memory exception.
 64 bit version made a transaction folder containing 117000 files in it,
 allocated like 3gb of memory and finally crashed with this diagnostic: svn:
 E235000: In file 'subversion/libsvn_ra_serf/util.c' line 1649: internal
 malfunction.
 May be this commit is not an example of the best practice but it crash
 only svnsync all the other svn tools handle it perfectly.
 What should I do? How to mirror this repository? Is it a bug or not?


Index: serf_private.h
===
--- serf_private.h  (revision 1905)
+++ serf_private.h  (working copy)
@@ -32,12 +32,12 @@
 
 /* Internal logging facilities, set flag to 1 to enable console logging for
the selected component. */
-#define SSL_VERBOSE 0
+#define SSL_VERBOSE 1
 #define SSL_MSG_VERBOSE 0  /* logs decrypted requests and responses. */
-#define SOCK_VERBOSE 0
+#define SOCK_VERBOSE 1
 #define SOCK_MSG_VERBOSE 0 /* logs bytes received from or written to a socket. 
*/
-#define CONN_VERBOSE 0
-#define AUTH_VERBOSE 0
+#define CONN_VERBOSE 1
+#define AUTH_VERBOSE 1
 
 
 typedef struct serf__authn_scheme_t serf__authn_scheme_t;

Re: [PATCH 2/2] git-svn: allow git-svn fetching to work using serf

[Lieven Govaerts]

On Sun, Jul 7, 2013 at 4:48 PM, Kyle McKay mack...@gmail.com wrote:
 On Jul 7, 2013, at 06:39, Daniel Shahaf wrote:

 Kyle McKay wrote on Sat, Jul 06, 2013 at 19:46:40 -0700:

 On Jul 6, 2013, at 19:23, Jonathan Nieder wrote:

 Kyle McKay wrote:

 Unless bulk updates are disabled when using the serf access method
 (the only one available with svn 1.8) for https?: urls,
 apply_textdelta does indeed get called multiple times in a row
 without an intervening temp_release.


 You mean Unless bulk updates are enabled and without an intervening
 close_file, right?


 The problem seems to be skelta mode although it may just be the fact
 that ra_serf has multiple connections outstanding and since ra_neon only
 ever has one it can't happen over ra_neon.

 If the server disables bulk updates (SVNAllowBulkUpdates Off) all
 clients are forced to use skelta mode, even ra_neon clients.


 As Brane and I have pointed out, git-svn can instruct libsvn_* to use
 bulk updates regardless of the server version, by setting
 SVN_CONFIG_OPTION_HTTP_BULK_UPDATES (new in 1.8).

 If you have questions about that, though, please address them to
 users@subversion.apache.org (the proper list for API usage questions),
 not to me personally.


 According to the table at
 http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default,
 if the server sets SVNAllowBulkUpdates Off, the client will be forced to use
 skelta no matter what the client setting is.

Indeed, the server admin has the final say in which mode is actually
used. SVNAllowBulkUpdates Off is only advised if the server admin
wants a log line per accessed resource. I doubt it's used a lot, but
the option is there.


 Is that table incorrect?

No, that table is correct.

 Kyle

Lieven

Re: SVN 1.8.0 segmentation fault behind proxy on Mac OS X

[Lieven Govaerts]

Hi Guillaume,


thanks for the report.

On Tue, Jul 2, 2013 at 11:56 AM, Guillaume Lasnier
guillaume.lasn...@hybris.com wrote:
 Hi,
 Please find below the content of the crash log:

 Process: svn [29901]
 Path:/usr/local/Cellar/subversion/1.8.0/bin/svn
 Identifier:  svn
 Version: 0
 Code Type:   X86-64 (Native)
 Parent Process:  bash [47372]
 User ID: 1487951899

 Date/Time:   2013-07-02 11:19:42.732 +0200
 OS Version:  Mac OS X 10.8.4 (12E55)
 Report Version:  10
 Sleep/Wake UUID: C3009E0E-2CB9-4556-AAD0-09ECAC6E2DFA

 Interval Since Last Report:  41279 sec
 Crashes Since Last Report:   1
 Per-App Crashes Since Last Report:   1
 Anonymous UUID:  79280656-DCE2-27AC-92A0-FF685CC020F5

 Crashed Thread:  0  Dispatch queue: com.apple.main-thread

 Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
 Exception Codes: KERN_INVALID_ADDRESS at 0x01b0

 VM Regions Near 0x1b0:
 --
 __TEXT 00010816e000-000108198000 [  168K]
 r-x/rwx SM=COW  /usr/local/Cellar/subversion/1.8.0/bin/svn

 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
 0   libsvn_ra_serf-1.0.dylib0x00010837c7dd
 svn_ra_serf__credentials_callback + 77

Based on this line I think your connecting to a repository on a https
server using a http proxy. The setup of the ssl tunnel when the proxy
requires authentication is broken in serf 1.2.1 used in svn 1.8.1.

You can find more details here:
http://svn.haxx.se/dev/archive-2013-06/0490.shtml

The issue is fixed in serf and will be included in the next release.

Lieven

[..]




 Regards,

 --
 Guillaume Lasnier






 On 7/2/13 11:50 AM, Ryan Schmidt subversion-20...@ryandesign.com wrote:

On Jul 2, 2013, at 04:29, Guillaume Lasnier wrote:

 When I try to access a repo behind a proxy I get a segmentation fault
error.

What does the crash log say? On recent versions of OS X it should have
been saved in ~/Library/Logs/DiagnosticReports.

Re: svnsync 1.8.0 fails if htdigest authentication is used

[Lieven Govaerts]

Hi,

On Tue, Jul 2, 2013 at 9:38 PM, Vadym Chepkov vchep...@gmail.com wrote:
 Bert,

 Master had KeepAlive on, replica - KeepAlive Off


as Bert said, Digest authentication to servers configured with
KeepAlive Off is currently broken in serf 1.2.1, the version used in
svn 1.8.0.
I have a patch that fixes this, as soon as I finish the unit test I'll
commit to serf trunk and make sure it gets included in serf 1.3.0.

Now, I can only advise you to always use KeepAlive On for the server
hosting your Subversion repositories. Svn will make many (small)
requests to the server, and in your configuration a new TCP connection
is opened for every request. I've noticed svnsync performing much
slower with KeepAlive Off.

Lieven


 On Tue, Jul 2, 2013 at 3:32 PM, Bert Huijben b...@qqmail.nl wrote:

 Hi Vadym,



 We found a related issue while testing the serf http code, which might be
 related to your issue.



 Can you somehow check if your repository has the ‘KeepAlive’ option
 configured to off? In this case the digest code in serf performs every
 request without authentication, because it would only try to use
 authentication on later requests on the same connection



 If that is the case, it looks like this issue will be resolved with the
 next serf release. (Which should happen with or before Subversion 1.8.1).



 Bert



 [Added CC to one of the serf developers, who isn’t subscribed to this
 list]



 From: Vadym Chepkov [mailto:vchep...@gmail.com]
 Sent: maandag 1 juli 2013 18:32
 To: Bert Huijben
 Cc: users@subversion.apache.org; Ryan Schmidt


 Subject: Re: svnsync 1.8.0 fails if htdigest authentication is used



 Bert,



 I would be happy to provide debugging information, but as I said, I had to
 rollback to 1.7.10.



 If I ran it interactively, authentication just didn't go through, so it
 looked like the username or password is incorrect.

 After I reverted back to 1.7.10  everything works as expected.



 svnsync is called from a hook on the master server :



 #!/bin/ksh

 REPOS=`basename $1`

 TMPFILE=/var/tmp/svnsync.$$

 /usr/bin/svnsync sync --non-interactive --quiet \

 --sync-username svnsync http://example.com/reposync/${REPOS}  $TMPFILE
 21

 if [[ $? -ne 0  -s $TMPFILE ]] ; then

   mail -s svnsync failed root  $TMPFILE

 fi

 rm -f $TMPFILE

 exit 0



 Slave server is properly initialized:



 sudo -u apache svn pg  svn:sync-from-url --revprop -r 0  --username
 svnsync http://example.com/reposync/repo1



 http://example.com/svn/repo1





 I was receiving errors like this in e-mail:



 svnsync: E175002: Unable to connect to a repository at URL
 'http://example.com/reposync/repo1'
 svnsync: E175002: OPTIONS of 'http://example.com/reposync/repo1': could
 not connect to server (http://example.com)



 or this



 svnsync: E175002: PROPFIND of '/reposync/repo2/!svn/rev/0': could not
 connect to server (http://example.com)





 Regards,

 Vadym





 On Mon, Jul 1, 2013 at 12:07 PM, Bert Huijben b...@qqmail.nl wrote:



  -Original Message-
  From: Vadym Chepkov [mailto:vchep...@gmail.com]
  Sent: zondag 30 juni 2013 22:58
  To: Ryan Schmidt
  Cc: users@subversion.apache.org
  Subject: Re: svnsync 1.8.0 fails if htdigest authentication is used
 
 
  On Jun 30, 2013, at 2:18 PM, Ryan Schmidt wrote:
 
  
   On Jun 30, 2013, at 07:06, Vadym Chepkov wrote:
  
   After I upgraded to 1.8.0, svnsync process started to fail. I am
   using
  apache 2.2.3. I suspect it's really serf's problem (1.2.1), but
 nevertheless I had
  to revert back to 1.7.10. Is this a known limitation?
  
   You said you upgraded to 1.8.0. Was that the computer running svnsync,
 or
  the server serving the original repository, or both?
  
   What error message did you get?
 
 
  Both source and destination run under Linux. Authentication fails, I see
 401 in
  the apache's access log.
 

 Hi,

 I expected a problem related to some recent fixes in serf that should be
 available in the next release, but one of the serf developers ensured me
 that it was not this problem.

 @lgo Bert: serf 1.2.1 fixed an issue with htdigest, no server
 authentication issues are known.
 @lgo I have no problem syncing a repository on a server using digest
 either
 @lgo that is, from a repository over ra_serf with digest authn to
 ra_local.
 @lgo The thread on users doesn't contain a lot of info, and I'm not
 subscribed to users. So if you can get some more info about his setup,
 exact
 error message, whether that's directly or after a while ... I will look
 into
 it further.

 So I would repeat Ryan's request. Can you show us what goes wrong (with
 what
 error) and how we can reproduce this problem?

 It is quite interesting to know if this happens directly at the start or
 after a huge chunk of work was completed.

 Bert

Re: Undocumented: ssl-pkcs11-provider - What is a «Security Provider»?

[Lieven Govaerts]

On Sat, Aug 25, 2012 at 6:35 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
 += dev@, please drop users@ from replies

 Marc Wäckerlin wrote on Wed, Aug 22, 2012 at 09:27:14 +0200:
 Hi

 I got a proprietary PKCS#11 library (for Post SuisseID smartcard) in
 /usr/lib/libcvP11.so.

 There is a configuration option «ssl-pkcs11-provider» in 
 ~/.subversion/servers.

 But it is absolutely undocumented what this option is, even google doesn't 
 find
 anything useful. The only documentation is: «Name of PKCS#11 provider to 
 use».

 How is the «Name of PKCS#11 provider» defined? It is *not* the name of the
 PKCS#11 library, so what is it?


 If you build svn against neon 0.28 or greater, the value of that option
 is passed is passed to ne_ssl_pkcs11_provider_init():
 https://svn.apache.org/repos/asf/subversion/branches/1.7.x/subversion/libsvn_ra_neon/session.c

 However, current trunk no longer uses the ssl-pkcs11-provider option,
 but still generates a config file that documents it.  (The option was
 originally added in r869495(r29421) by jorton for libsvn_ra_neon.
 (Marc: libsvn_ra_neon is no longer supported in trunk/1.8-to-be; only
 libsvn_ra_serf will be available for http/https access.))

 We should at least update the config file that trunk generates.  We
 might want to teach libsvn_ra_serf to support that config option (for
 compatibility reasons).


This feature is currently missing from serf:
https://code.google.com/p/serf/issues/detail?id=27

I have this on my todo list somewhere, but currently working on other
serf-ssl related stuff.

[..]

Lievne

Re: subversion crash report

[Lieven Govaerts]

On Wed, Mar 16, 2011 at 11:08 PM, Ryan Schmidt
subversion-20...@ryandesign.com wrote:

 On Mar 16, 2011, at 14:20, Darryl Fenwick wrote:

  Apologies for the non-descriptive e-mail previously.  I was either updating 
  or committing, I'm don't remember.  Sorry - not very helpful perhaps.

You were updating your trunk working copy, says so at the top of the log file:

Process info:
Cmd line: svn  up trunk

Is that trunk folder located directory under the root of a drive?

Based on the code in svn_dirent_is_child(), this might be related to:
http://subversion.tigris.org/issues/show_bug.cgi?id=3795


  My subversion (version 1.6.15) on my 64-bit windows 7 machine has been 
  unstable.  I get a lot of complaints about not being able to copy files 
  from the tmp directory, etc, when I try to update.
 

What type of complaints?

  If you wish, I can continue to send you more information if ever I 
  encounter problems.  Let me know.
 
  Darryl

 If you have further information to add, please do send it, but to the list, 
 not to me personally. I'm Cc'ing the list on this reply again.


Lieven

Re: crash report

[Lieven Govaerts]

On Fri, Oct 8, 2010 at 6:32 PM, Wolff, Dave davidwo...@letu.edu wrote:
 The following happens every time I try to update a development branch to the
 head of another branch.  Let me know if there’s anything I can do to help
 get you more information.


This looks like the previously reported issue in sliksvn:
http://svn.haxx.se/users/archive-2010-09/0065.shtml

hth,

Lieven

Re: Reverse merge - Halted due to an unexpected erro

[Lieven Govaerts]

On Tue, Aug 31, 2010 at 12:43 PM, Bert Huijben b...@qqmail.nl wrote:


 -Original Message-
 From: Stefan Sperling [mailto:s...@elego.de]
 Sent: dinsdag 31 augustus 2010 12:22
 To: Daniel Becroft
 Cc: subversion
 Subject: Re: Reverse merge - Halted due to an unexpected erro

 On Tue, Aug 31, 2010 at 12:54:00PM +1000, Daniel Becroft wrote:
  Hi all,
 
  I've just tried to reverse-merge a revision, and I've received the
 following
  message:
 
  svn merge -c -9654 .../tools tools
 
   BEGIN CONSOLE OUTPUT -
  This application has halted due to an unexpected error.
  A crash report and minidump file were saved to disk, you can find
 them here:
  C:\Users\x\AppData\Local\Temp\14\svn-crash-log20100831124530.log
  C:\Users\x\AppData\Local\Temp\14\svn-crash-log20100831124530.dmp
  Please send the log file to users@subversion.apache.org to help us
 analyse
  and solve this problem.
 
  NOTE: The crash report and minidump files can contain some sensitive
  information
  (filenames, partial file content, usernames and passwords etc.)
  - END CONSOLE OUTPUT -
 
  I can replicate this very easily with a fresh checkout, and it isn't
  revision specific (I've tried another revision and received the same
 error).
 
 
  My environment is: Windows Server 2008 R2 (64-bit), svn 1.6.12
 (SlikSVN) x64
 
  svn, version 1.6.12 (SlikSvn/1.6.12) X64
     compiled Jun 22 2010, 21:00:12
 
  Copyright (C) 2000-2009 CollabNet.
  Subversion is open source software, see http://subversion.tigris.org/
  This product includes software developed by CollabNet (
  http://www.Collab.Net/).
 
  The following repository access (RA) modules are available:
 
  * ra_neon : Module for accessing a repository via WebDAV protocol
 using
  Neon.
    - handles 'http' scheme
    - handles 'https' scheme
  * ra_svn : Module for accessing a repository using the svn network
 protocol.
    - with Cyrus SASL authentication
    - handles 'svn' scheme
  * ra_local : Module for accessing a repository on local disk.
    - handles 'file' scheme
  * ra_serf : Module for accessing a repository via WebDAV protocol
 using
  serf.
    - handles 'http' scheme
    - handles 'https' scheme
 
  The strange thing is, everything works on my Windows XP Pro
 workstation with
  32-bit.

 I'm not a windows expert, but this looks like a problem with
 64bit/32bit
 library mismatches. SlikSvn reports itself as 64bit, but the crashdump
 shows that quite a few *32.dll files are loaded -- is that normal?

 The system32 directory on Windows contains the 64 bit files, so it loads the
 right files. (The 32 bit files are in the SYSWOW32 directory, which some 32
 bit applications might see as if it is SYSTEM32 directory if they have a
 compatibility shim).

 The dump file (.dmp) of this crash doesn't contain useful information. (The
 stack trace it contained is from after the actual crash). The .log file
 looks similar to one I recently noticed on another subversion mailing list

This one:
http://svn.haxx.se/users/archive-2010-08/0436.shtml

L.

Re: SVN 1.6.12 crash on merge.

[Lieven Govaerts]

On Tue, Aug 24, 2010 at 8:26 PM, Andy Levy andy.l...@gmail.com wrote:
 On Tue, Aug 24, 2010 at 08:55, Pavel Ivanov pavel.iva...@acronis.com wrote:


 When reporting a crash, it is much more helpful if you can attach a
 sample repository  exact steps (preferably a script) which will
 reliably reproduce the issue. Just attaching dumps  logs without
 explaining how you got there is going to make things difficult for
 someone trying to help you.

If companies/people offering windows cmd-line client binaries build an
unchanged subversion (which is what I expect them to do) then users
will see the standard windows crash reporter message, which asks them
to send the crash log file to this mailing list.

I agree with your point, a reproduction recipe would be helpful. We
could probably be a bit more explicit about this in our message to the
users.

Lieven

Re: SSL handshake failed: SSL error: A TLS warning alert has been received.

[Lieven Govaerts]

On Wed, Aug 11, 2010 at 4:24 PM, Gero g...@ieee.org wrote:
 Hi,

 After moving to a new system (Kubuntu Hardy - Lucid) I can no longer access
 an SVN repository:

 $ svn update
 svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL handshake
 failed: SSL error: A TLS warning alert has been received.
 (https://example.com)

 I assume the old svn client version was 1.4.6:
 http://packages.ubuntu.com/hardy/subversion The new version is 1.6.6.

 The repository has other users for whom it continues to work.

 Any ideas what is going on?

Can you still access that folder with a web browser, without a
certificate warning?
I think 1.6.6 is more strict on validating server certificates as
1.4.6, not sure though.

Lieven

Re: SSL handshake failed: SSL error: A TLS warning alert has been received.

[Lieven Govaerts]

On Wed, Aug 11, 2010 at 8:28 PM, Gero g...@ieee.org wrote:
 On Wed, 2010-08-11, Lieven Govaerts wrote:
 On Wed, Aug 11, Gero wrote:
  Hi,
 
  After moving to a new system (Kubuntu Hardy - Lucid) I can no longer
  access
  an SVN repository:
 
  $ svn update
  svn: OPTIONS of 'https://example.com/path/to/svn/trunk': SSL handshake
  failed: SSL error: A TLS warning alert has been received.
  (https://example.com)
 
  I assume the old svn client version was 1.4.6:
  http://packages.ubuntu.com/hardy/subversion The new version is 1.6.6.
 
  The repository has other users for whom it continues to work.
 
  Any ideas what is going on?

 Can you still access that folder with a web browser, without a
 certificate warning?
 I think 1.6.6 is more strict on validating server certificates as
 1.4.6, not sure though.

 Yes, web access still works with no warnings.


Well, that error message isn't telling a lot. Might be interesting to
find out what's logged in the server's error log.

Lieven

Re: Migrating to SVN from zipfile-based archival. Advice?

[Lieven Govaerts]

[..]

 Is the SVN server smart enough to realize that, even if I follow this
 course of action, that

 /trunk/foo/bar.c
 /tags/release1/foo/bar.c
 /tags/release2/foo/bar.c

 are all the same file with minor (if any) differences?

 If you do this you are going to get several copies.

 What I would do is create a trunk and import the oldest ZIP that you have. 
 Then get a check out of trunk and copy your next version over it. Do and 
 add and commit then tag it. Continue.

 Actually, there is a utility that is designed to import ZIPs that are 
 different versions. Although now that everything is at apache.org I don't 
 know where to find all the little utilties that used to be on tigris.org... 
 and they don't seem to be at tigris.org either.


All files from svn.collab.net have been copied to svn.apache.org.
You're probably talking about svn_load_dirs.pl, which is the tool that
the documentation refers to in the 'vendor drop' chapter. You can find
it here:
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/

hth,

Lieven

Re: Subversion source code missing ??

[Lieven Govaerts]

On Thu, May 20, 2010 at 8:47 AM, John Buehrer j...@zuri.ch wrote:

 Hi,

 The Subversion source code has disappeared today: Thursday, 20-May-2010
 Am I looking in the wrong place?
 I already asked on IRC chat:  irc.freenode.net / #svn
 These main sites  mirrors are empty of Subversion source-code content:

 http://svncorp.org
 http://subversion.tigris.org

 http://subversion.apache.org/source-code.html
 http://subversion.apache.org

The subversion site was down a few hours ago, but it has been fixed since.

Lieven

Re: SVN error: (501 Not Implemented) while creating dir

[Lieven Govaerts]

On Thu, Mar 4, 2010 at 12:33 PM, Hussein Baghdadi hubaghd...@yahoo.cawrote:

 Hey,
 I'm trying to create a branches directory for our project:
 svn mkdir -m Creating branches directory
 http://local.domain/OoProject/branches

But I got this error:

svn: Server sent unexpected return value (501 Not Implemented) in response
 to OPTIONS request for 'http://local.domain/OoProject'

[..]

Wild guess, is that really your project's repository location? Typically
(but not always) apache is configured to host all repositories under /svn or
/repos, which would make the url
http://local.domain/svn/OoProject/brancheshttp://local.domain/OoProject/branches

Lieven

Re: subversion 1.6.6 coredumping

[Lieven Govaerts]

On Sat, Jan 23, 2010 at 11:57 PM, troels knak-nielsen
troel...@gmail.com wrote:
 Hi list.

 I've just installed svn from ports on FreeBSD. It works for some
 operations, but I get a coredump when running the following:

 # svn export http://svn.facebook.com/svnroot/platform/clients/php/trunk
 facebook-api
 svn: In file 'subversion/libsvn_ra_serf/update.c' line 1620: internal
 malfunction
 Abort trap: 6 (core dumped)

Can you send the stacktrace found in the core dump?

Lieven

Re: Partial Commits of an individual file?

[Lieven Govaerts]

On Tue, Jan 19, 2010 at 2:10 AM, Andrew Thorburn nzi...@gmail.com wrote:
 I'm wondering if there has been any discussion about the ability to
 commit bits and pieces of a file.

 e.g.:

 I have a particular bit of code in a project I'm working on which is
 very large (too large), and I frequently need to make changes to it
 for multiple issues. This means that when I go to commit, I have to
 make a single commit which fixes or implements multiple issues. This
 isn't really ideal, as it means that you can't look at the diffs of
 the file to see which change applies to which issue - you just see a
 nice big list of changes, and have to guess at what changes apply to
 what issue.

 I can't always commit straight away, as I need to wait for
 confirmation that the fix is *actually* required, so I might move on
 to the next issue which could require changes to the same file.

 Ideally, I would like to be able to select the lines I want to commit
 (or not commit, as the case may be),

While I'd like to have such a  feature in svn, I don't think this is
what you need (as Tyler also indicates in his response).

If you work on one issue after the other, you can commit your work on
some temporary branch (shelf,...). When it's decided that the fix is
needed, you can merge the changes from your temporary branch to your
main development branch easily. With this approach your work is cut
into pieces (per issue), it's safe in the repository and your working
copy is clean to continue working on other issues.

I'd never use a 'commit only these chunks of these files' tool on Java
code. You build and probably test your code before commit, and if you
only take parts of it and move those to the repository, you risk that
the resulting commit will break the build on your branch.

What such a tool would be handy for is when working with text files
(documents), HTML etc. I'm thinking of committing parts of a file,
reverting chunks of change set or marking such chunks as to-be-ignored
during a commit.

 but as far as I'm aware, this isn't possible with SVN, or any third-party 
 tools?

Not that I'm aware of.

[..]

Lieven