[pkg-gnupg-maint] Bug#851774: Stop using apt-key add to add keys in generators/60local

[Cyril Brulebois]

Hi Daniel,

Daniel Kahn Gillmor <dkg at fifthhorseman.net> (2017-02-04):
> On Sat 2017-02-04 18:25:52 -0500, Cyril Brulebois wrote:
> 
> > I'm adding gnupg maintainers in cc since they might have interesting
> > tips for the implementation. Context: we need to replace apt-key add
> > calls with dropping files under the appropriate names for extra
> > repositories in a Debian Installer context.
> 
> Thanks for the Cc, KiBi.
> 
> I think that extra repositories should *not* have their keys added to
> /etc/apt/trusted.gpg.d/*.gpg ("the fragment directory") by default,
> since that authorizes the extra key to make valid signatures for the
> main archive.
> 
> If the extra repo has its own key, it should be authorized to make
> signatures only for the extra repo, and nothing else (similarly, the
> official debian archive keys *shouldn't* be authorized to make
> signatures for the extra repo).
> 
> So if we're talking about adding extra repositories for a debian stretch
> installer, as i said over on #853858:
> 
>   for Debian 9 ("stretch") and later, you should place these keys (in
>   binary form) someplace within /usr/local/share/keyrings/ and add a
>   "Signed-By:" option to the relevant apt sources (see sources.list(5)).
> 
> Does that strategy sound right overall to the rest of you?

I'm fine with (discovering and) following best practices.

> Regardless of the choice of filesystem location (fragment directory or
> elsewhere), gpgv does want to see the curated keyrings it depends on
> in binary format, so on to the next bit:

I'm a bit confused here: apt-get update (in a sid chroot, not attempted
in d-i) is fine with an armor key in the fragment directory; are you
saying that using the Signed-by option for sources.list would mean
having to have a (curated) keyring, and an non-armored version, hence
the need for the transformation you're suggesting below?

> > so I think we need to have some kind of autodetection code. gnupg
> > maintainers: is grepping for “BEGIN PGP PUBLIC KEY BLOCK” enough to
> > decide between armored and non-armored? Or do you have any better
> > solutions?
> 
> If the keyring is non-armored, i assume that we're just going to try
> to use it as-is, without transformation.  So the question is: which
> incoming keys do we want to try to transform?
> 
> I'd err on the strict side and say that we really only want files that
> contain nothing but a public key block.  That is, if there's any
> garbage text before the ASCII-armored header, we probably want to
> reject the file rather than trying to transform it.  This strictness
> avoids tripping up in really bizarre corner cases (like if someone
> provides an non-armored key that contains a notation, uid, uat, or
> other embedded data that itself has the string "BEGIN PGP PUBLIC KEY
> BLOCK" in it).  I can cook up such a perversity if it would make
> anyone happy ;)
> 
> The strictness does mean that people who'd, say, copied and pasted an
> entire e-mail message that includes a key and expected it to JustWork™
> might be disappointed, but i might be OK with that.  Being clean about
> what's in your repo keyrings is a habit we want to cultivate.

Remember we're talking about adding extra repositories with custom d-i
configuration, so I'm fine with people having broken stuff because they
pasted a whole mail…

> If you agree with being strict, then the following pipeline should
> return 0 if the keyring is ASCII-armored:
> 
>     head -n1 | grep -Fxq -e '-----BEGIN PGP PUBLIC KEY BLOCK-----'

I might not have used all those flags but that's what I had in mind,
thanks. :)

> If you want to be a little less strict and permit arbitrary whitespace
> before the block, you could do:
> 
>     awk '/[^[:space:]]/{ print $0; exit }' | grep -Fxq -e '-----BEGIN PGP PUBLIC KEY BLOCK-----'

No awk in d-i, so I'll go with the strict version and we'll see if we
have users who could complain and why.

> I've tested and both of these pipelines appear to work with their
> busybox variants using busybox 1:1.22.0-19+b1 on amd64.

Thanks for checking but… nice try. ;-)

> So if you're OK with that test, then you need the transformation:
> 
> Over in #831409, i mentioned this simple pipeline to perform the actual
> transformation:
> 
>      awk '/^$/{ x = 1; } /^[^=-]/{ if (x) { print $0; } ; }' | base64 -d
> 
> Unfortunately, it looks to me like busybox doesn't offer a base64 applet
> at the moment, which would otherwise allow d-i to do the de-armoring
> entirely with busybox.  I could probably knock that applet together if
> people want it -- it looks like busybox already has b64 subroutines in
> it.

Depending on answers to various questions above, we'll see about adding
new applets to busybox if needed.

> Hope this helps!  I'm happy to follow up on it with you.

It definitely does (even if that means some more work than I initially
anticipated, but heh, I was asking for it! :)), thanks!


KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20170205/dc66d8a1/attachment.sig>