Bug 60513 - rpm --checksig gives inconsistant results
rpm --checksig gives inconsistant results
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-28 15:34 EST by mikej3
Modified: 2016-10-06 04:55 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-03-06 01:59:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Verify a package signature using only gpg. (892 bytes, text/plain)
2002-02-28 19:20 EST, Jeff Johnson
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 63478 ovirt-4.0 NEW Fix return value names for VM.ioTune calls 2016-10-10 04:00 EDT

  None (edit)
Description mikej3 2002-02-28 15:34:49 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (WinNT; U)

Description of problem:
This problem has haunted me for a while, but I have been blaming it on a flaky 
LAN.  Today I got these three consecutive results on a newly transfered rpm from 
updates.redhat.com:
[mikej@localhost i386]$ rpm --checksig kernel-2.4.9-31.i386.rpm
kernel-2.4.9-31.i386.rpm: md5 gpg OK
[mikej@localhost i386]$ rpm --checksig kernel-2.4.9-31.i386.rpm
kernel-2.4.9-31.i386.rpm: MD5 GPG NOT OK
[mikej@localhost i386]$ rpm --checksig kernel-2.4.9-31.i386.rpm
kernel-2.4.9-31.i386.rpm: md5 gpg OK

(These results cut and pasted from a telnet seeon to my Red Hat 7.1 system, 
which is current as of the beginning of February).  

Additionally, three consecutive checks of the older kernel-2.4.9-6.i586.rpm show  
"MD5 GPG NOT OK", presumably this file had previously checked as good.  

While the problem shows up most often on kernel files, I have occasionally seen 
it on other large files.  

This failure has been seen on both machines on the LAN (a Pentium II and a 
PentiumPro), but since it was assumed to be a LAN problem which went away when a 
new copy was FTP'd over, an rpm bug had not been considered.  This is the second 
time that consective runs of "rpm --checksig" produced inconsistant results.  

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


How reproducible:
Sometimes

Steps to Reproduce:
1."rpm --checksig *.rpm > sigs.txt" typicall shows one bad file in a collection 
of half a dozen kernel rpms
2.IIRC, the SRPM for kernel 2.4.9-6 was pathological
3.
	

Actual Results:  As quated above, here are three consecutive runs via telnet:  
[mikej@localhost i386]$ rpm --checksig kernel-2.4.9-31.i386.rpm
kernel-2.4.9-31.i386.rpm: md5 gpg OK
[mikej@localhost i386]$ rpm --checksig kernel-2.4.9-31.i386.rpm
kernel-2.4.9-31.i386.rpm: MD5 GPG NOT OK
[mikej@localhost i386]$ rpm --checksig kernel-2.4.9-31.i386.rpm
kernel-2.4.9-31.i386.rpm: md5 gpg OK


Expected Results:  md5 and gpg signatures should have been always good or always 
bad.

Additional info:

