Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 62802 - up2date-2.7.61-7.x.2 - up2date.py using wrong flag for rpm.checksig
up2date-2.7.61-7.x.2 - up2date.py using wrong flag for rpm.checksig
Product: Red Hat Public Beta
Classification: Retired
Component: up2date (Show other bugs)
i386 Linux
low Severity low
: ---
: ---
Assigned To: Adrian Likins
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2002-04-05 13:50 EST by James Manning
Modified: 2005-10-31 17:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-11 15:00:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description James Manning 2002-04-05 13:50:22 EST
this may be less of a bug and more a question of expected behavior. 
up2date_client/up2date.py's checkRpmMd5 takes one of 2 routes - if it can,  
rpm.checksig(fileName, rpm.RPMTAG_SIGMD5) otherwise /bin/rpm -Kv --nopgp 
if you apply this patch: 
to up2date you see that they don't return the same thing - specifically, rpm 
-Kv does return "MD5 sum OK" (and hence returns 0 for checkRpmMd5) but 
rpm.checksig(fileName, rpm.RPMTAG_SIGMD5) is returning 1 which is breaking 
Checking rpm-4.0.4/python/rpmmodule.c, we just call through to rpmCheckSig 
with the appropriate flags set.  Then checking rpm-4.0.4/lib/rpmchecksig.c it 
*looks* like (hard to tell for sure) that it should return 0 if the md5 on the 
file is fine (and the md5 flag was passed) 
So the question is: is rpm.checksig returning 1 expected behavior for an rpm 
with a good md5sum?  And if not, any idea what's going on (flag translation is 
all that makes sense as a guess given the rpm -Kv works) 
Getting headers for available packages...  
rpm.checksig returns 1 on file /var/spool/up2date/zip-2.3-12.i386.rpm  
rpm -Kv returns 0 on file /var/spool/up2date/zip-2.3-12.i386.rpm
Comment 1 Jeremy Katz 2002-04-11 03:20:07 EDT
You should do

rpm.checksig(filename, rpm.CHECKSIG_MD5)  
rpm.checksig(filename, rpm.CHECKSIG_GPG)

as opposed to SIGTAG_MD5 and SIGTAG_GPG
Comment 2 James Manning 2002-04-11 03:30:15 EDT
1) the flag was rpm.RPMTAG_SIGMD5 - what is SIGTAG_MD5? is that the equiv once 
it gets into C space?

2) sounds like you're saying that up2date.py's not using the right flag, so I'm 
reopening this as an up2date bug
Comment 3 James Manning 2002-04-11 03:31:42 EDT
ugh - i had hoped the bug owner would shift along with component, but here's 
step 2 to get this over to adrian
Comment 4 James Manning 2002-04-11 03:42:37 EDT
jeremy told me you've already got this fixed in cvs, adrian, so either 
close/dup this on whatever or use it to lemme know when the fix makes it 
out ;)  Kinda funny since this is all orthogonal once you switched to file size 
instead of md5 checks in bug 53583
Comment 5 Adrian Likins 2002-04-11 15:00:17 EDT
yeah, fixed in cvs, around 2.7.77 or so

It's not completely orthogonal since I use the md5 sum
when reading stuff off local disk cache to see if the files
are complete, and if not I download them again.

Thats what was causing the "skipjack always downloads
the packages" bug.

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