update-manager doesn't report authentication failure

[Eliah Kagan]

Binary package hint: update-manager

In the Update Manager (update-manager package version 1:0.142.22 on Maverick amd64), clicking the "Settings..." button raises a gksu dialog if authentication is needed. But if the wrong password is entered, no error is reported, and no action is taken. If the user does not realize that s/he entered the wrong password, the user would likely assume that some other unknown problem was preventing the Software Sources window from coming up.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: update-manager 1:0.142.22
ProcVersionSignature: Ubuntu 2.6.35-24.42-generic 2.6.35.8
Uname: Linux 2.6.35-24-generic x86_64
Architecture: amd64
Date: Sun Dec 12 02:30:50 2010
ExecutablePath: /usr/bin/update-manager
InstallationMedia: Xubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100406)
InterpreterPath: /usr/bin/python2.6
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US.utf8
 LANG=en_US.utf8
 LC_MESSAGES=en_US.utf8
 SHELL=/bin/bash
SourcePackage: update-manager

[Eliah Kagan (degeneracypressure)]

I have just tried to reproduce this bug on a Maverick i386 system, and was unable to do so. While I suppose it's possible that this occurs only on amd64, it seems more likely that there's some other important factor. Both systems do have the same package versions for update-manager, as well as for gksu (package version 2.0.2-2ubuntu3).

[Charlie Kravetz (cjkgeek)]

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here.

I can confirm this issue using Xubuntu Natty 64bit. When Settings is clicked and the password entered wrong, it fails silently back to update-manager. There is no indication that the attempt was even made to enter Settings.

Thanks for taking the time to make Ubuntu better!

[Robert Roth (evfool)]

I have reproduced this on Maverick, with i386, with update-manager 0.142.23, thus I am removing the amd64 tag.

[Eliah Kagan (degeneracypressure)]

@Robert
Shouldn't this be tagged with *both* amd64 and i386 now, rather than neither?

[Robert Roth (evfool)]

I don't know what's the right thing to do, but as far as I understood, tags are for restricting the environment in which a bug occurs. I have checked the code, and this is not fixed, so it does occur on every possible architecture - so if we want to add architecture tags, we should add all of those (i386, amd64, armel, etc...). So my opinion is that there should be no architecture tag on this bug. Please also note that the most general bugs are reported without any tags (those reported by users generally), apport adds the architecture tag, as it might be useful in some cases, but as this bug seems to be architecture-independent, it's not relevant. Please correct me if I'm wrong.

[Eliah Kagan (degeneracypressure)]

That reasoning makes good sense to me; I have no objection to it. (In any case, your accompanying comment clarifies the meaning of this bug's architecture-tagless state, so while some bugs are reported without tags because the original reporters--typically not using apport--didn't supply architecture information, I doubt this bug would be assumed to be in that situation.)

[Robert Roth (evfool)]

This seems to be related to bug #604197. The best would be to fix this in gksu, to show the gksu window until the password is either correct or the dialog is cancelled.

[Robert Roth (evfool)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported and is a duplicate of bug #773284, so it is being marked as such. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.