From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012 Description of problem: If there is no ~/.gnupg directory, rpm --checksig gives an incorrect result the first time it is run. e.g. [root@xpc1 RPMS]# rm -rf ~/.gnupg/ [root@xpc1 RPMS]# rpm --checksig LPRng-3.7.4-28.i386.rpm LPRng-3.7.4-28.i386.rpm: md5 GPG NOT OK [root@xpc1 RPMS]# rpm --checksig LPRng-3.7.4-28.i386.rpm LPRng-3.7.4-28.i386.rpm: md5 (GPG) OK (MISSING KEYS: GPG#DB42A60E) This is confusing, as it appears the rpm has changed contents. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Remove .gnupg directory 2. Use rpm --checksig on rpm from RedHat distribution. 3. Additional info:
Add a third step: 3. ll ~/.gnupg You'll discover that gnupg has created a default ~/.gnupg which contains a default options file and an empty public and secure key-ring.
You also need to use gpg to import whatever public keys you wish to use for package verification.
I still think this a bug. I'm aware you need to import keys, but the initial message (which you'd get after a fresh install) is: LPRng-3.7.4-28.i386.rpm: md5 GPG NOT OK Which implies there's something wrong with the package (it doesn't even say the md5 is okay), even though it just means that gpg hasn't been run before. rpm should give the same message on different invocations.
I think it's a bug too, fix well underway on the development branch of rpm. Hint: signatures are always verified when package is read, user doesn't get a choice.