Bug 52192 - up2date fails because packages are not pgp signed
Summary: up2date fails because packages are not pgp signed
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: up2date   
(Show other bugs)
Version: roswell
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-21 16:19 UTC by Need Real Name
Modified: 2015-01-07 23:50 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-22 04:27:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Need Real Name 2001-08-21 16:19:15 UTC
Description of Problem:

up2date failes to install any updates because packages on the beta rhn
server dont seem to be pgp signed.

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


Steps to Reproduce:
1. run up2date
2. choose update to install

Actual Results:
updates are not installed

Expected Results:
updates should be installed

Additional Information:

Comment 1 Need Real Name 2001-08-21 16:24:24 UTC
Note that up2date actually lets you install packages without gpg signatures, but
this results in errors.

Comment 2 Christopher McCrory 2001-08-21 17:36:38 UTC
change /etc/sysconfig/rhn/up2date 
to not use GPG

up2date:useGPG[comment]=Use GPG to verify package integrity

Comment 3 Jay Turner 2001-08-21 19:15:52 UTC
This is not a bug.  In the case that the user has the option set to check for
GPG signature, then up2date is not supposed to install packages which are not
GPG signed.  If you want to get around this on the commandline, then add
"--nosig"  In the GUI, the user is prompted that the package is not signed and
then given the opportunity to install the package anyway.

Comment 4 Need Real Name 2001-08-21 19:51:52 UTC
So, are the updates gpg signed?

I used up2date from the original roswell cds to update the up2date and
up2date-gnome packages. I installed them even though a gpg signature was not
found. The new up2date however was broken and refused to start.

Comment 5 Mihai Ibanescu 2001-08-21 20:11:19 UTC
For which values of 'broken'? :-)
Could you please provide us with more details?
To answer your question, the beta packages are not GPG signed, that's why you
have to either use --nosig on the command line, or to edit

Comment 6 Need Real Name 2001-08-22 04:27:20 UTC
I tried to recreate what happened by reverting to the old up2date and installing
the new one through it. This time it worked without the old "brokenness".
Later I realized that a new version of roswell had been released. I would
attribute the behaviour I saw to corrupted rpm packages caused by large numbers
of people hitting the up2date server simultaneously. (I verified this, many of
the packages downloaded by up2date dont seem pass the md5sum test with rpm -K.(
But, why would up2date install those packages?!)). The situation would probably
improve in a couple of days, again, this looks like a red-herring.

Comment 7 Jay Turner 2001-08-22 13:32:42 UTC
Closing this issue out again.  Will reopen is we start to see issues again.

Comment 8 Adrian Likins 2001-08-22 19:31:44 UTC
Hmm. The server delivering lots of corrupt rpms seems like a real problem
to me though. 

However, the client is supposed to verirfying the package md5sums before
it ever attempts to install them, so if this isnt the case thats another
bug. But both of those should probable get a new bui id. If you've got
more details about these cases, mind opening bug reports for them?

Comment 9 Mihai Ibanescu 2001-08-22 19:52:10 UTC
bharath, do you still experience corrupted RPM packages? If so, please file a
different bugzilla cause this one is really about GPG sigs and not about md5sums.

Comment 10 Need Real Name 2001-08-22 20:34:59 UTC
Please see Bug 52329.

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