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

[Guilhem Moulin]

On Sun, 23 Sep 2018 at 17:59:20 +0200, Peter Lebbing wrote:
>> 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 meant *.conf files specific to the initramfs

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.

>> 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).
> 
> Is this documented that it is bound to be supported by gpg? Because I
> always hear and repeat myself that the format of a keyring is an
> implementation detail, and anybody building keyrings this way should be
> prepared for problems, which they do have. [1] is fresh in my memory,
> but it might actually have been caused by a different problem. It's not
> the first time it's cropped up though.

I saw your latest thread on gnupg-users at gnupg.org, thanks for raising,
let's now wait for Werner's reply :-)  

>> Why would that block migration to GnuPG 2.1?
> 
> It's not related to migration here. I meant that you aren't supposed to
> be constructing keyrings with --export, this has to my knowledge never
> been an intended feature. You use --no-default-keyring --keyring X
> --import to build keyrings only (well, appending is possible with
> --primary-keyring as well).

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.

> 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.  Moreover if the
new homedir starts being further used, for instance because the user
runs `--card-status`, one might find stalled lock files, and/or
‘reader_$N.status’ for the reader status changes.

These files are most likely harmless but needlessly clutter the
initramfs image.  If we're peeking at the directory to copy only the
files we need, we might end up relying on some implemention details and
break forward compatibility. (For instance the default public keyring
filename might change — again — in the future.)

-- 
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/20180924/a4d86c27/attachment.sig>