all I wanted was to update the kernel, not a crypto lesson ...

[Nelson Strother]

  OK, so maybe I exaggerated, and would like a bit more of a crypto
lesson.

> On Wed, Oct 03, 2007 at 01:32:25PM +0100, Christopher Brown wrote:
>> Note the --nogpgcheck

  Yes, I had previously considered and rejected this option.  But
once Christopher reminded me of it *after* I had seen these very
same bits *pass* the gpgcheck on another system, I went ahead and
accepted this risk.

>> Probably becuase the key has changed between f7 and f8.

  But I am not comfortable with this explanation.  Remember that on a
second Fedora7 system the package check succeeds?  Also, while I did
not mention it in the previous posting, after seeing failures on the
first system, I did try commands such as:

[root at localhost ~]# rpm --import
http://ftp.linux.ncsu.edu/pub/fedora/linux/development/i386/os/RPM-GPG-KEY-fedora-rawhide
[root at localhost ~]#

which as I understand things would have pulled in the appropriate
changed key, if one had changed.  But, remember, even after this:

On 03/10/2007, Nelson Strother <xunilarodef at gmail.com> wrote:
>>> ...the directory listings of /etc/pki/rpm-gpg/ on the two systems
>>> appear identical.

namely:

  /etc/pki/rpm-gpg:
  total used in directory 64 available 1506220
  drwxr-xr-x 2 root root 4096 2007-05-25 08:39 .
  drwxr-xr-x 7 root root 4096 2007-05-25 08:43 ..
  -rw-r--r-- 1 root root 1910 2007-05-24 16:58 RPM-GPG-KEY
  -rw-r--r-- 1 root root 1706 2007-05-24 16:58 RPM-GPG-KEY-beta
  -rw-r--r-- 1 root root 1519 2007-05-24 16:58 RPM-GPG-KEY-fedora
  -rw-r--r-- 1 root root 1105 2007-05-24 16:58 RPM-GPG-KEY-fedora-rawhide
  -rw-r--r-- 1 root root 1076 2007-05-24 16:58 RPM-GPG-KEY-fedora-test
  -rw-r--r-- 1 root root 1232 2007-05-24 16:58 RPM-GPG-KEY-rawhide

which would seem to shoot down the explanation offered by Matthew, no?

On 10/3/07, Matthew Miller <mattdm at mattdm.org> wrote:
> Or because there's a different key for rawhide. Which there is. :)

  So now that the new kernel is successfully installed, I still want
to understand why this escape route was needed.  If I did not have a
second system to have used as a canary in this coal mine, what would
I have done to resolve this package check failure?

Cheers,
Nelson

p.s. Chris, patience, maybe tonight I will have time to actually *run*
the new kernel and see if it helps.  :-)