GnuPG v2 support in initramfs for LUKS PGP keys.

[viewizard]

Could you please, add gnupg v2 support? The issue is /usr/bin/gpg-agent, that must be also copied for gnupg v2.
Here is the bug I filled in Gentoo bugzilla https://bugs.gentoo.org/show_bug.cgi?id=583748 with boot process photo (by some reason I can't attach photo into this issue).

Upd.

I just made some tests, and looks like gnupg-v2 need staticly builded pinentry, that not allow gtk/qt4 stuff (in Gentoo ebuild). Is the any chance for internal gnupg-v1 build in order to provide GPG support, something like busybox build?

[sakaki-]

+1. In my EFI install guide (which uses genkernel, via some custom scripts, and an encrypted LUKS keyfile), I ended up creating a static version of gnupg v1 (staticgpg) which is automatically copied into the initramfs; the ebuild is here. It'd be nice to see this fixed upstream in genkernel though.

[mudler]

bda99a4

Can't reproduce right now, give me a feedback and let's see if fixes your problems. About the building internally: once genkernel was building gpg 5750b8a, i see no particular reason to go back. In your case my suggestion is to temporary build static gpg and then re-emerge the old one back.

[viewizard]

Can't reproduce right now, give me a feedback and let's see if fixes your problems.

I already tested same idea as you have in the patch, as I wrote in "Upd" of first message, pinentry needs to be installed into initramfs too. And I still don't see any way to build static pinentry:

1. static build can't be used with gtk and qt4 support in the same time (I use pinentry-gtk in xfce4);
2. pinentry require ncurses, that can't be build with static-libs and gpm support (required by others installed packages) in the same time.

So, I stack with gnupg-v2 integration with internal system gnupg-v2/pinentry packages on Gentoo.

In your case my suggestion is to temporary build static gpg and then re-emerge the old one back.

Yes, I do exactly this. But this mean all users with gnome-keyring and/or gvfs, forced do the same.

Btw, probably will be good idea at least warn ppl, if gnupg-v2 detected (/usr/bin/gpg + /usr/bin/gpg-agent) instead of gnupg-v1, that gnupg-v2 version not supported and they might face issues during boot with LUKS PGP keys and crypted root partition.

[mudler]

I don't have any resources here to test as for now. But in the worst scenario, if such requirements conflicts with your system too much, i think you can however build the whole statically without using emerge (heh), and use the static built just temporarly. Alternatively you could also use a container to do the job. The patch holds in the scenarios where you have the static gpg-agent.

But yes, you are right, i'll add a warning that is not supported as for now.

Edit:
If that can help @Sabayon we have https://github.com/Sabayon/sabayon-distro/blob/master/app-crypt/pinentry-base/pinentry-base-0.9.1.ebuild which is a "split" version of pinentry

[viewizard]

I have one more idea, @mudler. Is it possible add user custom gnupg binary variable, as priority binary for initramfs compilation?

What exactly I mean:

1. Add to configuration also custom user binary variable (something like):

# Add in GnuPG support
#GPG="no"
#GPG_CUSTOM_BINARY="/usr/local/bin/gpg"

• somehow add info into configuration file, that, if GPG_CUSTOM_BINARY used, GPG_CUSTOM_BINARY must route to gnupg-v1 static binary file.

2. Add into gen_initramfs.sh check for GPG_CUSTOM_BINARY as for priority gpg binary (something like):

if <GPG_CUSTOM_BINARY> precent
  copy <GPG_CUSTOM_BINARY> as /usr/bin/gpg into initramfs
else
  copy system /usr/bin/gpg into initramfs (current code we have now in gen_initramfs.sh)
fi

• plus, if GPG_CUSTOM_BINARY not used and system have gnupg-v2 instead gnupg-v1 installed - warn about issues with gnupg-v2 during boot.

In this way, we could have local ebuild with gnupg version we need, installed in safe (non system) place without any conflicts with system gnupg package. I don't see, how gnupg could be SLOTed, but some gnupg-static package with gnupg-v1 static gpg version installed as "/usr/bin/gpg-static" or in different place is more realistic to be added even into portage tree...

