On Wed, Jan 17, 2018 at 5:20 PM, Daniel Kahn Gillmor <d...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users