Bug 140723 - support for authenticated proxies has regressed
Summary: support for authenticated proxies has regressed
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: python   
(Show other bugs)
Version: 3
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Mihai Ibanescu
QA Contact: Brock Organ
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-24 14:48 UTC by Daniel Thompson
Modified: 2014-01-21 22:50 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-11 19:26:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Low quality band-aid patch to alleviate the problem (602 bytes, patch)
2004-11-24 14:51 UTC, Daniel Thompson
no flags Details | Diff
Remove a spurious newline from the authentication header (530 bytes, patch)
2005-09-07 08:57 UTC, Daniel Thompson
no flags Details | Diff

Description Daniel Thompson 2004-11-24 14:48:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
I am unable to use yum with an authenticated proxy. This is a
regression from FC2. yum fails to download correctly formed URLs.

Version-Release number of selected component (if applicable):
yum-2.1.11-3

How reproducible:
Always

Steps to Reproduce:
export http_proxy="http://user name:password@proxy.example.com:8080"
yum upgrade
<watch packet trace with a sniffer>

Actual Results:  Looking at the packet sniffer output it is obvious
what is wrong.

GET
http://fr2.rpmfind.net/linux/fedora/core/updates/3/i386/repodata/repomd.xml
HTTP/1.1
Host: fr2.rpmfind.net
Accept-Encoding: identity
Proxy-authorization: Basic MIND_YOUR_OWN_BUSINESS

User-agent: urlgrabber/2.9.0

The new line beween Proxy-authorization and User-agent causes the
proxy server to consider this two requests. It correctly satifies the
first but reports an error for the second. yum does the following:

 - reads the first reply from the handle
 - issues another request
 - reads the error from the handle
 - bombs out

Additional info:

This is probably a python bug but yum was the tools that revealed it
to me. I have worked around this problem by altering yum see attached
patch. Although this solves the problem at hand this is a hack.

Comment 1 Daniel Thompson 2004-11-24 14:51:49 UTC
Created attachment 107390 [details]
Low quality band-aid patch to alleviate the problem

As already stated this avoids the problem rather then treating the cause.

Comment 2 Seth Vidal 2005-01-21 02:50:39 UTC
If you get a chance-  could you pull down yum from cvs and see if it
helps out the problem you're having?
Thanks.


Comment 3 Daniel Thompson 2005-01-31 11:09:59 UTC
Sorry for the delay in replying.

I've just downloaded a tarball from YUM viewcvs stuff (cannot use CVS
directly from this machine).

This did not work on FC3. Looking at the packet trace the problem of
the extra new line is still apparant.



Comment 4 Daniel Thompson 2005-09-07 08:57:26 UTC
Created attachment 118543 [details]
Remove a spurious newline from the authentication header

I finally got so fed up patching yum everytime it was updated I decided to find

the 'proper' fix for this problem.

It turns out to be a problem in Python's urllib2 library. The base64
encoder library included a newline on the end of the encoded string and this
was incorrectly being added to the header. A simple .rstrip() removed the
trailing whitespace and this fixes the broken header.

This non-hacky fix should be applied to Python.

Comment 5 Mihai Ibanescu 2005-11-30 22:48:57 UTC
Well, the even better fix would be to strip all newline characters in the string.
encodestring has the bad habit of adding new lines every 80 chars (I believe).
If  the combination (username:password) happens to be longer than 58 chars,
we're back to a similar problem.

Comment 6 Matthew Miller 2006-07-10 23:27:46 UTC
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!


Comment 7 Daniel Thompson 2006-07-11 19:26:24 UTC
I believe this issue is fixed in recent Fedora Cores (and is certainly not a
security issue).

Comment 8 Matthew Miller 2006-07-11 19:28:42 UTC
Thanks!


Note You need to log in before you can comment on or make changes to this bug.