Bug 227511

opensuse-updater just calls zypp-checkpatches, which links against libzypp whioch reads proxy information from /etc/proxy/sysconfig

It seems libzypp does not read the proxy authentication from there, but from HOME/.curlrc 

but according to YaST module, you can specify the proxy auth information there:

"f you are using a proxy server with authorization, enter Proxy User Name and Proxy Password. A valid username consists of printable ASCII characters (except for quotation marks) only."

/sbin/yast2 proxy writes the proxy host+port values (url's)
to /etc/sysconfig/proxy and the username and password to the
/root/.curlrc, e.g.:

proxy-user = "foo:bar"

libzypp reads both files, except somebody specified an proxy,
proxyuser, proxypass as url arguments, e.g.:

http://server/path?proxy=myproxy&proxyuser=foo&proxypass=bar

Note, that the /root/.curlrc has to be owned by root or zypp
will ignore it.

That's the problem - the password IS set in ~root/.curlrc but opensuse-updater (is that how the KDE icon / applet is called, isn't it?) runs with privileges of my normal user. Unfortunately in ~mludvig/.curlrc the password is not set. 

Now I anticipate arguments about security considerations ;-) Well, how about having a checkbox in the Yast proxy module saying something like "Disclose this username and password to users" (maybe "... in group wheel" or something). And then put it in /etc/curlrc?

Or at least make opensuse-updater complain loudly when the proxy asks for authorization but that can't be found in .curlrc and/or $http_proxy.

BTW It still doesn't work even after I put the credentials to ~/.curlrc and restarted opensuseupdater

mludvig@zofka:~> cat .curlrc
proxy-user = "webuser:webpass"
mludvig@zofka:~> ls -l .curlrc
-rw------- 1 mludvig users 31 2006-12-12 14:33 .curlrc

Comment #3 is incorrect.

Please forget about the applet. The applet is dumb. The real guilty here is a binary the applet launches.

This binary is run by the user, but the bnary has the suid bit on (+s).

I think the bug could be that, HOME is defined in this case as the user's home, but zypp still looks if the curl file is owned by root. I mean, this implies zypp is not taking the case where a user runs a suid program linked to it.

Michal, can you please chown /home/mludvig/.curlrc to root but give permissions to others to read?

I want:

mludvig@zofka:~> ls -l .curlrc
-rw-r--r-- 1 root users 31 2006-12-12 14:33 .curlrc

and see if it works.

HOME is not defined. The suid wrapper clears the environment.

That is the reason then. zypp is not finding curlrc at all. And even if HOME is not cleaned, the user's curlc is not owned by root as zypp checks first.

Which is the guilty component here?

W.r.t. comment #5 - chmod/chown as per your request didn't help.

I am having this exact same error with the zmd.  Could it be the same problem?

--
[~]$ wbinfo -u
DOMAIN\sjd

[~]# kinit -V sjd
Password for sjd@xyzproxy.full.domain-name.com: **********
Authenticated to Kerberos v5

--
[~]$ wbinfo -i DOMAIN\\sjd
DOMAIN\sjd:*:10000:10002:Sajid Ali:/home/DOMAIN/sjd:/bin/bash


[~]$ wbinfo --separator
\

[~]$ wbinfo --krb5auth=DOMAIN\\sjd%0password\)
plaintext kerberos password authentication for [DOMAIN\sjd%0password)] succeeded (requesting cctype: FILE)
credentials were put in: FILE:/tmp/krb5cc_10000
plaintext kerberos password authentication for [DOMAIN\sjd%0password\)] succeeded (requesting cctype: KCM)
no credentials cached
plaintext kerberos password authentication for [DOMAIN\sjd%0password)] succeeded (requesting cctype: KCM:0)
no credentials cached
plaintext kerberos password authentication for [DOMAIN\sjd%0password)] succeeded (requesting cctype: Garbage)
no credentials cached
plaintext kerberos password authentication for [DOMAIN\sjd%0password)] succeeded (requesting cctype: (null))
no credentials cached
plaintext kerberos password authentication for [DOMAIN\sjd%0password)] succeeded (requesting cctype: 0)
no credentials cached

--
[~]# ls -l /root/.curlrc
-rw-r--r-- 1 root root 82 May 16 22:05 /root/.curlrc

[~]# ls -l /home/DOMAIN/sjd/.curlrc
ls: cannot access /home/DOMAIN/sjd/.curlrc: No such file or directory

[~]# cp -vp /root/.curlrc /home/DOMAIN/sjd/
`/root/.curlrc' -> `/home/DOMAIN/sjd/.curlrc'

[~]# ls -l /home/DOMAIN/sjd/.curlrc
-rw-r--r-- 1 root root 82 May 16 22:05 /home/DOMAIN/sjd/.curlrc    <- -rw-r--r-- (readable by group|other)

