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

[Peter Lebbing]

On 23/09/2018 17:02, Guilhem Moulin wrote:
> I was thinking about something like that, and that's why I was referring
> to by “the complexity is not worth it IMHO”.  `--list-secret-keys`
> implicitly launches gpg-agent(1) for that homedir, which will need to be
> shut down afterwards (unless it was started manually before).

Oh, I hadn't realized. That's a blocking issue.

> 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, so no breaking options
would be picked up from the normal homedir. scdaemon options like
disable-ccid, enable-pinpad-varlen, disable-pinpad and maybe reader-port
might be useful in some setups where card readers are not completely
compliant with GnuPG's expectations. I couldn't find any useful
(documented :-) options for gpg or gpg-agent either.

> 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.

> 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). I don't see a reason to be using the
--export approach here anyway?

> gpgconf(1) honors GNUPGHOME (and has an undocumented --homedir flag
> since 2.1.7 AFAIK):

Ah yes, I forgot that it wasn't documented, so when I went to the
documentation to check, well... :-)

I'm going to raise the issue of how private the directory/filename
structure in private-keys-v1.d is on GnuPG-Users. Because if they are
deemed an acceptable API, we could just copy a configurable .key stub,
or even find it ourself from an OpenPGP key identifier and
--with-keygrip --with-colons --list-secret-keys etcetera.

It would be easier if we could just --import a stub.

On 23/09/2018 17:17, Guilhem Moulin wrote:
> If we want this to be widely used we should make initramfs image
> generation as quiet as possible.

I meant document it in README.gnupg-sc, not on every initramfs image
generation. Just say that anything in /etc/cryptsetup-initramfs is going
to end up unencrypted in the initramfs, but that since the key for
unlocking the filesystem is already stored encrypted in that directory,
this does not compromise the unlock key. This obviously implies anything
else would be compromised. IMHO, sometimes good documentation can take
the place of full automation/checking.

Cheers,

Peter.

[1] https://lists.gnupg.org/pipermail/gnupg-users/2018-September/060936.html

-- 
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/20180923/73d250af/attachment.sig>