Bug 2174373

Summary: rpm should not use short gpg key ids in messages
Product: [Fedora] Fedora Reporter: Zbigniew Jędrzejewski-Szmek <zbyszek>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: igor.raits, mdomonko, packaging-team-maint, pmatilai, vmukhame
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-07-04 10:03:40 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Zbigniew Jędrzejewski-Szmek 2023-03-01 11:13:54 UTC 
Description of problem:
(Inspired by #2170878.)
Short gpg key ids are easy to spoof and generally should not be used [e.g. 1].
rpm prints them in various messages:

  warning: google-chrome-stable_current_x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOKEY

There is really no point in trying to save a few bytes. Please print at least the "long" 16-digit hash. With the short id the user cannot even reliably look up the key online.

In other output, please print the full hash:
$ rpm -qi util-linux | rg Signature
Signature   : RSA/SHA256, Sat 21 Jan 2023 11:02:21 AM CET, Key ID 809a8d7ceb10b464

The full finger print is 6A51BBABBA3D5467B6171221809A8D7CEB10B464
and it is just easier to do verification if the full hash is known.

Version-Release number of selected component (if applicable):
rpm-4.18.0-10.fc38.x86_64

[1] https://security.stackexchange.com/questions/84280/short-openpgp-key-ids-are-insecure-how-to-configure-gnupg-to-use-long-key-ids-i
Comment 1 Panu Matilainen 2023-03-01 11:19:38 UTC 
Bugs that aren't Fedora specific are best filed upstream.

While I generally agree on this, various software actually parses these messages and *will* break if/when changed.
Comment 2 Zbigniew Jędrzejewski-Szmek 2023-03-01 11:25:16 UTC 
→ https://github.com/rpm-software-management/rpm/issues/2403
Comment 3 Panu Matilainen 2023-07-04 10:03:40 UTC 
Closing for upstream tracking.