--
[~]# cat /root/.curlrc

# Changed by YaST2 module proxy 05/16/2007    <- changed by YaST2, of course, as noted by YaST2
proxy-user = "DOMAIN\\sjd:0password\)"

--
[~]# cat /etc/sysconfig/proxy
PROXY_ENABLED="yes"

HTTP_PROXY="DOMAIN\\sjd:0password\)@xyzproxy.full.domain-name.com:8080"
HTTPS_PROXY="DOMAIN\\sjd:0password\)@xyzproxy.full.domain-name.com:8080"
FTP_PROXY="DOMAIN\\sjd:0password\)@xyzproxy.full.domain-name.com:8080"

GOPHER_PROXY=""
NO_PROXY="localhost, 127.0.0.1"

__note__:
  username: domain\sjd
  password: 0password)  <- yes, zero & right parenthesis are part of the password

--
[~]# cat /home/INT/sjd/.profile
http_proxy=DOMAIN\\sjd:0password\)@xyzproxy.full.domain-name.com:8080
ftp_proxy=DOMAIN\\sjd:0password\)@xyzproxy.full.domain-name.com:8080
https_proxy=DOMAIN\\sjd:0password\)@xyzproxy.full.domain-name.com:8080

--
[~]# env | grep proxy
http_proxy=http://xyzproxy.full.domain-name.com:8080
ftp_proxy=http://xyzproxy.full.domain-name.com:8080
https_proxy=http://xyzproxy.full.domain-name.com:8080
no_proxy=localhost, 127.0.0.1

-- Installation repos
[~]# zypper sl
# | Enabled | Refresh | Type | Name                                    | URI
--+---------+---------+------+-----------------------------------------+------------------------------------------------------------------
1 | Yes     | Yes     | YaST | 20070210-123801                         | ftp://mirrors.kernel.org/opensuse/distribution/10.2/repo/non-oss/
2 | Yes     | Yes     | YUM  | http://packman.unixheads.com/suse/10.2/ | http://packman.unixheads.com/suse/10.2/
3 | Yes     | Yes     | YaST | 20070210-123301                         | ftp://mirrors.kernel.org/opensuse/distribution/10.2/repo/oss

-- zypper list update fails
[~]# zypper lu
Restoring system sources...
Not found: Media Exception
Not found: Media Exception
Please insert media [Curl error for: ftp://mirrors.kernel.org/opensuse/distribution/10.2/repo/non-oss/media.1/directory.yast: Error code: HTTP response: 407 Error message: The requested URL returned error: 407
] # 1. Retry [y/n]:
n
Please insert media [Curl error for: http://packman.unixheads.com/suse/10.2/repodata/repomd.xml: Error code: HTTP response: 407 Error message: The requested URL returned error: 407
] # 1. Retry [y/n]:
n
I/O error: Can't provide /repodata/repomd.xml from http://packman.unixheads.com/suse/10.2/
(A)bort, (R)etry, (I)gnore?
a
I/O error: Can't provide /repodata/repomd.xml from http://packman.unixheads.com/suse/10.2/
Not found: Media Exception
Not found: Media Exception
Please insert media [Curl error for: ftp://mirrors.kernel.org/opensuse/distribution/10.2/repo/oss/media.1/directory.yast: Error code: HTTP response: 407 Error message: The requested URL returned error: 407
] # 1. Retry [y/n]:
n
Failed to restore sources

-- YaST Online update fails
[~]# you
URL: ftp://mirrors.kernel.org/opensuse/distribution/10.2/repo/non-oss/
Curl error for: ftp://mirrors.kernel.org/opensuse/distribution/10.2/repo/non-oss/media.1/directory.yast: Error code: HTTP response: 407 Error message: The requested URL returned error: 407 

URL: http://packman.unixheads.com/suse/10.2/
Curl error for: http://packman.unixheads.com/suse/10.2/repodata/repomd.xml: Error code: HTTP response: 407 Error message: The requested URL returned error: 407 
http://packman.unixheads.com/suse/10.2/
Can't provide /repodata/repomd.xml from http://packman.unixheads.com/suse/10.2/

URL: ftp://mirrors.kernel.org/opensuse/distribution/10.2/repo/oss
Curl error for: ftp://mirrors.kernel.org/opensuse/distribution/10.2/repo/oss/media.1/directory.yast: Error code: HTTP response: 407 Error message: The requested URL returned error: 407


Please help.

-- 
Sajid Ali

"Information is not knowledge." -Albert Einstein

Jano, this was fixed in 10.3 yes? Can be closed?

Is there some reason you can't fix this in 10.2?  There is no Novell client for 10.3, but there is for 10.2.

