Description of problem: I'm trying to check out a googlecode repository -- which worked fine when I last tried this (several months ago) -- and I'm getting the above error from both the command-line subversion client and the Eclipse "subclipse" plugin. Version-Release number of selected component (if applicable): subversion-1.6.17-1.fc15.x86_64 How reproducible: Every time Steps to Reproduce (using a random googlecode project for demo purposes): 1. svn checkout https://google-web-toolkit.googlecode.com/svn/trunk/ test Actual results: svn: OPTIONS of 'https://google-web-toolkit.googlecode.com/svn/trunk': SSL handshake failed: Secure connection truncated (https://google-web-toolkit.googlecode.com) Expected results: Being prompted for login credentials at the very least Additional info: Based on a bit of web surfing, I've tried deleting my .ssh and .subversion directories; no change to the above issue.
That works for me. Do you have a proxy between yourself and the server? Please try: $ svn checkout --config-option servers:global:neon-debug-mask=511 URL 2>debug and attach the "debug" file which is produced.
Created attachment 523147 [details] Requested debugging output As far as I know there's no proxy, but I'm using the network at work so I'm not 100% sure how they have things configured. Here's the requested output. Doesn't look particularly illuminating to me but hopefully it contains some clues at least ...
If you run: $ openssl s_client -connect google-web-toolkit.googlecode.com:443 what happens?
It prints the following and then doesn't do anything else until I Ctrl-C it: CONNECTED(00000003) depth=2 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.googlecode.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googlecode.com i:/C=US/O=Google Inc/CN=Google Internet Authority 1 s:/C=US/O=Google Inc/CN=Google Internet Authority i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIID1DCCAz2gAwIBAgIKUanXYgADAAAudzANBgkqhkiG9w0BAQUFADBGMQswCQYD VQQGEwJVUzETMBEGA1UEChMKR29vZ2xlIEluYzEiMCAGA1UEAxMZR29vZ2xlIElu dGVybmV0IEF1dGhvcml0eTAeFw0xMTA4MTIwMzQ5MThaFw0xMjA4MTIwMzU5MTha MGoxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQHEw1N b3VudGFpbiBWaWV3MRMwEQYDVQQKEwpHb29nbGUgSW5jMRkwFwYDVQQDFBAqLmdv b2dsZWNvZGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4OYO+qUoG PoOmlsQ0S5SbBWwd7mGmLFXRufoP5SPLeZZQ/0e2Q7fn9GZ4V/j/L2KcbLvy5Y7q 2T1BjU+w9KLJk3ouCmVqUF2RN44MIYCJ5U5UkWEdDQozffSoPL2wo0yvB0w58s/O QExg/KvULsIKbbiP/9oWIwLEPjRsNBdEmQIDAQABo4IBozCCAZ8wHQYDVR0OBBYE FHIfE9+/4uebYqCJ3vaNrek6zMyyMB8GA1UdIwQYMBaAFL/AMOv1QxE+Z7qekfv8 atrjaxIkMFsGA1UdHwRUMFIwUKBOoEyGSmh0dHA6Ly93d3cuZ3N0YXRpYy5jb20v R29vZ2xlSW50ZXJuZXRBdXRob3JpdHkvR29vZ2xlSW50ZXJuZXRBdXRob3JpdHku Y3JsMGYGCCsGAQUFBwEBBFowWDBWBggrBgEFBQcwAoZKaHR0cDovL3d3dy5nc3Rh dGljLmNvbS9Hb29nbGVJbnRlcm5ldEF1dGhvcml0eS9Hb29nbGVJbnRlcm5ldEF1 dGhvcml0eS5jcnQwIQYJKwYBBAGCNxQCBBQeEgBXAGUAYgBTAGUAcgB2AGUAcjB1 BgNVHREEbjBsghAqLmdvb2dsZWNvZGUuY29tghIqLnUuZ29vZ2xlY29kZS5jb22C Dmdvb2dsZWNvZGUuY29tgg4qLmNvZGVzcG90LmNvbYISKi5nb29nbGVzb3VyY2Uu Y29tghBnb29nbGVzb3VyY2UuY29tMA0GCSqGSIb3DQEBBQUAA4GBAB1TAB/3YULF RTghkxQPfwPZ6i4xGZSTlOPr7lcK04E0xpDhDw5/hoTLSWv966ntAm+hemkk/p2q 1fe/EjbNEzoAxtdIEA/NThr6slJY0oOogLKN4bNlIXArUv5sPgfXST3tqCXTV9Ds MNCElda2aBBRerpz9AkbUpnPej7cIjPg -----END CERTIFICATE----- subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.googlecode.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority --- No client certificate CA names sent --- SSL handshake has read 1971 bytes and written 299 bytes --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : RC4-SHA Session-ID: ED610DD9DB1A3534DBA6B80E39143C9F1084C457484BAEBB2E8BBCA5AD532DF0 Session-ID-ctx: Master-Key: 2B9C9B989AABCFBDC11FD1FF1DFD7D64AAC4D3724AE50A5087FBB09DA9D46DE78F576BBF1AA2F02F36C1C247215B8620 Key-Arg : None Krb5 Principal: None PSK identity: None PSK identity hint: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - 98 ab cf d7 11 73 a0 b0-fe f1 00 90 ef ea 98 82 .....s.......... 0010 - 3f a7 31 86 fb 86 18 10-f7 43 f1 86 4e 50 b4 8f ?.1......C..NP.. 0020 - 51 79 a9 5d e5 cd 80 dc-0b 8d bf 81 ef f9 2e 43 Qy.]...........C 0030 - 23 34 fe 86 a3 14 52 5f-32 90 58 d1 d7 59 5f df #4....R_2.X..Y_. 0040 - 70 bf ad d7 98 dd 66 37-f1 6b 32 83 b8 c3 24 44 p.....f7.k2...$D 0050 - 39 f9 3b c0 8d ee 74 44-62 e4 a8 ea 9f 0c cd db 9.;...tDb....... 0060 - 7b 48 49 ad cf 9c b8 5c-da e1 32 a9 12 ab a1 46 {HI....\..2....F 0070 - cd 4d 84 0f 2f 86 16 c1-69 3e 72 09 c9 ca d6 f8 .M../...i>r..... 0080 - aa 8f c4 08 91 11 c4 e1-29 12 4f 80 5b de c5 f0 ........).O.[... 0090 - 04 72 1d 0c .r.. Start Time: 1316007540 Timeout : 300 (sec) Verify return code: 0 (ok) ---
Update: I'm working at home today, on my home broadband, and the above command is working fine. So it seems to be something in the configuration of the network at work ... I'll be back there tomorrow and can do some more testing then.
Sorry for the delay -- I'm back to trying to check out SVN things on the work network again, and I'm seeing exactly the same symptoms. It works on other networks, though -- how to find out what's going on at work?
Created attachment 527458 [details] Debugging output with http-proxy set in .subversion/servers Oops, here's the version without the actual URL and port ...
I marked the first attachment private on the assumption that you'd prefer that. I would guess the proxy is somehow intercepting the SSL connection even in pass-through mode.
Update: I just did "yum downgrade subversion subversion-libs subversion-javahl", which has given me subversion-1.6.16-1.fc15.x86_64 and friends. The same error persisted. :( Then I downloaded and rebuilt the subversion-1.6.15-1.fc14 SRPM from http://koji.fedoraproject.org/koji/buildinfo?buildID=212562 (wow, that took a while to build!!) Same error. :( But using subversion 1.6.15 on a different CentOS 5 box on the same network does work fine. Weird ... I've emailed the university IT support to ask what's up with the proxy
Based on the conversation in this ubuntu bug -- https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/294648 -- I tried rebuilding neon using openssl instead of gnutls, and svn now seems to work even from inside my work network. It's still only triggered by the local network at work, but at least I've now got a workaround ...
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping