Bug 107983 - up2date says many packages have no GPG signature
Summary: up2date says many packages have no GPG signature
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: up2date   
(Show other bugs)
Version: beta1
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Fanny Augustin
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-10-25 16:43 UTC by Ted Kaczmarek
Modified: 2007-04-18 16:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-11-04 20:19:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Ted Kaczmarek 2003-10-25 16:43:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Epiphany/1.0.4

Description of problem:
Was not sure how to file this one, but since it happened when running up2date
:-). This box is a fedora 0.95 subsribed to rawhide. Their are many packages
that up2date says many packages have no GPG signature.
Too many to list ;-)

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

How reproducible:
Always

Steps to Reproduce:
1.Start up2date on Fedora 0.95
2. up2date says packaged not signed with GPG
3.
    

Actual Results:  up2date says packaged not signed with GPG

Expected Results:  packages should be signed with GPG key

Additional info:

IP of server was 66.187.232.30. Reverse record shows as ftp.redhat.com.

Comment 1 Jeremy Portzer 2003-10-29 16:36:51 UTC
According to traffic on fedora-test-list, many rawhide packages don't have a
signature.  This is the state of things -- GPG signatures are added manually,
but the rawhide push process is semi-automatic.  Not sure if this should be a
big deal or not.

Suggest this be closed as NOTABUG.

Comment 2 Ted Kaczmarek 2003-10-29 18:50:42 UTC
[root@cr1itl130 root]# up2date --nosig
Traceback (most recent call last):
  File "/usr/share/rhn/up2date_client/gui.py", line 2070, in doInstallation
    kernelsToInstall = up2date.installPackages(self.selectedPkgList,
self.rpmCallback)
  File "/usr/share/rhn/up2date_client/up2date.py", line 604, in installPackages
    hdr = getRealHeader(pkg)
  File "/usr/share/rhn/up2date_client/up2date.py", line 173, in getRealHeader
    hdr = _ts.hdrFromFdno(fd)
rpm.error: public key not trusted
up2date-4.1.12-1
rpm-4.2.1-0.30

Should I open a new one about this? It is in the neighborhood.


 


Comment 3 Ted Kaczmarek 2003-10-29 19:54:13 UTC
rw-rw-r--    1 root     root         5896 Oct 29 14:52
anaconda-help-9.2-1.noarch.rpm
-rw-rw-r--    1 root     root         5896 Oct 29 14:52
redhat-config-network-1.3.10-1.noarch.rpm
-rw-rw-r--    1 root     root         5896 Oct 29 14:52
redhat-config-network-tui-1.3.10-1.noarch.rpm

I guess the rpms with 5896 bytes size are the bad ones :-)

Comment 4 Ted Kaczmarek 2003-10-30 02:11:43 UTC
kickstart.linux.ncsu.edu looks good, but yum channel rawhide from 
http://ftp.redhat.com/pub/redhat/linux/rawhide/ is bad.

Comment 5 Don Himelrick 2003-10-30 02:56:04 UTC
I take it back, I couldn NOT install the redhat-config-network (and tui) noarch
rpms.  This is what I get:

# rpm -Uvh --nosignature redhat-config-network-1.3.10-1.noarch.rpm
error: open of <!DOCTYPE failed: No such file or directory
error: open of HTML failed: No such file or directory
error: open of PUBLIC failed: No such file or directory

Comment 6 Don Himelrick 2003-10-30 02:57:01 UTC
oops, wrong bug, disregard if you want :)

Comment 7 Ted Kaczmarek 2003-10-30 16:05:18 UTC
And the packages of the day for 10/30/03 are
indexhtml-1-1.noarch.rpm
anaconda-images-9.2-3.noarch.rpm

Hmm, maybe md5sum on the rpms after putting them on the server would be a good
idea :-)

Comment 8 Adrian Likins 2003-11-04 20:19:08 UTC
server should be fixed now. 

I hope.

And current clients should be somewhat more robust in face
of this (though, they still basically just stop, since the
info they need isnt there, but they stop nicely)


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