Hi Daniel, Daniel Kahn Gillmor <d...@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.
signature.asc
Description: Digital signature