Your message dated Sun, 05 Feb 2017 03:56:24 -0500
with message-id <[email protected]>
and subject line Re: [pkg-gnupg-maint] Bug#839683: apt-key accepts short key IDs
has caused the Debian Bug report #839683,
regarding apt-key accepts short key IDs
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
839683: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839683
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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

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.

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.

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.

Attachment: signature.asc
Description: PGP signature


--- End Message ---
--- Begin Message ---
Over on https://bugs.debian.org/839683 On Mon 2016-10-03 17:48:21 -0400, Daniel 
Kahn Gillmor wrote:
> 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 :/

I never heard any specific changes that need to be made to GnuPG out of
this discussion, so i'm going ahead and closing #839683 .

If anyone has concrete suggestions, they're welcome to reopen the bug
report (or to open a new one, of course).

       --dkg

Attachment: signature.asc
Description: PGP signature


--- End Message ---

Reply via email to