Bug 60513
| Summary: | rpm --checksig gives inconsistant results | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | mikej3 | ||||
| Component: | rpm | Assignee: | Jeff Johnson <jbj> | ||||
| Status: | CLOSED WORKSFORME | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.1 | CC: | herrold, shishz | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | i386 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2002-03-06 06:59:39 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
mikej3
2002-02-28 20:34:49 UTC
Created attachment 47000 [details]
Verify a package signature using only gpg.
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. 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. 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.
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. OK, send me a pointer to the package and I'll run --checksig to try to reproduce your problem. Wanna bet on the outcome? :-) 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. 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. 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 |