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

[Daniel Kahn Gillmor]

On Mon 2018-09-24 12:44:38 +0200, Peter Lebbing wrote:
> The always-correct option would be to --export, copy the exported key to
> the initramfs, and simply --import it before use, no meddling with
> prefabricated keyrings. It does waste some processing.

I think you're right that this is an "always-correct" option.

But i note that when assembling an initramfs, you have to choose which
version of GnuPG you put in it.  And i also note that the initramfs is
typically never modified once created: rather, a new one might be
created and swapped in.

This suggests that at time of initramfs creation, you can use your
suggested "--no-default-keyring --keyring foo.kbx --import" approach
(using the version of gpg that you are also packing into the initramfs),
and you can be confident that it will work in the initramfs, because the
version of gpg and the keyring will match.  In this case, you only need
to --import at initramfs creation time, and you can avoid the extra
--import at initramfs-run-time.

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.

> So have I been too strict all these years? :-) Are we free to build
> keyrings with --export and will GnuPG happily consume them as an
> always-supported fallback?

I don't know the answer to this about using concatenated TPKs as
keyring.  Maybe Werner can weigh in?

But GnuPG *will* forever continue to consume concatenated TPKs via
--import -- that's the OpenPGP interoperable format, and if GnuPG stops
consuming it on --import, it would no longer be an OpenPGP
implementation.

Regards,

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