[pkg-cryptsetup-devel] Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Guilhem Moulin]

Hi,

On Sun, 23 Sep 2018 at 13:32:44 +0200, Peter Lebbing wrote:
> --8<---------------cut here---------------start------------->8---
> #!/bin/sh
> 
> UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys | \
> 	gawk -F: '$1=="sec" || $1=="ssb" \
> 		{ if ($15 !~ /D27600012401.*/ && $15 != "#") { print $5 } }')
> 
> if [ -n "$UNSAFEKEYS" ]; then
> 	echo "Non-smartcard keys found:\n${UNSAFEKEYS}\nAborting" >&2
> 	exit 1
> fi
> --8<---------------cut here---------------end--------------->8---

I was thinking about something like that, and that's why I was referring
to by “the complexity is not worth it IMHO”.  `--list-secret-keys`
implicitly launches gpg-agent(1) for that homedir, which will need to be
shut down afterwards (unless it was started manually before).  Also,
while the bits that matter (the pubring and the stubs) will seldom
change hence /etc is probably the right place to store these, /etc might
be read-only when the initramfs image is generated.  Since gpg(1) needs
a writeable homedir, we'd need to copy stuff around.
 
> Whatever the solution, I think it's a good idea to copy *.conf to the
> GnuPG homedir as well

I'm reluctant to do that since there are plenty of options that would
break the setup: ‘no-autostart’, ‘keyring’, ‘pinentry-program
/path/to/custom/wrapper’, ‘pinentry-program /usr/bin/pinentry-gtk’,
etc., and (beside ‘trusted-key’ maybe) I don't see a valid usecase for
custom config files yet.

> I'm a bit worried that currently, the implementation detail that the old
> pubring.gpg format is the same format as gpg --export is being used.
> This is tripping up people upgrading to GnuPG 2.1, and I think it's a
> better idea to avoid it here as well.

The `--export` command produces RFC 4880 compatible output, which is
also the format for gpgv(1) keyrings and is bound to be supported
forever by gpg(1) (possibly via intermediate upgrade to .kbx like for
the private key material).  Why would that block migration to GnuPG 2.1?

>> By the way, I also added a local-bottom script to kill gpg-agent and
>> scdaemon before execution is turned over to the init binary :-)
> 
> A good idea. If we copy a whole homedir, it might be needed to put the
> homedir in its regular place for that. I suppose this is possible? I
> think gpgconf can only manage daemons started with a default homedir.

gpgconf(1) honors GNUPGHOME (and has an undocumented --homedir flag
since 2.1.7 AFAIK):

    $ GNUPGHOME=/tmp/abc gpgconf --list-dirs homedir
    /tmp/abc
    $ gpgconf --homedir /tmp/abc --list-dirs homedir
    /tmp/abc

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180923/b2167ecb/attachment.sig>