I am seeing something similar via the GUI (with 4.1.12-1)
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

But rerunning up2date sometimes works.

whats 

rpm -q gpg-pubkey

is the gui up2date  problem also with --nosig?

I have
rpm -q gpg-pubkey
gpg-pubkey-897da07a-3c979a7f
gpg-pubkey-e418e3aa-3f439953
gpg-pubkey-db42a60e-37ea5438
My system is now up2date, so I can't do any testing at the moment.

Hey cool, it's a heisenbug

When I ran the same command again (nothing changed), it worked.

It's sort of far-fetched, but I thought that I ought to point out that these
sort of "heisenbugs" (good word) tend to happen to me when prelink is in the
middle of working.

That's probably not the case for this bug, but just in case it is, I thought I'd
point it out. If I run into the bug myself, I'll try to debug.

-M

>When I ran the same command again (nothing changed), it worked.

hmm, well. It is crypto, so cosmic rays and flipped bits and
other hardware wackiness could be the cause. 

But seeing it in suddenly start happening would seem
to rule that out (I'm assusing this is new behaviour?)

If anyone sees it again, can they grab a copy of the
file it fails on and put it up somewhere?

rpm version too, since its librpm bubbling up that
it failed the key check.

I'm not sure what you mean by the file it's failing on. Here's todays attempt:

Testing package set / solving RPM inter-dependencies...
########################################
FreeWnn-libs-1.11-39.i386.r ########################## Done.                   
anaconda-help-9.2-1.noarch. ########################## Done.                   
bash-2.05b-31.i386.rpm:     ########################## Done.                   
evolution-1.4.5-7.i386.rpm: ########################## Done.                   
evolution-devel-1.4.5-7.i38 ########################## Done.                   
fedora-release-1-1.i386.rpm ########################## Done.                   
gzip-1.3.3-11.i386.rpm:     ########################## Done.                   
initscripts-7.42-1.i386.rpm ########################## Done.                   
kdebase-3.1.4-6.i386.rpm:   ########################## Done.                   
kdebase-devel-3.1.4-6.i386. ########################## Done.                   
kernel-2.4.22-1.2111.nptl.a ########################## Done.                   
kernel-doc-2.4.22-1.2111.np ########################## Done.                   
kernel-source-2.4.22-1.2111 ########################## Done.                   
libgnomeprint22-2.4.0-1.i38 ########################## Done.                   
libgnomeprint22-devel-2.4.0 ########################## Done.                   
libgnomeprintui22-2.4.0-1.i ########################## Done.                   
libgnomeprintui22-devel-2.4 ########################## Done.                   
libtool-1.5-8.i386.rpm:     ########################## Done.                   
libtool-libs-1.5-8.i386.rpm ########################## Done.                   
mc-4.6.0-6.i386.rpm:        ########################## Done.                   
metacity-2.6.3-1.i386.rpm:  ########################## Done.                   
nautilus-2.4.0-7.i386.rpm:  ########################## Done.                   
ntp-4.2.0-2.i386.rpm:       ########################## Done.                   
prelink-0.3.0-13.i386.rpm:  ########################## Done.                   
redhat-artwork-0.87-1.i386. ########################## Done.                   
redhat-config-network-1.3.1 ########################## Done.                   
redhat-config-network-tui-1 ########################## Done.                   
rpmdb-fedora-0.95-0.2003102 ########################## Done.                   
sendmail-8.12.10-1.1.1.i386 ########################## Done.                   
sendmail-cf-8.12.10-1.1.1.i ########################## Done.                   
Traceback (most recent call last):
  File "/usr/sbin/up2date", line 1187, in ?
    sys.exit(main() or 0)
  File "/usr/sbin/up2date", line 765, in main
    fullUpdate, dryRun=options.dry_run))
  File "/usr/sbin/up2date", line 1050, in batchRun
    batch.run()
  File "up2dateBatch.py", line 82, in run
  File "up2dateBatch.py", line 153, in __installPackages
  File "up2date.py", line 604, in installPackages
  File "up2date.py", line 173, in getRealHeader
rpm.error: public key not trusted
[kaboom@skuld kaboom]$ 

sendmail-cf is the final package. It looks like it's dying at the point when it
transitions from downloading to installing, not while it's installing any
specific package

This is with

up2date-4.1.12-1
rpm-4.2.1-0.30

Created attachment 95577 [details]
strace of failing up2date

I just attached an strace of the failure. It was 33 megs, so I've only attached
the part from halfway through the next-to-last download (of rpmdb-fedora) on
through the crash

At least from the strace, it looks like anaconda-help-9.2-1.noarch.rpm is the
problem, though I can't see why....

Created attachment 95578 [details]
fubar'ed rpm

Hmm, I just looked at the anaconda-help rpm (attached). If you look at it,
you'll see why it's failing ;-)

I wonder how that got pulled down by up2date?

If I delete /var/spool/up2date/anaconda-help* and try again, it pulls down the
HTML doc again, so it looks like its a server-side missing file problem....

Hmm, it's universal to noarch packages:

[kaboom@skuld /var/spool/up2date]$ file *.noarch.rpm
anaconda-help-9.2-1.noarch.rpm:                ASCII English text, with very
long lines
redhat-config-network-1.3.10-1.noarch.rpm:     ASCII English text, with very
long lines
redhat-config-network-tui-1.3.10-1.noarch.rpm: ASCII English text, with very
long lines
[kaboom@skuld /var/spool/up2date]$ 

This is due to the way http://ftp.redhat.com redirects to 404 page it uses a 302
but never sets a 404 header so the page gets snarfed.  There is another bug
where I noted this in.

Other bug closed so adding appropriate text here:

In addition this seems to be due to to http://ftp.redhat.com using a 302 to
direct to the error page and there not being a 404 in the HTTP header:

To reproduce lynx --mime_header
http://ftp.redhat.com/pub/redhat/linux/foo/foo-0.1-1.src.rpm | head

Other mirrors get an I/O Error as expected 

yup

server is redirecting with a 302 to a page that just happens to
say "404" while returning a 200 error code.

aka, as far as up2date is concerned, it redirected it to a perfectly
valid page, not a 404. 

server setup is busted. 

working on better handling this error case.

theoretically better error handling should be in 4.1.15

It wont traceback, but your basically deed in the water
same as with a 404. Except slightly later. Not exactly
sure what else to do, since the resource we want isnt
available.

I would expect just a "Server-side error" message, personally, as an end user.

-M

same here... todays rawhide push 

 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 613, 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

Second time around it works... ???

Can anyone confirm if this is still happening. I can't replicate here
by manually munging the local header xml conversion to point a package
url at a non-existent place
I now get:

An HTTP error occurred

triage->close

I don't think your test is valid (see comment #16). Also I think I saw
it in the up2date version that was supposed to fix it, but it probably
not going to reoccur until we start getting updates.

My test points the target rpm at a nonexistent file, so simulates the
update.  It downloads the 404 page but then handles it.

Edit /var/spool/up2date/fedora-core-1.<timestamp> edit a package url
that you don't have installed, and try to up2date it. If you want you
could set up a locally broken yum repo to test I guess, however I
thing my test should simulate the behaviour.

Michael is correct my test was originally against
download.fedora.redhat.com != ftp.redhat.com, I tried same test
against a rawhide setup against ftp.redhat.com with 4.1.16-1 and issue
still persists (untrusted gpg signature message).

Editing the local file is a good way to test though - apologies for
triager->crack :(

"issue still persists" kicking back to alikins

up2date is no more.