Comment 8 for bug 1481871

Revision history for this message
David Kalnischkies (donkult) wrote :

> Does this issue have a CVE assigned yet? Does it have a Debian bugreport yet?

It has neither and it needs neither in my humble opinion.

The longid issue had its own bugreport in Debian (#754436) which used the included patch (more or less) for Jessie while the 1.1 series (at that time already) had apt-key rewritten fixing this among other things. The unblock request back then mentions explicitly the inability of apt/jessie to work with fingerprints at the benefit of not introducing untested changes late in the release process.
As already mentioned 1.1 in Debian (and Ubuntu) supports fingerprints just fine, so there isn't anything left to be done for Debian.

In the end, "apt-key del" is supposed to be used only to get away from using apt-key as what you are supposed to be doing is ship your own -keyring package which contains a /etc/apt/trusted.gpg.d/ fragment file instead of using "apt-key add /path/to/file" to add your key to a central file (from which you have to delete it again on remove with "apt-key del"). I doubt the chances to have collision even with shortids among archive keyrings in the wild is high. With longids its even less likely. And what exactly is to be gained by such a collision given that all you get is to take another key (you collision with) with you at the time your maintainerscript (run with root rights I have to add) removes it…
[That "apt-key del" isn't failing and can't be changed to do it if it hasn't removed a key is btw based on the problem that its mostly called by maintainerscript, which don't ignore failures]

If on the other hand you happen to think you could revert a "apt-key adv" command like "--recv-key" with a "apt-key del" you are wrong as it isn't safe to fetch a key directly into an always trusted keyring to begin with (mainly as you can't be sure that gpg is actually inserting the key you wanted it to and no amount of fingerprint is helping here). See this subthread (and followups) for the written affirmation of Debians gnupg maintainer(s) that you can't: https://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2015-August/002802.html [just so you don't have to "just trust me" on this].

So, in summary, I believe that the chance that you have a security bug on your(!) side based on the idea that you need a fingerprint in this scenario to interact with apt-key is a lot higher than the chance to encounter a collision even on short keyids in this scenario.