Does not seem to be affected by actual hard drive the files are on (these 
results are from hdg, similar results were seen on hde on that box and on hda of 
the other box on the LAN.  

I seem to recall one result of "md5 ok GPG NOT OK", but I may be wrong about 
that.
Comment 1 Jeff Johnson 2002-02-28 19:20:18 EST
Created attachment 47000 [details]
Verify a package signature using only gpg.
Comment 2 Jeff Johnson 2002-02-28 19:22:48 EST
Hmmm, weird.

Of course md5 sums and DSA signatures give invariant,
mathematical, results. But only if given reproducible
inputs. I suspect that you're getting different
data returned when reading for whatever reason.

Try the attached shell script to convince yourself
that your results are caused by something other than rpm.
Comment 3 mikej3 2002-02-28 19:58:27 EST
I don't follow the script bit at all.  It appears to split the rpm data from the 
signature and then check the signature with gpg.  I don't believe it is working:  

[mikej@localhost i586]$ ../i386/bugzilla.sh kernel-2.4.9-6.i586.rpm
D: Expected size:      9892660 = lead(96)+sigs(149)+pad(3)+data(9892412)
D:   Actual size:      9892660
gpg: reading options from `/home/mikej/.gnupg/options'
gpg: Warning: using insecure memory!
gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.
secmem usage: 0/0 bytes in 0/0 blocks of pool 0/16384
[mikej@localhost i586]$ ../i386/bugzilla.sh kernel-2.4.9-31.i586.rpm
D: Expected size:     10533344 = lead(96)+sigs(293)+pad(3)+data(10532952)
D:   Actual size:     10533344
gpg: reading options from `/home/mikej/.gnupg/options'
gpg: Warning: using insecure memory!
gpg: no valid OpenPGP data found.
gpg: the signature could not be verified.
Please remember that the signature file (.sig or .asc)
should be the first file given on the command line.
secmem usage: 0/0 bytes in 0/0 blocks of pool 0/16384
[mikej@localhost i586]$  

The first file showed as bad with rpm --checksig, the second showed as good.  
Neither verified with the script.  

--------------

In any case the "md5 ok GPG NOT OK" was not the issue but rather a side comment.  
The issue is that consecutive runs on an rpm showed both checks good, then both 
checks bad, then both checks good again.  

It is very difficult to "trust" the rpms under these circumstance.
Comment 4 Jeff Johnson 2002-02-28 20:41:49 EST
Ah, pardon, minor brain fart. You'll need
rpm-4.0.4 to extract a detached signature
in the line
    rpm -qp -vv --qf '%{siggpg:armor}' $pkg > $detached


But the core issue is that I still believe
that rpm is not at fault here, programs
(and mathematics) are deterministic, random
results are caused by Something Else. I suggest
the script merely as an alternative to convince
yourself that, indeed, the problem is not in
rpm.
Comment 5 mikej3 2002-02-28 21:03:17 EST
That is why I swore at the LAN for so long.  Still, the three consecutive runs I 
quoted show ~something~ is not right.  A flaky drive should have shown up 
elsewhere have become obvious by now, and would not explain why physically 
different drives showing this behaviour.  OTOH, an uninitalized variable or 
buffer could cause this.  I personally loathe this sort of bug, but I suspect 
that is the case here.  
Comment 6 Jeff Johnson 2002-03-01 08:14:43 EST
OK, send me a pointer to the package and I'll
run --checksig to try to reproduce your problem.

Wanna bet on the outcome? :-)
Comment 7 mikej3 2002-03-01 10:34:38 EST
No bets, but I did speciffically show the problem happenning with 
kernel-2.4.9-31.i386.rpm.  I believe I mentioned that this seemed to be a 
problem with large files, and that in genreal a collection of kernel release 
RPMs would show one bad file.  
Comment 8 Jeff Johnson 2002-03-10 11:01:23 EST
Running rpm -Kv repeatedly on the kernel-2.4.9-31.i386.rpm
package (i.e. the one that's available to me) shows no
problem.

Unless I can reproduce the problem, I'm not gonna be able
to diagnose. I don't believe I'm gonna be able to reproduce
this problem ever, so I'm closing WORKSFORME.
Comment 9 mikej3 2002-03-16 18:33:15 EST
Hate to be a pain and all that, but it's still with me.  I have replaced all the 
memory in the box, and this is a different system build on a different hda.  

This system is RH7.2 ENIGMA being manually patched to current.  binutils is part 
of the zlib fix which would have made the system current.  

[root@localhost Update]# rpm --checksig  binutils-2.11.90.0.8-12.i386.rpm
binutils-2.11.90.0.8-12.i386.rpm: md5 GPG NOT OK
[root@localhost Update]# rpm --checksig  binutils-2.11.90.0.8-12.i386.rpm
binutils-2.11.90.0.8-12.i386.rpm: md5 (GPG) OK (MISSING KEYS: GPG#DB42A60E)
[root@localhost Update]# rpm --checksig  binutils-2.11.90.0.8-12.i386.rpm
binutils-2.11.90.0.8-12.i386.rpm: md5 (GPG) OK (MISSING KEYS: GPG#DB42A60E)

Now, it is likely that the Red Hat keys have not been loaded on this system, 
hence the missing key, but it should not have reported this as "GPG NOT OK" on 
the first run.  

IIRC, gpg behaves differently the first time it is run.  This may have happened 
here and may explain this event if you are chaining to gpg to check the 
signatures.  

Because there was an earlier question about the version of rpm:
[root@localhost Update]# rpm -q rpm
rpm-4.0.3-1.03
[root@localhost Update]# rpm -q gnupg
gnupg-1.0.6-3

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