From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1 Description of problem: With curl-7.12.1-1, I could use .netrc to supply a user name and password for the above URL. With curl-7.12.3-2 this no longer works. The above site has some sort of re-directed authentication - .netrc needs to contain the same user name and password for www.progeny.com and netid.progeny.com, but not transition.progeny.com. I have tried to duplicate this problem with my own authenticated directory using httpd on FC3, and the new curl is able to access it. Version-Release number of selected component (if applicable): curl-7.12.3-2 How reproducible: Always Steps to Reproduce: 1. Install curl-7.12.3-2 2. Set up .netrc with a valid ID and password for www.progeny.com and netid.progeny.com. (I don't know how you are supposed to duplicate this. I asked support at this site if they had some way of testing this. They said no.) 3. rm -f $HOME/tmp/progeny.cookie 4. curl -D $HOME/tmp/progeny.cookie -b $HOME/tmp/progeny.cookie -nL0 \ http://transition.progeny.com/private/updates/ > bad-msgs Actual Results: [fred@ruuttest tmp]$ rm -f $HOME/tmp/progeny.cookie [fred@ruuttest tmp]$ curl -D $HOME/tmp/progeny.cookie -b $HOME/tmp/progeny.cookie -nL0 \ http://transition.progeny.com/private/updates/ > bad-msgs % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 397 0 397 0 0 270 0 --:--:-- 0:00:01 --:--:-- 0 [fred@ruuttest tmp]$ cat bad-msgs <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>401 Authorization Required</TITLE> </HEAD><BODY> <H1>Authorization Required</H1> This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.<P> </BODY></HTML> [fred@ruuttest tmp]$ Expected Results: With curl-7.12.1-1 I get the following: [fred@ruuttest tmp]$ rm -f $HOME/tmp/progeny.cookie [fred@ruuttest tmp]$ curl -D $HOME/tmp/progeny.cookie -b $HOME/tmp/progeny.cookie -nL0 \ http://transition.progeny.com/private/updates/ > good-msgs % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 1351 0 1351 0 0 3318 0 --:--:-- --:--:-- --:--:-- 450 [fred@ruuttest tmp]$ and good-msgs contains the HTTP-server-built index.html of the requested directory. Additional info:
Hello, can you test the latest curl version (7.13.1-1) please. Affects this bugthe latest version too? Thank you. Ivana Varekova
Authentication is still broken with curl-7.13.1-1. I tested this from an FC4T2 system at home. My home network is behind a NAT firewall, so I also confirmed that curl-7.12.1-1 works as desired on a Fedora Core 3 system on the same home network.
Can you use --trace-ascii and attach the output here? Just remember to edit out any sensitive data before you do.
Created attachment 113597 [details] Trace file using curl-7.13.1-1 The attached was created with curl --trace-ascii curl-trace \ -D $HOME/tmp/progeny.cookie -b $HOME/tmp/progeny.cookie \ -nL0 http://transition.progeny.com/private/updates/ >curl-stdout 2>curl-stderr
Created attachment 113598 [details] Trace file using curl-7.12.1-1, the older, working version
Thanks for the fine traces. This problem is clearly not at all related to Basic authentication. In the failing case, you can see in the log that the CA cert bundle was not found (or couldn't be read) properly and thus I believe it couldn't verify the server. If you show us your return code/error message it could reveal that. For testing purposes, you could rerun with -k (--insecure) which disables the verification of the server's certificate.
Created attachment 113622 [details] The STDERR messages that go with the first trace (curl-7.13.1-1).
Created attachment 113623 [details] Trace for curl-7.13.1-1 using -k
Created attachment 113624 [details] STDERR for curl-7.13.1-1 using -k
Created attachment 113625 [details] STDOUT for curl-7.13.1-1 using -k
Created attachment 113652 [details] proposed patch to fix this problem, generated against a 7.14.0 dev version but should apply fine on recent versions This bug occurs because libcurl takes measures in order to prevent leaking the password to other hosts than the original one you pass the auth to. It didn't however properly acknowledge that the netrc file kind of permits it this way as used in this bug report.
The above patch worked for me after combining it with curl-7.12.3-3.fc3.src.rpm and rebuilding the RPM. I can't say whether the patch introduces any new problems.
All existing curl test cases (and my new one that tests for this flaw) all run fine. That's not a guarantee everything is fine, but it hints that nothing major breaks. This fix will be included in the upcoming (upstream) curl 7.14.0 release. Thanks for the excellent details.
Thanks Fred for bug report and information and thanks Daniel for his solvation and patch. I will apply this patch to the last fc4 curl version. Ivana Varekova
This ptoblem is fixed in 7.13.1-3. Thank you very much. Ivana Varekova
Sorry for asking a stupid question here, but is there a URL somewhere I can browse to see what (other) changes you've put into your curl 7.13.1 releases? I spend a large amount of time on support issues, and many users use these packages. It would help me to know what particular changes your version of the releases contain...