Red Hat Bugzilla – Bug 1480407
rpm 4.13.0 cannot read signature headers made by rpm 4.13.90
Last modified: 2017-09-06 11:46:27 EDT
Description of problem: RPMs generated by RPM 4.13.90 seem to have signature headers that cannot be parsed by 4.13.0.1. Version-Release number of selected component (if applicable): rpm-4.13.90-0.git14002.1.fc27 (generated rpm file) rpm-4.13.0.1-41.fc27 (trying to read rpm file) How reproducible: Consistent Steps to Reproduce: 1. Get an RPM built with rpm-4.13.90 (e.g. https://kojipkgs.fedoraproject.org//packages/net-snmp/5.7.3/24.fc27/aarch64/net-snmp-debugsource-5.7.3-24.fc27.aarch64.rpm) 2. Run rpm -K on it with 4.13.0.1 Actual results: rpm -K net-snmp-debugsource-5.7.3-24.fc27.armv7hl.rpm net-snmp-debugsource-5.7.3-24.fc27.armv7hl.rpm: sha1 ?UnknownSigatureType? md5 NOT OK Expected results: rpm -K net-snmp-debugsource-5.7.3-23.fc27.aarch64.rpm net-snmp-debugsource-5.7.3-23.fc27.aarch64.rpm: sha1 md5 OK Additional info: Note that the Expected output is generated with an RPM built with RPM 4.13.0.
[brain@ignatenko-w541 rpm]$ ./rpmkeys -Kv /home/brain/rpmbuild/RPMS/noarch/dummy-1.0-1.fc27.noarch.rpm /home/brain/rpmbuild/RPMS/noarch/dummy-1.0-1.fc27.noarch.rpm: Header SHA1 digest: OK Header SHA256 digest: OK Payload SHA256 digest: OK MD5 digest: OK [brain@ignatenko-w541 rpm]$ rpmkeys -Kv /home/brain/rpmbuild/RPMS/noarch/dummy-1.0-1.fc27.noarch.rpm /home/brain/rpmbuild/RPMS/noarch/dummy-1.0-1.fc27.noarch.rpm: Header SHA1 digest: OK (e03b0b919aa8c3fb3870eebade5aa59333fa6527) Verify signature: BAD PARAMETERS (273 0xa210889e21 1 (nil) (nil)) MD5 digest: OK (57427666af776b18899b02944a9badf7)
Okay, funnily enough this is actually a bug in 4.13 which doesn't skip unknown elements in the signature header the way it should, 4.11 and 4.12 have no problems verifying the package(s). This seems to fix it (against 4.13.0.1), but I need to test it some more (I've only into first cup of coffee this morning): diff --git a/lib/signature.c b/lib/signature.c index 1b9fe345f..41bf85893 100644 --- a/lib/signature.c +++ b/lib/signature.c @@ -71,6 +71,7 @@ rpmRC rpmSigInfoParse(rpmtd td, const char *origin, break; default: /* anything unknown just falls through for now */ + sinfo->type = RPMSIG_OTHER_TYPE; break; } Which Fedora version is used for signing? F26?
So, the exact problem is that rpm 4.13 fails to ignore the unknown SHA256 header digest in rpmkeys -K, which is what the above one-liner fixes. Everything else works fine even without the patch, actual signing included. Basically the choices are a) hot-patch whatever is doing the signing with the one-liner b) hot-patch 4.14 to not generate the SHA256 digest until we have fixed the other fedora versions
After the second cup of coffee the choice is pretty obvious: time is of the essence, and b) buys as much as we need for practically no cost. So I've disabled SHA256 header digest generation in rpm 4.14 for now: https://src.fedoraproject.org/rpms/rpm/c/14f55d6b2238ecb49c57a8a27db022a9d939637e?branch=master This lets us deal with the older versions at leisure instead of paniced running around in circles. Recommencing rebuilds with the patched 4.14.
Bug 1480480 has nothing to do with this, removing.
The signing systems are on F25 for now, but will move to F26 sometime soonish. If you could make a scratch build of an RPM 4.13 that handles the sha256 headers correctly, we could apply that on the signing servers.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Updates submitted to both F25 and F26 now: https://bodhi.fedoraproject.org/updates/FEDORA-2017-e9a1ddb533 https://bodhi.fedoraproject.org/updates/FEDORA-2017-33d34f3f6b
Panu, thank you. I will update the signing infrastructure over the weekend, so you should be good resubmitting an rpm 4.14 with sha256 headers on Monday.
No rush. I'm not enabling the sha256 digests until at least the F26 update has been in stable for some time. Just to be on the safe side.
Okay, both updates are now in stable so we should be good to proceed with this. The signing infra has been updated by now, right? (based on comment #9 yes, but just double-checking)
The vault is updated now, but the bridge is rhel7.4... will that work?
(In reply to Kevin Fenzi from comment #12) > The vault is updated now, but the bridge is rhel7.4... will that work? Yes, only 4.13 was buggy.
Okay, re-enabling SHA256 digest generation then. Rawhide build proceeding. I'll leave F27 till tomorrow, it's not going anywhere fast anyway because of the beta freeze.