-
Notifications
You must be signed in to change notification settings - Fork 355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rpm should not use short gpg key ids in messages #2403
Comments
Are there scripts out there that parse this output? If so, they will almost certainly break. Perhaps it would be better to do:
|
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 |
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 |
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. |
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:https://www.asheesh.org/note/debian/short-key-ids-are-bad-news.html |
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. |
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:
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:
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
The text was updated successfully, but these errors were encountered: