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

[Peter Lebbing]

On 24/09/2018 11:42, Guilhem Moulin wrote:
> Sure, me too :-)  But I'm afraid of ending up in a situation similar to
> caff(1)'s, where in order to avoid maintaining two sets of conf files
> some users end up symlinking them (or blindly copying them).  I hadn't
> thought of scdaemon.conf, but at least for gpg.conf and gpg-agent.conf
> I'm really not convinced of the usefulness to give users the stick to
> beat themselves with.

Luckily, this particular application should just be working after
initial setup, no need to mess with it anymore unless you buy a new
smartcard reader.

I think scdaemon.conf is necessary for some people.

> Since /etc/cryptsetup-initramfs normally won't be re-written upon
> GnuPG upgrades, we have to trust that GnuPG developers have well
> thought-out upgrade paths and migrations.  It's just a (documented)
> fact that today (GnuPG 2.2.10) `gpg --import` uses ‘pubring.kbx’ as
> default public keyring (and falls back to ‘pubring.gpg’); with <2.1 it
> was ‘pubring.gpg’; and for all I know it might be ‘pubring.kbx2’ in
> some later version.  Since keyrings created with a particular version
> of GnuPG might be used by any (later) version, they need to remain
> supported; either directly, or through a migration mechanism.

Well, the ultimate fail-safe migration mechanism is very
straight-forward. Export to /etc/cryptsetup-initramfs/pubkey.gpg, and in
the decrypt script, --import that first. I see you already use a
default, empty homedir anyway, might as well just --import to that. I do
wonder why you ended up creating the homedir manually, doesn't GnuPG do
that for you when it's the /default/ homedir? I can't just try it out
and see myself, I don't have a Debian testing handy :-). Can build one,
obviously.

My assumption was that when GnuPG significantly changes, changes to
/etc/cryptsetup-initramfs would be necessary anyway. But let's see
whether the keyring format is declared stable.

For now, the --import during initramfs appeals most to me.

> 
>> I don't see a reason to be using the --export approach here anyway?
> 
> I'm not fond of the `| gpg --import` due to the added clutter.  Today
> 
>     gpg --export $KEYID | gpg --homedir="$(mktemp -d)" --import
> 
> creates a trust database ‘trustdb.gpg’ (unless we pass
> `--trust-model=always`), a backup keyring ‘pubring.kbx~’ and an empty
> directory ‘private-keys-v1.d’.  It also launches gpg-agent(1) and
> dirmngr(1) processess (unless we pass `--no-autostart`), and if there
> is no /run/user/$UID directory, uses destination homedir for the agent
> / dirmngr sockets.

Ah. Yes, a trustdb issue, which I thought went fine in the past (I'm not
sure), but it now is all sorts of not fine indeed (lost my actual
trustdb; luckily I have daily backups to rely on). All the other issues
but the trustdb issue are caused by the temporary homedir. This
invocation seems to be fine:

$ TMPTRUST=$(mktemp)
$ gpg --no-default-keyring --keyring /home/peter/test.kbx --trustdb-name="$TMPTRUST" --import test.gpg
$ rm "$TMPTRUST"

But I notice your phrasing "today" :-). This might not be future-proof,
although very little truly is, of course. We are here because it's not
the standalone binary gpg 1.4 was anymore. And it used to be possible
to just import smartcard stubs.

My 2 cents,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20180924/f2dadf8d/attachment.sig>