Bug 1480407 - rpm 4.13.0 cannot read signature headers made by rpm 4.13.90 [NEEDINFO]
rpm 4.13.0 cannot read signature headers made by rpm 4.13.90
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
27
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: packaging-team-maint
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1480492 1480493
  Show dependency treegraph
 
Reported: 2017-08-10 20:38 EDT by Patrick Uiterwijk
Modified: 2017-09-06 11:46 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1480492 1480493 (view as bug list)
Environment:
Last Closed: 2017-09-06 11:46:27 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
pmatilai: needinfo? (puiterwijk)


Attachments (Terms of Use)

  None (edit)
Description Patrick Uiterwijk 2017-08-10 20:38:35 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.
Comment 1 Igor Gnatenko 2017-08-11 01:46:48 EDT
[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)
Comment 2 Panu Matilainen 2017-08-11 02:11:29 EDT
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?
Comment 3 Panu Matilainen 2017-08-11 02:32:11 EDT
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
Comment 4 Panu Matilainen 2017-08-11 03:02:13 EDT
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.
Comment 5 Panu Matilainen 2017-08-11 05:04:08 EDT
Bug 1480480 has nothing to do with this, removing.
Comment 6 Patrick Uiterwijk 2017-08-11 09:34:36 EDT
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.
Comment 7 Jan Kurik 2017-08-15 04:40:43 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.
Comment 9 Patrick Uiterwijk 2017-08-18 08:16:15 EDT
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.
Comment 10 Panu Matilainen 2017-08-18 08:53:27 EDT
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.
Comment 11 Panu Matilainen 2017-09-04 00:29:02 EDT
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)
Comment 12 Kevin Fenzi 2017-09-05 21:17:58 EDT
The vault is updated now, but the bridge is rhel7.4... will that work?
Comment 13 Igor Gnatenko 2017-09-06 01:10:06 EDT
(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.
Comment 14 Panu Matilainen 2017-09-06 11:46:27 EDT
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.

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