Bug 493126 - use sha256 to gpg sign *-CHECKSUM files
use sha256 to gpg sign *-CHECKSUM files
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: pungi (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: David Cantrell
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks: fedora-sha2
  Show dependency treegraph
 
Reported: 2009-03-31 13:59 EDT by Till Maas
Modified: 2013-01-10 00:07 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-25 18:05:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Till Maas 2009-03-31 13:59:32 EDT
Description of problem:
The checksum in *-CHECKSUM files are done with sha256sum, but the gpg signature only uses SHA1:

$ grep Hash F11-Beta-i686-Live-CHECKSUM
Hash: SHA1

Additional info:
Passing this to gpg will probably make it use SHA256 instead:

--digest-algo SHA256
Comment 1 Bug Zapper 2009-06-09 08:52:42 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Miloslav Trmač 2009-06-30 12:37:31 EDT
This was fixed in time for F11.  Thanks!
Comment 3 Till Maas 2009-11-17 16:37:16 EST
For F12, SHA1 was used again! :-(

$ curl -s  https://fedoraproject.org/static/checksums/Fedora-12-i386-CHECKSUM|grep Hash
Hash: SHA1
Comment 4 Zeev Tarantov 2009-12-14 06:51:42 EST
Worse: SHA256 was used (just look at the length of the hash, or run sha256sum on the iso yourself), but the CHECKSUM file says "SHA1". The hash is right, it is signed with the right key, but it is labeled incorrectly, so that if a machine were going to verify it, it would say it is either wrong or invalid. Such an error slipping through means the hash was never verified, which is a concern.
Comment 5 Till Maas 2009-12-14 07:12:52 EST
(In reply to comment #4)
> Worse: SHA256 was used (just look at the length of the hash, or run sha256sum
> on the iso yourself), but the CHECKSUM file says "SHA1". The hash is right, it
> is signed with the right key, but it is labeled incorrectly, so that if a
> machine were going to verify it, it would say it is either wrong or invalid.
> Such an error slipping through means the hash was never verified, which is a
> concern.  

sha256sum was used to create the hash values of the individual files listed in the CHECKSUM file, but SHA1 was used to create the signature of the list of sha256 hash values. Within the section that starts with "-----BEGIN PGP SIGNATURE-----", there SHA1 is used. This is what the "Hash: SHA1" line says after "-----BEGIN PGP SIGNED MESSAGE-----".
Comment 7 Miloslav Trmač 2010-04-28 10:31:30 EDT
Same problem with F13 beta.
Comment 8 Jesse Keating 2010-04-28 11:17:12 EDT
This will require support in sigul for doing sha256 signatures when clear signing.  That support doesn't exist yet.
Comment 9 Miloslav Trmač 2010-04-28 11:32:36 EDT
See https://bugzilla.redhat.com/show_bug.cgi?id=480017#c1 .

This should affect all signing operations; RPM signatures do use SHA-256, was the checksum file signed using a different mechanism?


(sigul sign-rpm --v3-signature) has no equivalent in (sigul sign-text), but v3/v4 signature format is unrelated to the hash algorithm used.
Comment 10 Jesse Keating 2010-04-28 13:45:26 EDT
I think what's missing is setting the preference in sigul's gpg.conf.  I had assumed that by setting it, we would be unable to generate sha1 signatures for our older rpm systems.  I'll have to test this.
Comment 11 Jesse Keating 2010-05-25 18:05:57 EDT
Since this is a process issue, not a pungi issue, I've filed this in releng trac.  https://fedorahosted.org/rel-eng/ticket/3762

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