Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GnuPG v2 support in initramfs for LUKS PGP keys. #33

Open
viewizard opened this issue May 24, 2016 · 10 comments
Open

GnuPG v2 support in initramfs for LUKS PGP keys. #33

viewizard opened this issue May 24, 2016 · 10 comments

Comments

@viewizard
Copy link

viewizard commented May 24, 2016

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-
Copy link
Contributor

sakaki- commented May 25, 2016

+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
Copy link
Member

mudler commented May 25, 2016

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
Copy link
Author

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
Copy link
Member

mudler commented May 25, 2016

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
Copy link
Author

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.
  1. 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
Copy link
Author

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
Copy link

ghost commented May 31, 2017

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
Copy link

vizv commented Dec 11, 2019

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
Copy link

vizv commented Dec 11, 2019

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
Copy link

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants