Summary: | >=app-crypt/gnupg-2.1.15 breaks /etc/init.d/dmcrypt in runlevel boot | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Felix Tiede <info> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | UNCONFIRMED --- | ||
Severity: | major | CC: | base-system, crypto+disabled, polynomial-c |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Adapt OpenRC dmcrypt init script to work with >=app-crypt/gnupg-2.1.15 |
Description
Felix Tiede
2016-10-18 08:12:29 UTC
(In reply to Felix Tiede from comment #0) > /usr/bin/gpg2 (and hence /usr/bin/gpg) requires its agent to be running to > be able to decrypt gpg-symmetrically encrypted LUKS keys. > As the rootfs is r/o while dmcrypt runs (system boot has not yet run fsck > and not remounted the root-fs read-write) all tries to decrypt a LUKS key > silently fail and mounting a LUKS-encrypted partition with a gpg-encrypted > secret fails with "Unable to run cryptsetup". Starting this early in the boot process I wonder if it wouldn't make more sense to have a copy of gnupg 1.4 in initramfs. GnuPG performs all secret-key operations in gpg-agent, ensuring amongst other thing proper process separation, and enables features such as socket forwarding. > > Rerunning /etc/init.d/dmcrypt later in the boot process or from commandline > does work clean, as at this point the root-fs is r/w and the agent can start > and create its socket. But this renders automounting (and automated fsck > runs) useless and not-working. > > For me this is a major issue, as all /home on my systems are LUKS-encrypted > with gpg-encrypted secrets. if you have /run/user/$UID created gnupg 2.1.15 will create a socket in /run/user/$UID/gnupg instead of the homedir (In reply to Kristian Fiskerstrand from comment #1) > GnuPG performs all secret-key operations in gpg-agent, ensuring amongst This should be GnuPG 2.1 (In reply to Kristian Fiskerstrand from comment #1) > if you have /run/user/$UID created gnupg 2.1.15 will create a socket in > /run/user/$UID/gnupg instead of the homedir Unfortunately only if the agent is started manually before running gpg itself. /usr/bin/gpg2 does not perform this magic on its own. At least not in app-crypt/gnupg-2.1.15. This means that /etc/init.d/dmcrypt needs to check gpg-version (works without agent), create the directory, start the agent, perform unlocking operations (which might have also worked w/o all those steps) and then retrace its steps to leave a clean system. I've already confirmed with upstream that this is intended behavior and running gpg with an unwritable $GNUPGHOME is in fact unsupported. Its unclear if this applies only to encryption, decryption or both. Decryption of symmetric encrypted files does indeed work with an unwritable $GNUPGHOME, yet it might really be unsupported. (In reply to Felix Tiede from comment #3) > (In reply to Kristian Fiskerstrand from comment #1) > > if you have /run/user/$UID created gnupg 2.1.15 will create a socket in > > /run/user/$UID/gnupg instead of the homedir > > Unfortunately only if the agent is started manually before running gpg > itself. > /usr/bin/gpg2 does not perform this magic on its own. At least not in > app-crypt/gnupg-2.1.15. Its easier if you come to #gentoo-crypto on IRC Freenode to debug things, but gpg auto-start the agent and first checks /run/user/$UID in 2.1.15 (but it is only created there if /run/user/$UID/ is created at the time. You can also force this by using gpgconf --create-socketdir > > This means that /etc/init.d/dmcrypt needs to check gpg-version (works > without agent), create the directory, start the agent, perform unlocking > operations (which might have also worked w/o all those steps) and then > retrace its steps to leave a clean system. > > I've already confirmed with upstream that this is intended behavior and > running gpg with an unwritable $GNUPGHOME is in fact unsupported. Its > unclear if this applies only to encryption, decryption or both. Decryption > of symmetric encrypted files does indeed work with an unwritable $GNUPGHOME, > yet it might really be unsupported. the limitation would be more related to trustdb calculation and key storage/management and not actual cryptographic operations. Please reopen if applicable despite the discussions Created attachment 460688 [details, diff]
Adapt OpenRC dmcrypt init script to work with >=app-crypt/gnupg-2.1.15
I've adapted my local dmcrypt init script which does now work with gnupg-2.1.15 and exhibits the same behavior as it did with gnupg-2.0.28.
It manually creates /run/user/0 and removes the directory as well as /run/user if that didn't already exist at the time of dmcrypt start being called.
It's quick and dirty, it works for me, so it should be checked to meet quality criteria.
(In reply to Kristian Fiskerstrand from comment #5) > Please reopen if applicable despite the discussions Reopened as requested with patch proposal. |