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 [email protected], 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.
signature.asc
Description: PGP signature