(In reply to comment #11 from Duncan Mac-Vicar Prett)
> Jano, this was fixed in 10.3 yes? Can be closed?

The only thing that has been changed in 10.3 in this regard is the incorrect parsing of .curlrc (so comment #10 should be fixed). The undefined HOME (due to the suid - comment #6) was probably not dealt with. What can we do about it?

I can replicate the same problem in openSUSE 10.3 GM (x86_64). Zypper (zypper ar) or adding software repositories under "Yast > Software Repositories" fails with a curl error 407. The problem is because curl doesn't read the proxy authentication information (username/password).

The problem is in the /root/.curlrc file. The autogenerated file contains:
---------------------------------------------
# Changed by YaST2 module proxy 09/19/07
--proxy-user "username:password"
--proxy "http://proxy.domain.com:8080"
---------------------------------------------

This file is missing the "=" (equal to) sign between the name and the value. I modified this file manually to:


---------------------------------------------
# Changed by YaST2 module proxy 09/19/07
--proxy-user = "username:password"
--proxy = "http://proxy.domain.com:8080"
---------------------------------------------

After adding the = sign in this file, it works fine. 

This is a show stopper bug. Until this is fixed, users behind a corporate firewall cannot update their opensuse 10.3 installation, making it unable to apply security updates. Hence, I mark this as high priority. 

Please update the Suse proxy configuration tool to generate the /root/.curlrc file correctly.

Finally a workaround!

Thanx! While it is unclear what's the correct .curlrc syntax, we will fix it in the YaST proxy module.

BTW, confirmed, any of the following is correct, -- and = are optional:

long-opt value
--long-opt value
long-opt = value
--long-opt = value

the correct way would be to fix it in libzypp, but let's use the '=' for now.

(In reply to comment #17 from Ján Kupec)
> BTW, confirmed, any of the following is correct, -- and = are optional:
> 
> long-opt value
> --long-opt value
> long-opt = value
> --long-opt = value
> 
> the correct way would be to fix it in libzypp, but let's use the '=' for now.
> 

Can you tell me where you found documentation for the .curlrc file syntax please? I searched the man pages for curl but I couldn't find the proper syntax.

I thought curl would just read this file and append it to the command line switches. In that case, are the = sign and the double quotes required? I think if the the value contains a whitespace, then it should be enclosed in single quotes? Can it be either single quotes or double quotes? 

Sorry for asking so many questions, I haven't used curl much, and the man pages do not provide these details.

(In reply to comment #18 from Senthil Nachimuthu)
> (In reply to comment #17 from Ján Kupec)
> > BTW, confirmed, any of the following is correct, -- and = are optional:
> > 
> > long-opt value
> > --long-opt value
> > long-opt = value
> > --long-opt = value
> 
> Can you tell me where you found documentation for the .curlrc file syntax
> please? I searched the man pages for curl but I couldn't find the proper
> syntax.

Unfortunately i've hit the same problem, the correct syntax is poorly documented in the man page and i did not find anything more on the web either. All i did was to experiment with it.

> I thought curl would just read this file and append it to the command line

Me too, but nope, it does not work like that, check for example the following:

this one works:
$ curl --max-filesize 2 http://asdf.comer
this one doesn't (but within .curlrc it is OK)
$ curl --max-filesize=2 http://asdf.comer
curl: option --max-filesize=2: is unknown

> switches. In that case, are the = sign and the double quotes required? I think
As i said above, the = sign is not required but permitted in the .curlrc file, but _not allowed_ on the command line.

> if the the value contains a whitespace, then it should be enclosed in single
> quotes? Can it be either single quotes or double quotes? 

Yes, both are OK, AFAIK

> Sorry for asking so many questions, I haven't used curl much, and the man
> pages do not provide these details.

true, we are left to experiments and source code reading :O( CCing our curl maintainer so that he can push the correction of the documentation upstream.

I added the = to the .curlrc in openSUSE and could not get opensuse-updater working.  Is there any way to get this working on 10.2?

(In reply to comment #20 from Andrew Pastuszak)
> I added the = to the .curlrc in openSUSE and could not get opensuse-updater
> working.  Is there any way to get this working on 10.2?

IIRC libzypp doesn't expect initial double dashes in the options in 10.2 (e.g. use 'proxyuser = ' instead of '--proxyuser = '). Also you can use the workaround where you pass the options in the URL.

I'll fix this in libzypp for 10.3, but with lower priority as there is a workaround for both 10.2 and 10.3.

The workaround does not work for me because our corporate proxy does not accept Basic authentification but only NTLM or Kerberos. Curl will not work untill i add "proxy-ntlm" or "proxy-anyauth" into /root/.curlrc but even with this modification, i can't get a working opensuse-updater.

(In reply to comment #23 from eric vialas)
> The workaround does not work for me because our corporate proxy does not accept
> Basic authentification but only NTLM or Kerberos. Curl will not work untill i
> add "proxy-ntlm" or "proxy-anyauth" into /root/.curlrc but even with this
> modification, i can't get a working opensuse-updater.

Hi Eric! This is somehting different. So far, libzypp does not support authentication methods other than basic and digest. Although curl supports it, we need to make libzypp able to pass necessary authentication data for these types of authentication to curl. For this case i suggest you to file a new enhancement request bug for component 'libzypp' and assign it directly to me. Thanx!

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

Ok, I have a new OpenSUSE box fully patched, and now the updater in Yast works like a charm through an authenticated proxy, but the Gnome panel icon doesn't work at all.  Anything I can do to help troubleshoot this?

The last updates for "zypper" and "libzypp" were July 4, bringing "zypper" up to "zypper-0.8.23-7.x86_64.rpm".  I have been using it lately and the panel icon seems to be working.  I am thinking about asking for a change, but that would be an enhancement in another "bug report".  Is there any reason not to close this one?

(In reply to comment #27 from Jim Omura)
> The last updates for "zypper" and "libzypp" were July 4, bringing "zypper" up
> to "zypper-0.8.23-7.x86_64.rpm".  I have been using it lately and the panel
> icon seems to be working.

Are you behind a proxy that requires authentication?

> I am thinking about asking for a change, but that
> would be an enhancement in another "bug report".  Is there any reason not to
> close this one?

Do you mean this "copy to new" button? Yes, you can do that (i hope it does not copy all the comments :O). In any case, it should be a NEW bug report.

(In reply to comment #28 from Jan Kupec)
> (In reply to comment #27 from Jim Omura)
> > The last updates for "zypper" and "libzypp" were July 4, bringing "zypper" up
> > to "zypper-0.8.23-7.x86_64.rpm".  I have been using it lately and the panel
> > icon seems to be working.
> 
> Are you behind a proxy that requires authentication?

No, but back at the end of October you recommended that a new "report" be opened requesting an enhancement.  So at that point I was wondering if it had been done.  Since another report could have been opened and closed without affecting this one.

So the only outstanding problem I could see when reading through all this was the last problem where the icon applet was "not working at all", and since mine seems to be working fine, that raised the question whether this bug should be closed.

> > I am thinking about asking for a change, but that
> > would be an enhancement in another "bug report".  Is there any reason not to
> > close this one?

> Do you mean this "copy to new" button? Yes, you can do that (i hope it does not
> copy all the comments :O). In any case, it should be a NEW bug report.

No, actually, I was thinking about asking for more options beyond checking "every day" and "every other day."  I am currently using this on a laptop and it just wastes my online time because there is no way I am going to update while I am on a v.90 connection.  Do you guys ever remember how slow this can be? :-)
However, I think the better idea would be for me to uninstall the icon applet, if I can do that without affecting the regular "online update" in Yast2.  So I might not bother asking for any changes.

Information was provided by NEEDINFO was not removed.

(In reply to comment #29)
> (In reply to comment #28 from Jan Kupec)
> > (In reply to comment #27 from Jim Omura)
> > Are you behind a proxy that requires authentication?
> 
> No,

> So the only outstanding problem I could see when reading through all this
> was the last problem where the icon applet was "not working at all",
> and since mine seems to be working fine, that raised the question whether
> this bug should be closed.

No. Your updater was working because you were not behind a proxy with authentication. Andrew says in c#26 that the updater applet does not work in such case.

> No, actually, I was thinking about asking for more options beyond checking
> "every day" and "every other day."  I am currently using this on a laptop and
> it just wastes my online time because there is no way I am going to update
> while I am on a v.90 connection.  Do you guys ever remember how slow this can
> be? :-)

Yeah, you're right.

> However, I think the better idea would be for me to uninstall the icon applet,
> if I can do that without affecting the regular "online update" in Yast2.  So I
> might not bother asking for any changes.

I would do that, too. Uninstalling the applet won't affect yast or zypper in any way, no need to be afraid.

This bug is pretty old and the updater applet is not using zypper as backend by default anymore since openSUSE 11.1 (or even 11.0, i can recall exactly), so I'm going to close the bug now. Those affected by this bug, please use YaST Online Update, or 'zypper up' to update your systems.

(In reply to comment #32)
> Those affected by this bug, please use YaST
> Online Update, or 'zypper up' to update your systems.

I'd also advise upgrading to a more recent openSUSE, of course, openSUSE 11.1 rocks! But i'm afraid the PackageKit backend there has a similar problem with the $HOME env. variable, see bug 487092 c#18.