Bug 150768

Summary: curl-7.12.3-2 breaks basic authentication
Product: [Fedora] Fedora Reporter: Fred New <fred.new2911>
Component: curlAssignee: Ivana Varekova <varekova>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
URL: http://transition.progeny.com/private/updates
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-05-03 11:36:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Trace file using curl-7.13.1-1
none
Trace file using curl-7.12.1-1, the older, working version
none
The STDERR messages that go with the first trace (curl-7.13.1-1).
none
Trace for curl-7.13.1-1 using -k
none
STDERR for curl-7.13.1-1 using -k
none
STDOUT for curl-7.13.1-1 using -k
none
proposed patch to fix this problem, generated against a 7.14.0 dev version but should apply fine on recent versions none

Description Fred New 2005-03-10 13:05:08 UTC
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:

Comment 1 Ivana Varekova 2005-04-22 08:30:20 UTC
Hello,
can you test the latest curl version (7.13.1-1) please. 
Affects this bugthe latest version too? 
Thank you. 
Ivana Varekova


Comment 2 Fred New 2005-04-22 18:16:53 UTC
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.

Comment 3 Daniel Stenberg 2005-04-23 21:54:43 UTC
Can you use --trace-ascii and attach the output here? Just remember to edit out
any sensitive data before you do.


Comment 4 Fred New 2005-04-24 13:14:17 UTC
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

Comment 5 Fred New 2005-04-24 13:16:56 UTC
Created attachment 113598 [details]
Trace file using curl-7.12.1-1, the older, working version

Comment 6 Daniel Stenberg 2005-04-24 22:00:41 UTC
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.

Comment 7 Fred New 2005-04-25 05:22:04 UTC
Created attachment 113622 [details]
The STDERR messages that go with the first trace (curl-7.13.1-1).

Comment 8 Fred New 2005-04-25 05:23:29 UTC
Created attachment 113623 [details]
Trace for curl-7.13.1-1 using -k

Comment 9 Fred New 2005-04-25 05:24:51 UTC
Created attachment 113624 [details]
STDERR for curl-7.13.1-1 using -k

Comment 10 Fred New 2005-04-25 05:25:43 UTC
Created attachment 113625 [details]
STDOUT for curl-7.13.1-1 using -k

Comment 11 Daniel Stenberg 2005-04-25 21:34:36 UTC
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.

Comment 12 Fred New 2005-04-26 10:38:05 UTC
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.

Comment 13 Daniel Stenberg 2005-04-26 11:41:49 UTC
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.

Comment 14 Ivana Varekova 2005-04-27 10:22:10 UTC
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

Comment 15 Ivana Varekova 2005-05-03 11:36:46 UTC
This ptoblem is fixed in 7.13.1-3.
Thank you very much.
Ivana Varekova

Comment 16 Daniel Stenberg 2005-05-04 13:51:55 UTC
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...