[viewizard]

I realized idea from my previous post:

1. added gnupg-static local package that install only gnupg v1 static binary /usr/bin/gpg-static (same ebuild as for gnupg-v1 from portage tree, except src_install() and altered to be "static" only );
2. added /etc/portage/env/sys-kernel/genkernel-next

post_src_unpack() {
sed -i -e 's#/usr/bin/gpg#/usr/bin/gpg-static#' "${S}"/defaults/initrd.d/00-crypt.sh || die
sed -i -e 's#/usr/bin/gpg#/usr/bin/gpg-static#' "${S}"/gen_initramfs.sh || die
}

Work exactly as I need without any hand-made scripts and portage conflicts. Hope, this will help.

And one more issue with gnupg-v2 what I faced with (during mount non-root partitions with LUKS PGP keys) - password request redraw all console output, instead of 1 line password request in gnupg-v1. Not even sure, how gnupg-v2 will work with boot splash at all, since pinentry want all screen to be redrawing for password request on screen center.

[ghost]

Hi,

Is there any news on this ?
I'd like to bring openpgp smart card support to unlock the luks keyfile but I'm a little stuck with GPGv1 and gpgsc-deamon.
I found this werwurm/plymentry which could solve the "hard part" of passing the PIN code to GPG (plymouth) but I'm no C++ guy and I don't know where to start.

I personally have a CCID reader with a keypad so pinentry isn't really an issue for me but I want it to work for everybody :)

Rgds,

[vizv]

I've got genkernel-next working with GnuPG 2 and use my Yubikey to unlock my LUKS partition:

First patch gen_initramfs.sh:

--- /tmp/gen_initramfs.sh       2019-12-11 11:06:02.420034211 -0800
+++ /usr/share/genkernel/gen_initramfs.sh       2019-12-03 10:27:29.657421471 -0800
@@ -627,7 +627,10 @@
     mkdir -p "${TEMP}/initramfs-gpg-temp/sbin/"

     print_info 1 "Including GPG support"
-    copy_binaries "${TEMP}/initramfs-gpg-temp" /usr/bin/gpg
+    copy_binaries "${TEMP}/initramfs-gpg-temp" \
+            /usr/bin/gpg \
+            /usr/bin/gpg-agent \
+            /usr/libexec/scdaemon

     cd "${TEMP}/initramfs-gpg-temp/"
     log_future_cpio_content

Then create a directory called overlay some where and copy your ~/.gnupg directory into it.

Next enable loopback pinentry to avoid extra pinentry dependencies by edit overlay/.gnupg/gpg.conf, add:

use-agent
pinentry-mode loopback

and edit overlay/.gnupg/gpg-agent.conf, add:

allow-loopback-pinentry

Then run genkernel with --luks, --gpg, and --initramfs-overlay=/path/to/overlay, I have something like:

genkernel initramfs --btrfs --luks --gpg --busybox --lvm --udev --no-compress-initramfs --initramfs-overlay=/root/genkernel/overlay

and finally ensure all required kernel parameters are set, like:

root=/dev/ram0 crypt_root=UUID=8c976243-4c5c-4dd9-8579-b569afedcd1c real_root=/dev/mapper/gentoo rootfstype=btrfs rootflags=subvol=gentoo/root root_keydev=UUID=8E18-232C root_key=gentoo.gpg init=/lib/systemd/systemd quiet

[vizv]

I followed most part of @sakaki- 's EFI guide (thanks!), however GnuPG v1 provided with staticgpg doesn't support OpenPGP card and I'd like to use a hardware token for LUKS key decryption

[2Belette]

@vizv : I am very interested to know if you ever been able to make @Sakaki Guide works with your Yubikey to unlock your LUKS partition ? is there anything else than your comment from Dec 11, 2019 needed ? In fact staticgpg is not supporting card so I think I have to tune & change some procedure from @Sakaki guide but I am a newbie at Gentoo and I am wondering if you'd be able to share with me what did you change to make it work with your Yubikey ?

Many thanks!