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

[Daniel Kahn Gillmor]

On Mon 2016-10-03 15:04:06 -0400, Julian Andres Klode wrote:
> Control: reassign -1 gnugpg

there's no source package named 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

FWIW, this sounds like a pretty severely bad bug in the ubuntu help
article.  This is terrible advice, not only because of the short key ID,
but because the keyserver can send you *anything* (including stuff that
doesn't match the key ID) and many still-distributed versions of gpg
will just accept it.

Recent versions of GnuPG have some partial filtering in place for
--recv, but (a) i do not believe it is complete, and (b) it's not
something that generic instructions should be relying on anyway.

> 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...

fwiw, if you're going to do this, it might be even more efficient to
ship a "repo-source" package instead of a "keyring" package.

a "repo-source" package would drop a keyring into
/usr/share/keyrings/whatever-keyring.gpg and a configfile in
/etc/sources.list.d/whatever.list which would have a Signed-By option
pointing to the keyring.  Then users wouldn't need the intermediate step
of fiddling with "apt edit-sources".

I don't know of any external repos that follow this pattern today, but
it seems strictly better than the practice described above.  Any reason
we shouldn't encourage it?

>> 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.

Asking GnuPG to refuse short Key IDs generally is a weird idea -- where
should they be refused?  What if i want to query gpg to see what keys i
have that match a given key ID?  What if the *only* thing i have is a
short key ID, and i just want to send someone mail that would otherwise
go in cleartext?  should gpg refuse to offer to retreive the key?

I don't see a clear implementable suggestion for GnuPG in this
discussion yet, sorry :/

>> 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.

if we want to add warnings, we should add warnings to "apt-key adv" and
"apt-key add".  these things are dangerous.

         --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161003/bb9400a8/attachment-0003.sig>