Red Hat Bugzilla – Bug 681132
Add/Remove Software crashes on Startup (SSL cert. verify fails in RHN)
Last modified: 2014-10-06 09:46:19 EDT
Created attachment 481550 [details] Crash Dump Description of problem: Add/Remove Software crashes on Startup Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Start Add/Remove Software
File "/usr/share/rhn/up2date_client/up2dateAuth.py", line 186, in login li = server.up2date.login(systemId) File "/usr/share/rhn/up2date_client/rhnserver.py", line 64, in __call__ raise up2dateErrors.SSLCertificateVerifyFailedError() SSLCertificateVerifyFailedError: The SSL certificate failed verification.
Well, the cause of this is that you have bad SSL certificate to access to rhn.redhat.com or you RHN Satellite. There is nothing we can do that about that. Reporter should use correct certificate. I will ignore this part. What we can fix is that Traceback. And it should be part of GUI/CLI tool using this plugin to catch this exception and provid nice error message - or in case of pirut - to provide nice error window. Presumable with some Cancel/Try Again. James, do you agree, that pirut should catch this exception? If yes, can you take this BZ back. Otherwise I'm going to close it as there is nothing I can fix in plugin.
Changing the GUI significantly at this point is ... unlikely. In general we don't want to be catching 666 random exceptions within the core, so we'd "expect" that the rhn plugin would catch the exception and rethrow as RepoError/NoMoreMirrorsRepoError/RepoMDError or even PluginYumExit (I'm not sure what pirut does with the later though).
*** Bug 684340 has been marked as a duplicate of this bug. ***
*** Bug 691552 has been marked as a duplicate of this bug. ***
*** Bug 691556 has been marked as a duplicate of this bug. ***
Fixed in upstream https://bugzilla.redhat.com/show_bug.cgi?id=691188#c6
Thanks, it seems to be working now.
Backported change from spacewalk master as ------------------------------------------------------------------------ r207195 | mmraka | 2011-10-06 13:24:17 +0200 (Thu, 06 Oct 2011) | 5 lines 681132 - inherit SSLCertificateVerifyFailedError from RepoError backported from 3ef12a289c1f1341144caf2af1d2595cd1500a66 691188 - inherit SSLCertificateVerifyFailedError from RepoError ------------------------------------------------------------------------
The first part of this problem is already fixed in rhn-client-tools (now up2dataErrors.SSLCertificateVerifyFailedError inherits from RepoError), but there is still problem in pirut, which still handles this exception incorrectly. I created a new Bug #771385. Reproducer: 1. register to Satellite 2. change SSLCert in /etc/sysconfig/rhn/up2date to some existing and valid (but for another different Satellite) cert 3. run `yum check-update` - readable error message is shown (not traceback) 4. run `pirut` - 'Exception Occured' window with traceback + traceback in terminal is shown Switching to VERIFIED (from the satellite devel/qa point of view).
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Originally in the times of up2date, when no yum exist at all, we had our own set of classes which represent different errors. And we feel no shame to print traceback when such error was raised. Consequence: But as Linux matured (and yum raised) we have to be friendly to users. And yum expected that all errors which happen due some problem with repo, will be instance of yum.RepoError. But our old code did not know that and nobody fixed that. Fix: I came and made error SSLCertificateVerifyFailedError a child of yum.RepoError. Result: As result, whenever some error with repository occure - Yum (or Pup) will be meet with error which has known ancestors and instead of printing unfriendly traceback, these programs can print nice error message or even present dialog window. This will significantly lower confuse level of our users.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0250.html