Bug 227513

Please attach your yast log files.
http://en.opensuse.org/Bugs/YaST

Thank you.

How about trying it yourself instead of asking for needless yast logs, hm? It's perfectly reproducible and not difficult at all to verify ;-)

You don't even need a proxy that requires authorization, all you have to do is to check the env variable after setting the proxy in YaST (and obviously logout && login again). 

Anyway, it appears that login/password is not available to ordinary users as yet therefore making this bug a dependency to bug #227511

Actually it isn't a dependency because $http_proxy doesn't carry the login and password for root either. 

I suggest for /etc/profile.d/profile.sh around line 47 and below to check ~/.curlrc to see if there is a password available and pass it to $http_proxy if it was. That way even programs like wget that are not based on curl will have enough information to reach the net.

-> 10.3

Created attachment 162256 [details]
y2logs. yast2 proxy screenshot, /etc/sysconfig/proxy file

This bug appears to have crept back in to beta3 - beta2 seemed to work fine.

To reiterate - using Yast2 to set the proxy settings does *not* save/set the username and password in /etc/sysconfig/proxy. This causes things like zypper to fail on authentication.

If I manually set the HTTP_PROXY variable (adding the user/password) then all is well.

I have attached my y2 logs, a screen shot, and the resultant /etc/sysconfig/proxy file.

Steve, proxy username and password were never stored in /etc/sysconfig/proxy file. Instead, they were written into /root/.curlrc file, but with incorrect syntax, so I don't quite understand how it could possibly work in beta2 :) 

This incorrect .curlrc issue should be now fixed (bug #305163), but I don't know if zypper checks this file for user/password. Jano, can you comment?

But please note that this bug is about something different - about user and password being stored in root's $HOME only and not being accessible to normal users.

(In reply to comment #7 from Katarina Machalkova)
> This incorrect .curlrc issue should be now fixed (bug #305163), but I don't
> know if zypper checks this file for user/password. Jano, can you comment?

Yes, zypper (libzypp) reads it from $HOME/.curlrc. You can also specify it in the repository URL using URL parameters "proxyuser" and "proxypassword" (this actually takes preference over reading .curlrc).

I've open a new bug #309139, as per comment #6, because changing .curlrc syntax to a valid one (bug #305163) invalidated the way how libzypp parses its data

RC1 is showing new problems related to zypper proxy authentication. The .curlrc file has the correct format, and curl itself works with no problems (also, the proxy environment variables are set correctly).

Unfortunately, zypper now refuses to authenticate with the proxy. We have a workaround - we have set up Squid so that squid does the authentication with the external proxy. We then set the local proxy settings to point at Squid with no authentication required. This allows zypper to work correctly.

I have attached a tarball containing:

* screenshot of yast failing to add external repository + curl managing to download
* All the Yast logs
* zypper logs while failing to add repository
* my .curlrc (which is correct)
* tcpdump log of zypper attempting to authenticate

From everything I've seen, it looks to me like zypper attempts to get the xml file via the proxy; the proxy requests authentication; zypper gives up (i.e. does not send proxy authentication response) thinking it's got a permanent error (?)

Created attachment 173805 [details]
zypper logs - fails to authenticate with proxy

Please refer to bug #309139 for any issue related to libzypp/zypper that has something to do with proxy authentication. 

Christian, can new variables be added to /etc/sysconfig/proxy, e.g. PROXY_USER, PROXY_PASSWORD ? (of course, some md5 hash of the password). So that these can be later exported into environment and made accessible to all programs, not just curl (as they are now).

Oh, i don't mind, but /etc/sysconfig/proxy is not in my working scope.

This file (or better the template /var/adm/fillup-templates/sysconfig.proxy) comes from package aaa_base and the maintainer is Rudi. Maybe also ask the maintainers of proxies.

What info is Rudi supposed to provide?

well, the bug should be assigned to me and needinfo maintainer(squid) ...

my fault, brain twisted ...

adding variables to /etc/sysconfig/proxy can only help if someone
uses them.

HTTPS_PROXY/FTP_PROXY are used by more applications, curl is just one
of them.

But I don't know of any application that would read USER/PASSWD from the
environment, so an addition like this would only make sense if anyone
was willing to add patches to at least the most common tools and browsers
(mozilla,w3m,wget,curl,...)

wget certainly accepts http_proxy env. variable in the form http://user:password@proxy.somewhere.net:3128 

But that's the only app I know of (which does not mean that other apps do not support username and password in $http_proxy). Maybe the original requester could give us more information ;-)

what is the current status ?

Overlooked this one, I'm sorry.

> But I don't know of any application that would read USER/PASSWD from the
> environment, so an addition like this would only make sense if anyone
> was willing to add patches to at least the most common tools and browsers
> (mozilla,w3m,wget,curl,...)

Here are some apps that are able to read $http_proxy env. variable with user & password:

* wget, lynx, (e)links, Konqueror
* Firefox - but only after installing an extension: 
https://addons.mozilla.org/cs/firefox/addon/3896 

As for the other apps, it is more easy to find out what does not work with $http_proxy with user/passwd (mplayer, git,...) than something that does :( 

Certainly YaST and libzypp (which is curl-based) ignore $http_proxy and read sysconfig and .curlrc directly.

Maybe it makes sense to file a feature request. There already is one $http_proxy-related (FaTE #302377)

okay, closing here, rest in fate.

*** Bug 523922 has been marked as a duplicate of this bug. ***

*** Bug 628310 has been marked as a duplicate of this bug. ***