[pkg-gnupg-maint] Bug#839683: apt-key accepts short key IDs

[Julian Andres Klode]

Control: reassign -1 gnugpg
Control: affects -1 apt

On Mon, Oct 03, 2016 at 07:50:27PM +0100, Robie Basak wrote:
> Package: apt
> Version: 1.2.12~ubuntu16.04.1
> 
> I noticed this on Ubuntu, but I believe it affects Debian as well.
> 
> apt-key currently accepts short key IDs. For example,
> https://help.ubnt.com/hc/en-us/articles/220066768 currently instructs
> users to run:
> 
> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50

(1) short ids are not the problem. ids in general are, we only want
    fingerprint

(2) apt-key adv just forwards the arguments to a temporary gpg instance,
    it does not know anything about it. gpg short reject key ids, and
    require full fingerprints to be passed to --recv.

> 
> This is unsafe (eg. see http://gwolf.org/node/4070) but seems to be very
> common in instructions provided by third parties to add their external
> apt repositories. The result is that apt-using users, such as Debian and
> Ubuntu users, end up vulnerable.

Third party repositories should provide a keyring package. Then they tell
the user to download it with apt-helper download-file, and install it with
apt install. To quote David:

  $ /usr/lib/apt/apt-helper download-file http://example.org/keyring.deb keyring.deb SHA256:AAABBBBCCCC…
  # apt install ./keyring.deb
  # apt edit-sources yourcoolstuff.list
  # apt update

Use of apt-key adv or apt-key add is not supported and will be
punished...

> 
> Can we mitigate this somewhat by having apt-key refuse to accept short
> keys in the next release? Then third parties will be forced to update
> their documentation to keep users safe, which they'll notice when they
> QA their apt repositories against the new series.

That's the job of gnupg, not APT's job.

> 
> We still rely on their documentation not recommend that users do other
> unsafe things, and of course this still gives the third party apt
> repository owner "root", but at least this particular commonly used
> unintentional vulnerability path will be closed.
> 
> Of course, if the path the documentation takes to get to users is unsafe
> (such as over plain HTTP), then a man-in-the-middle could still modify
> the instructions. But users are slowly starting to understand to look
> for the HTTPS indicator in their browsers, so this would at least make
> things better.
> 
> Alternatively, if you think this is too harsh, you could still print a
> warning and ask for user intervention before continuing when given a
> short key ID.



-- 
Debian Developer - deb.li/jak | jak-linux.org - free software dev

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.