Utilizing facts of homedir organization (was: Exact definition of token S/N field for --with-colons)

Guilhem Moulin guilhem at fripost.org
Fri Nov 9 16:48:41 CET 2018


On Fri, 09 Nov 2018 at 16:12:19 +0100, Peter Lebbing wrote:
> On 07/10/2018 03:01, Daniel Kahn Gillmor wrote:
>> Does this make sense?  you just need to make sure you tie the version of
>> gpg and the keyring into the same initramfs build time.
> The problem is that the gpg invocation is not at the time of building
> the initramfs.

It wasn't, but the hook file is a mere shell script where we can do
pretty much everything (as long as it's nullipotent from the main
system's perspective — besides creating the initramfs image of course).
In fact I implemented dkg's suggestion:

    gpg --homedir="$DESTDIR/cryptroot/gnupghome" … --import <"$PUBRING"

is called by the hook file when the initramfs image is generated, using
the very same gpg(1) binary that's copied to the initramfs.  Hence we're
not relying on its homedir's internals, and we're safe as long as gpg(1)
is able to make use of the homedir content it generates (which is
definitely a reasonable assumption), even if the ‘gnupg’ package is
later is upgraded to a version with a different keyring format or file
name, and diverges from the version included in the initramfs image.
(In fact the ‘gnupg’ package can even be deleted on systems where one is
certain that the initramfs image won't be updated anymore.)

> I have an idea about elegantly handling the fact that the smartcard stub
> is not known during boot, since there doesn't seem to be a stable
> interface to transferring these stubs, and invoking gpg at initramfs
> build time will leave a running gpg-agent, which is rather avoided. I'll
> work this out when I have the time.

I look forward to see that! :-)  FWIW it's not the `gpg` invocation
during initramfs generation that's a blocker, but the fact that listing
secret key material spawns a gpg-agent(1) process hence breaks
nullpotency.  We could make make the hook nullpotent, but at the expense
of a brittle and racy logic I'm reluctant to write or merge in to

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20181109/89a25b8c/attachment.sig>

More information about the Gnupg-users mailing list