Will gpg 1.x remain supported for the foreseeable future?
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Jan 19 04:52:28 CET 2018
On Wed 2018-01-17 20:58:21 -0800, Dan Kegel wrote:
> Does one even need --import and --export while building foobar-archive;
> aren't the thing being imported and the thing being exported
> the same format?
i don't know -- what are you importing? if the thing you're importing
is already a clean Transferable Public Key, then you are right: you can
deploy it with /bin/cp or /bin/cat or /usr/bin/install :)
> (I saw a note about stripping off trust packets, since they're less
> portable. Wonder if that's related.)
trust packets aren't part of a Transferable Public Key -- if you're
seeing trust packets, then the thing you're working with was never a
Transferable Public Key in the first place :/
> What I am missing is how dropping a key into /usr/share/keyrings,
> and then pointing to it with signed-by=, actually establishes
hm, that pesky "trust" word again ;) -- let's be clear what we mean
The actions you describe above mean that the user is willing to rely on
this key to certify the archive listing from your APT repository.
this is a narrowly-scoped "trust", because it also means that the user
will *not* accept signatures from the key in question on any *other*
This is good -- in the security sense of "trusted", we want to *reduce*
trust, not expand it, right? things that you trust can violate that
trust and you're helpless.
> I mean, it makes sense and all, but when I write a
> regression test script that :
> - sets GNUPGHOME to an empty directory
> - generates a key
> - creates a repo using reprepro signed by that key
> - creates a dummy package
> - adds it to the repo
> - tries to access the repo with 'apt-get update'
if this is the only thing happening, apt will indeed fail, because it
has never heard of the "new key" that was just created -- why should it
accept signatures from that new key?
how are you configuring the target system to point to the repo? how are
you telling it where to find the key?
I'd expect somewhere in there to be a "gpg --export" of the
newly-created key, into a simple file that can be picked up later.
> + sudo GNUPGHOME=/tmp/obs_localbuild_gpghome_dank.tmp APT_CONFIG=/home/dank/src/obs/foo.tmp/etc/apt.conf apt-get -q -q update
> inside VerifyGetSigners
> Preparing to exec: /usr/bin/apt-key --quiet --readonly --keyring
> /tmp/obs_localbuild_gpghome_dank.tmp/keyrings/localhost.gpg verify
> --status-fd 3 /tmp/apt.sig.UbNAaM /tmp/apt.data.5w6fyj
> Read: [GNUPG:] ERRSIG 77D1F0D4EC3422C4 1 8 01 1516232802 9
> Got ERRSIG
> Read: [GNUPG:] NO_PUBKEY 77D1F0D4EC3422C4
> Got NO_PUBKEY
this looks strange to me -- you seem to be using a --keyring that is
*inside* the GNUPGHOME that you've set
that GnuPG homedir is really not part of the GnuPG API contract -- and
anything you put in that homedir could potentially be overwritten by
GnuPG itself. How is
This seems like the sticking point to me.
> or forgetting to mark the key I just generated as trusted
there's no need to mark any keys as "trusted" with GnuPG for apt's sake.
Apt represents its "trust" (willingness to rely on a key to generate
acceptable signatures over an archive) in one of two ways:
a) placement in /etc/apt/trusted.gpg or /etc/apt/trusted.gpg.d/*.gpg
b) placement elsewhere in the filesystem, pointed to by a signed-by
option in a line in /etc/apt/sources.list or
/etc/apt/sources.list.d/*.list; or pointed to by a Signed-By: header
in a stanza in /etc/apt/sources.list.d/*.source (see sources.list(5)
for more details about the way that signed-by can be presented).
the keys placed in the filesystem at the locations described in (a) are
acceptable for making signatures over *every* apt repository configured
on the system, except those with an explicit signed-by directive, which
are more constrained.
The keys referred to via signed-by are the only acceptable keys for the
associated apt repo.
does that make sense?
More information about the Gnupg-users