Description of problem: RPM tries to verify package signatures even with --nosignature option given on command line. Version-Release number of selected component (if applicable): 4.11.0.1-1.fc19 How reproducible: always Steps to Reproduce: attempt to install package with invalid signature or unsupported type (tag) of signature and --nosignature on command line Actual results: RPM attempts to verify signatures and fails to install packages with invalid signatures even if --nosignature is given. Expected results: When --nosignature is given RPM does not attempt to verify signatures (and hence installs packages with invalid/unsupported signatures).
Example: # rpm -Uvv --nodeps --nosignature /root/maven-3.0.4-31.fc19.noarch.rpm D: ============== /root/maven-3.0.4-31.fc19.noarch.rpm D: Expected size: 1319960 = lead(96)+sigs(180)+pad(4)+data(1319680) D: Actual size: 1319960 error: /root/maven-3.0.4-31.fc19.noarch.rpm: Verify signature: BAD PARAMETERS (269 0xc28bcc 1 (nil) (nil)) error: /root/maven-3.0.4-31.fc19.noarch.rpm cannot be installed D: added source package [0] D: found 1 source and 0 binary packages rpmVerifySignature() is called even with --nosignature: (gdb) b rpmVerifySignature Function "rpmVerifySignature" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (rpmVerifySignature) pending. (gdb) r -Uvv --nodeps --nosignature /root/maven-3.0.4-31.fc19.noarch.rpm Starting program: /usr/bin/rpm -Uvv --nodeps --nosignature /root/maven-3.0.4-31.fc19.noarch.rpm [...] Breakpoint 1, 0x00007f2f97d88b30 in rpmVerifySignature () from /lib64/librpm.so.3 (gdb) bt #0 0x00007f2f97d88b30 in rpmVerifySignature () from /lib64/librpm.so.3 #1 0x00007f2f97d73364 in rpmpkgRead () from /lib64/librpm.so.3 #2 0x00007f2f97d7378e in rpmReadPackageFile () from /lib64/librpm.so.3 #3 0x00007f2f97d8030f in rpmInstall () from /lib64/librpm.so.3 #4 0x00000000004018ea in main ()
rpmVerifySignature() is normally called despite --nosignature as header SHA verification goes through the same route (digests are sort of "signatures" too in rpm internals), so that part is expected. You need to add --nodigests too to completely bypass the verification steps. Please attach the reproducer package though, I "collect" broken packages, and this case should probably fail with something more descriptive than "BAD PARAMETERS".
(In reply to comment #2) > Please attach the reproducer package though, I "collect" broken packages, > and this case should probably fail with something more descriptive than "BAD > PARAMETERS". I'm affraid I removed it, but I will create a new one. Setting needinfo so I don't forget.
So the package in question was indeed intentionally tampered with? That's how I read this, but just to be sure... (especially given the issues in bug 909618) Testing against fuzzed etc packages is very welcome if that's what this is about, but please always attach such reproducer cases to the bug itself when reporting. Recreating the exact failure case can be really hard, especially if the result is from random mass-fuzzing.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
As explained in comment #2, rpmVerifySignature() getting called despite --nosignature is not a bug because rpm's notion of a "signature" is somewhat peculiar -> NOTABUG. As for the "BAD PARAMETERS" message caused by unexpected NULL's, given the other bugs (like bug 909618) from same timeframe I can only assume this occurred on a system with with a damaged NSS installation. Rpm >= 4.11.1 (in rawhide and heading for f19) detects failure to initialize crypto subsystem and wont even start in such a situation, which should be enough to cover such cases. And as said in comment #4, torture testing with fuzzed packages etc is very welcome, but reproducer packages are needed for analyzing those.