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

Add support for GnuPG2 #454

Closed
wants to merge 26 commits into from
Closed

Add support for GnuPG2 #454

wants to merge 26 commits into from

Conversation

osresearch
Copy link
Collaborator

This is based on the patches by @duncanguthrie and @tlaurion to fix #435 and #296.

gpg2 and its various libraries adds 430KB to the initrd compared to gnupg1.4.21. This might be a concern for some of the smaller flash systems.

modules/npth Outdated Show resolved Hide resolved
modules/gpg2 Outdated Show resolved Hide resolved
modules/libksba Outdated Show resolved Hide resolved
Copy link
Collaborator

@tlaurion tlaurion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've pushed things further here: #435 (comment)

modules/gpg2 Outdated Show resolved Hide resolved
Copy link
Collaborator

@tlaurion tlaurion left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please review #435 (comment)

@osresearch
Copy link
Collaborator Author

With those library changes and enabling UNIX Domain Sockets with CONFIG_UNIX in the linux config to avoid the socket creation error, I'm able to startupgpg-agent and scdaemon. Generating keys with gpg --gen-key fails due to a missing pinentry program.

I'm trying gpg --gen-key --pinentry-mode loopback, but it is hanging forever while generating entropy, I think.

@osresearch
Copy link
Collaborator Author

Building pinentry-1.1.0 in tty mode works, although I'm not sure if it is currently hung waiting for entropy (on qemu) or if there is something else wrong.

@tlaurion
Copy link
Collaborator

tlaurion commented Sep 19, 2018

@osresearch : pinentry complains about curses.h missing.
pinentry-curses.c:25:20: fatal error: curses.h: No such file or directory

Edit: fixed below with --disable-fallback-curses

@druimalban
Copy link
Contributor

For the record, you don't need pinentry to be built with ncurses support. It can run in the tty on its own.

--host x86_64-linux-musl \
--prefix "/" \
--enable-pinentry-tty \
--disable-pinentry-curses \
Copy link
Collaborator

@tlaurion tlaurion Sep 19, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

        --disable-pinentry-qt5 \
        --disable-pinentry-fltk \
        --disable-pinentry-emacs \
+       --disable-fallback-curses \
        --with-libgpg-error-prefix="$(INSTALL)" \
        --with-libassuan-prefix="$(INSTALL)" \

@tlaurion tlaurion mentioned this pull request Sep 19, 2018
@tlaurion
Copy link
Collaborator

For the record, you don't need pinentry to be built with ncurses support. It can run in the tty on its own.

@duncanguthrie It was supposed to. It was just not respected :)
the --disable-fallback-curses wasn't either, until placed at the right place.

@duncanguthrie : have insight on this?

@jandryuk
Copy link
Contributor

jandryuk commented Oct 3, 2018

You might need to start gpg-agent with option --scdaemon-program /bin/scdaemon

image

@jandryuk
Copy link
Contributor

jandryuk commented Oct 4, 2018

gpg-agent looks in /libexec (${libexecdir}) for scdaemon, but Heads packages scdaemon into /bin. A workaround is to pass --libexecdir=/bin to gpg2_configure. The other option is to extend the Heads Makefile to put files into /libexec, but that is more involved.

I haven't gotten to actually testing this with my Nitrokey yet...

@tlaurion
Copy link
Collaborator

tlaurion commented Oct 5, 2018

@jandryuk : I've added a gpg-agent.conf that gives scdaemon's path.
gpg --card-edit now works on my Nitrokey Pro V2 :)

see #462

…lly work, tools and libs updated to latest versions
@tlaurion
Copy link
Collaborator

tlaurion commented Nov 29, 2018

@jandryuk : I've used gpg2 ang gpg1 only with gpg --card-edit to generate keys, and that works.

Trying to figure out what is wrong with pseudo-random generators. I'm testing on x230, not qemu, but can see that neither works with gpg --gen-key (osresearch/master gpg1 branch and osresearch/gpg2 branch, rebased on master).

