rpm should not use short gpg key ids in messages

[keszybz]

Copied over from https://bugzilla.redhat.com/show_bug.cgi?id=2174373:

Description of problem:
(Inspired by https://bugzilla.redhat.com/show_bug.cgi?id=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

[nwalfield]

Are there scripts out there that parse this output? If so, they will almost certainly break. Perhaps it would be better to do:

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

[pmatilai]

Yep, various things do parse that "informational" warning from rpm and will break if changed. Doesn't mean we can never change it, just that we need to be mindful of doing so.

I remember starting towards "use fingerprints everywhere" goal once upon a time but ran into sufficient obstacles to get sidetracked / gave up / something to that effect. The biggest obstacle of them all was probably the gpg-pubkey entries in the rpmdb, with all manner of things expecting the exact version/release "semantics".

[keszybz]

Well, anything which parses this output and makes use of it is broken. I shouldn't be using short ids for anything, particularly not in a script. So I think it's entirely reasonable to just change the output.

Also, I'm not sure if too many things would break. I'd expect that even sloppy parsers would just take field by position of by some regexp with [0-9a-f]+ and not be bothered by the change in length.

[Conan-Kudo]

Well, anything which parses this output and makes use of it is broken. I shouldn't be using short ids for anything, particularly not in a script. So I think it's entirely reasonable to just change the output.

Unfortunately, we can't afford to do that. There are config management tools and layered package managers that parse RPM's output. And we have the model of "it's stable unless documented otherwise". So we have to work with that.

[keszybz]

What "config management tools" are that? Maybe they need to be warned that the output will change and then the output in rpm adjusted after a while. Short gpg ids are widely known to be a bad idea at least since 2011 [1]. Is the idea to set every mistake that was ever made in stone?

[1] http://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html

[pmatilai]

They have been used in some places we know (eg yum) and then there are all those cases we don't know about.

It's not so much the message that needs changing, but the idiotic API that emits this message (needs to die). But to be able to deprecate that API (which happens to be one of the oldest APIs in rpm) we need something better first, which is a long time coming.