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
signature.asc
Description: PGP signature
