Will gpg 1.x remain supported for the foreseeable future?

[Dan Kegel]

On Wed, Jan 17, 2018 at 5:20 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> > - The package depends on debian-archive-keyring (to leverage
> > the web of trust as suggested in 'man secure-apt')
>
> (itym 'man apt-secure', right?)

right.

> if you're expecting ubuntu (or any other non-debian) users to install
> this, then you're actually increasing their attack surface

Correct.  Glad to hear it's a crazy idea, happy to drop it, just
need to understand how trust is established, and how to use the tools.

> what i'm not hearing is an explicit example of how you are using gpg --
> as the archive maintainer, surely you manage the archive itself on a
> system of your choice.  for me, that would be a debian stable system,
> with reprepro or something like that, which should already know how to
> call out to gpg.
>
> as the developer of the foobar-archive package, you shouldn't need to
> invoke gpg at all in your package build scripts other than just --import
> and --export, which should be pretty standard across all versions of
> gpg.

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?  Just ferry active-keys/foobar-archive.gpg straight into
/usr/share/keyrings/foobar-archive.gpg?
(I saw a note about stripping off trust packets, since they're less portable.
Wonder if that's related.)

> You may also be interested in https://bugs.debian.org/861695, fwiw.

Yes, I read that earlier with interest.  Happy to be chatting with a
grandmaster, as it were.

What I am missing is how dropping a key into /usr/share/keyrings,
and then pointing to it with signed-by=, actually establishes
trust.  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'

it says the repo key is bad.  Such a script is long enough
than a secure apt beginner like me is unlikely to be
able to get it right quickly.  Here's the bit where it explodes,
with debugging prints enabled:

+ 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

So I'm forgetting something important, like
avoiding breaking things when I set up an
isolated GNUPGHOME or apt config,
or forgetting to mark the key I just generated
as trusted, or not understanding how apt-key
works, or just plain being dumb.  My next move
is probably reading apt-key and trying to
understand it.  Alternately, I could
try ripping out all the gpg1 support in my scripts.
That probably won't help, but would be satisfying :-)
- Dan