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.
