Dealing with apt's GPG signing stuff -- the right way.

Philippe blogs about how one can import a GPG key into apt's GPG keyring so that it will stop complaining about unknown keys. While his method will work, it has a major flaw:

Importing random keys without checking them first makes secure apt totally useless, since it allows an attacker to replace an apt repository with another one that he signed with his own key and you won't even notice because you blindly import keys anyway.

So what's the right way? Depends:

  • If you have a GPG key yourself, and you have built a local web of trust (with gpg's --update-trustdb command—beware, this is an interactive process that can take a long time if you have a lot of keys in your local gpg keystore), you can verify that the key really is what it claims to be: 
    wouter@celtic:~$ gpg --edit-key 6070D3A1
gpg (GnuPG) 1.4.9; Copyright (C) 2008 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  1024D/6070D3A1  created: 2006-11-20  expires: 2009-07-01  usage: SC  
                     trust: never         validity: full
[  full  ] (1). Debian Archive Automatic Signing Key (4.0/etch) <ftpmaster@debian.org>

Command> quit

    Why --edit-key? Because --list-keys, --list-sigs, or even --check-sigs does not show you the validity information. The --list-sigs --with-colons output does, but that is meant for computer consumption, and isn't very useful for human beings. But --edit-key contains the information too, so that works.

    What you need to look at is the information that immediately follows 'validity:'. In my case, it says 'validity: full', meaning, "enough" people who I have indicated (using --update-trustdb) to trust that they can sign keys the proper way have signed this particular key. "Enough" is configurable, but for now, let's ignore that (there's plenty of data about that on the web if you want it).

    If your output says 'validity: full', then go ahead and add it to apt's trusted keyring:

    gpg --export 6070D3A1 | apt-key add -

    Note: go ahead and ignore the 'trust: never' data in the output. This represents the fact that I told gpg not to trust the key when doing gpg --update-trustdb. This doesn't mean I won't trust data that's signed with this particular key; however, it does mean I won't trust key signatures signed with this particular key. Since this is not a personal key, but a key only used to sign data with, this is the right thing to do for this particular key.

  • Alternatively, if you don't have a keyring, don't want to maintain your local web of trust, don't understand what I just said, or any combination of the preceding, just check what the maintainers of the particular repository to which this key corresponds tell you. If they're good maintainers, they should've given you a fingerprint right beside the information that contained the apt repository. Copy-and-paste that information on two command lines: 
    gpg --keyserver subkeys.pgp.net --recv-key <fingerprint>
gpg --export <fingerprint> | apt-key add -

    If they didn't give you that information, then send a giant cluebat mail to them. They really should've done that.

  • Finally, if you don't care about all this gpg stuff and don't think anyone would be interested to break into your system, you'd be wrong—scriptkiddies don't look at who's using a particular system, they just like to be stupid. If you insist, however, you should note that you can actually disable secure apt, by adding the following to a file under /etc/apt/apt.conf.d: 
    APT::Get::AllowUnauthenticated "yes";

    Not that I'd recommend it, but if you insist...