It seems that there is not enough action on the host (recovery is doing nothing. May explain it) to generate enough entropy. Haven't had any feedback yet from u-root channel for gpg --gen-key having worked yet.

gpg1: gpg --gen-key complains about a lack of entropy and never gets enough (2 hours waiting)
gpg2: gpg --gen-keystays silent but shows the same absence of keys being generated.

@tlaurion
Copy link
Collaborator

I confirm, by running gpg --debug-all --gen-key that entropy is missing and filled if typing random keys on keyboard.

Since Heads relies on smartcards to sign configs, is gpg --key-gen missing entropy a false problem?
@osresearch @flammit ?

A couple of solutions could be taken into consideration if entropy generation in Heads is really a need ( I don't think so ).

@tlaurion
Copy link
Collaborator

tlaurion commented Nov 29, 2018

The only need I see would be to generate keys from Heads to keep an offline backup of master key, and insert subkeys in the smartcard for daily operations, like proposed, for example, in this guide.

So if this is required, rng-tools could be integrated inside of Heads with HW RANDOM support and a config option added. Look here for other options, out of which rng-tools is recommended.

@kyle @flammit, @osresearch: False need?

@jandryuk
Copy link
Contributor

@tlaurion Thanks for tracking down the problem! I am okay with leaving it as-is since it's due to the lack of entropy. I was more concerned there was still something broken with the gpg2 installation causing the hang.

initrd/init Outdated
@@ -5,6 +5,9 @@ echo "hello world" > /dev/ttyprintk
# Setup our path
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

#export GPG_TTY STATICALLY (NEED TO FIX)
export GPG_TTY=/dev/console
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
export GPG_TTY=/dev/console
export GPG_TTY=$(tty)

tty is installed, so it could be used here. tty returns /dev/console, so that doesn't change.

Copy link
Collaborator

@tlaurion tlaurion Nov 30, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: Will redo tests.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jandryuk : I've took that approach initially. Exiting to recovery shell consequently gives:

echo $GPG_TTY
not a tty

tty
/dev/console

init script doesn't have an access to a TTY.
This is why gpg command verifying signatures is gpg --no-tty, because from a whiptail perspective, it doesn't have access to a shell until ash is spawned. The reason why gpg signing works is because pinentry-tty is called for which requires the tty to be set, else it also fails.

I haven't found a more elegant solution then to hardcode the tty, force the paths to binaries in config and force gpg-agent usage. If you have a better solution, please advise. :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm pretty sure I used $(tty) for qemu's recovery shell and it worked. But that wasn't the whiptail stuff. Can you run the whiptail stuff under qemu?

Anyway, I don't have a better suggestion.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, your call to tty was before /dev/ was mounted. Setting GPG_TTY later works for me in QEMU. Check out this commit: jandryuk@ab8046b

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jandryuk if you want to test fbwhiptail/gui-init, see this branch: https://github.com/flammit/heads/tree/qemu-gui-init. Feel free to drop by u-root.slack.com / #heads channel if you wanna chat live (invite available from slack.u-root.com)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@flammit Oh, I forgot to thank you for the gui branch. Thanks!

gpg2 needs GPG_TTY set to function properly.  We set it in /init so it
is inherited by all children.  The call to $(tty) must be after /dev and
(preferably) /dev/pts are mounted.

Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
@tlaurion
Copy link
Collaborator

tlaurion commented Dec 3, 2018

@osresearch : please merge #491 here.

@flammit
Copy link
Collaborator

flammit commented Dec 10, 2018

@osresearch once #491 is in, this LGTM. Tested on x230 and qemu and tested repro on Ubuntu 16.04, Fedora Server 29, Fedora Workstation 29.

Note: you'll need to update your key files to only include the public key of the yubikeys, so the easiest way is to cbfs -o build/x230/coreboot.rom -a "heads/initrd/.gnupg/keys/pub.key" -f {your_pub_key.file}, then do a flash.sh -c coreboot.rom in Heads (which will ignore the initrd files you previously had in the rom).

@itay-grudev
Copy link
Contributor

itay-grudev commented Dec 30, 2018

Is this PR stable at the moment? I'd like to try it on the Librem 13 v3.

@tlaurion
Copy link
Collaborator

@itay-grudev : yes. You have to merge #491 on top of this one and you're good to go.

@itay-grudev
Copy link
Contributor

itay-grudev commented Jan 3, 2019

I have the following problem when I attempt to update my /boot signatures after switching to the gpg2 branch.

gpg: gpg-agent is not available in this session
gpg: Sorry, no terminal at all requested - can't get input
/boot: Unable to sign kexec hashes
Failed to sign default config

It ends with a kernel panic.

@itay-grudev
Copy link
Contributor

itay-grudev commented Jan 3, 2019

I also had a problem adding my GPG key. I ended up flashing to a non gpg2 ROM, adding it and then switching to gpg2. The key just wasn't being added.

@itay-grudev
Copy link
Contributor

gpg: Sorry, no terminal at all requested - can't get input

Fixed in #505.

@itay-grudev
Copy link
Contributor

itay-grudev commented Jan 3, 2019

After I switched to this branch and compiled this I noticed that gpg is still using version 1.x. And I am also the following error when I use a 4096 bit key:

gpg: BAD signature from key_id_here

Please advise.

@itay-grudev
Copy link
Contributor

The GPG2 flag wasn't set for the Librem platforms so GPG2 wasn't built. I added that in #505. Now I have another issue. Looks like libsecret is missing as a dependency.

Making all in pinentry
make[3]: Entering directory '/home/user/Projects/heads/build/pinentry-1.1.0/pinentry'
/home/user/Projects/heads/install/bin/musl-gcc -fdebug-prefix-map=/home/user/Projects/heads=heads -gno-record-gcc-switches -D__MUSL__  -DHAVE_CONFIG_H -I. -I..  -pthread -I/home/user/Projects/heads/install/usr/include/libsecret-1 -I/home/user/Projects/heads/install/usr/include/glib-2.0 -I/home/user/Projects/heads/install/usr/lib/x86_64-linux-gnu/glib-2.0/include -I//include -I//include  -I../secmem -Wall  -g -O2 -Wall -Wno-pointer-sign -Wpointer-arith -MT password-cache.o -MD -MP -MF .deps/password-cache.Tpo -c -o password-cache.o password-cache.c
password-cache.c:30:31: fatal error: libsecret/secret.h: No such file or directory
compilation terminated.
make[3]: *** [Makefile:417: password-cache.o] Error 1
make[3]: Leaving directory '/home/user/Projects/heads/build/pinentry-1.1.0/pinentry'
make[2]: *** [Makefile:465: all-recursive] Error 1
make[2]: Leaving directory '/home/user/Projects/heads/build/pinentry-1.1.0'
make[1]: *** [Makefile:405: all] Error 2
make[1]: Leaving directory '/home/user/Projects/heads/build/pinentry-1.1.0'
make: *** [Makefile:356: /home/user/Projects/heads/build/pinentry-1.1.0/.build] Error 1

@itay-grudev
Copy link
Contributor

Fixed in #505

@itay-grudev
Copy link
Contributor

With #505: Compiled successfully. GPG2 works fine. Signing works fine. Verification works fine. Tested on a Librem 13 v3 with a 4096 bit RSA key.

@tlaurion tlaurion mentioned this pull request Jan 17, 2019
@itay-grudev
Copy link
Contributor

@tlaurion CONFIG_GPG is no longer required for CONFIG_GPG2 builds, right?

@tlaurion
Copy link
Collaborator

tlaurion commented Jan 18, 2019

@tlaurion CONFIG_GPG is no longer required for CONFIG_GPG2 builds, right?

@itay-grudev Exact. CONFIG_GPG->CONFIG_GPG2 in board configs.

@tlaurion
Copy link
Collaborator

Please merge #510 instead.

@tlaurion tlaurion closed this Feb 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade GnuPG to 2.2.9
6 participants