Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-25 Thread Peter Lebbing
On 25/09/2018 02:10, Guilhem Moulin wrote: > Then shouldn't the following be enough, and > save a temporary file? > > `| gpg --no-default-keyring --keyring … --trust-model=always --import` I thought so but was wrong. Without relocating trustdb.gpg to somewhere else, it will lose all

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

2018-09-24 Thread Guilhem Moulin
On Mon, 24 Sep 2018 at 14:11:02 +0200, Peter Lebbing wrote: > Well, the ultimate fail-safe migration mechanism is very > straight-forward. Export to /etc/cryptsetup-initramfs/pubkey.gpg, and in > the decrypt script, --import that first. I see you already use a > default, empty homedir anyway,

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-24 Thread Peter Lebbing
On 24/09/2018 11:42, Guilhem Moulin wrote: > Sure, me too :-) But I'm afraid of ending up in a situation similar to > caff(1)'s, where in order to avoid maintaining two sets of conf files > some users end up symlinking them (or blindly copying them). I hadn't > thought of scdaemon.conf, but at

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-24 Thread Guilhem Moulin
On Sun, 23 Sep 2018 at 17:59:20 +0200, Peter Lebbing wrote: >> 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

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-23 Thread 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

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-23 Thread Guilhem Moulin
On Sun, 23 Sep 2018 at 16:00:30 +0200, Peter Lebbing wrote: > I'm not really happy with the "wait for a random smartcard to be > available and import that as stubs" solution, Note that in principle we can wait for a smartcard with a given serial number to be inserted, with `gpg-connect-agent 'SCD

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-23 Thread Guilhem Moulin
Hi, On Sun, 23 Sep 2018 at 13:32:44 +0200, Peter Lebbing wrote: > --8<---cut here---start->8--- > #!/bin/sh > > UNSAFEKEYS=$(gpg --batch --with-colons --homedir /etc/keys --list-secret-keys > | \ > gawk -F: '$1=="sec" || $1=="ssb" \ > { if

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-23 Thread Peter Lebbing
On 23/09/2018 13:32, Peter Lebbing wrote: > How about copying the whole homedir without > random_seed, but first checking to make sure there are only smartcard > keys as private keys? O dear, this might not be enough. The agent can also hold non-OpenPGP keys. SSH keys are an example of what I'm

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-23 Thread Peter Lebbing
On 23/09/2018 13:32, Peter Lebbing wrote: > How about copying the whole homedir without random_seed, but first > checking to make sure there are only smartcard keys as private keys? However, we should specifically exclude openpgp-revocs.d as well. The whole "is the homedir an API or

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-23 Thread Peter Lebbing
On 23/09/2018 05:58, Guilhem Moulin wrote: > Agreed, and implemented :-) This is awesome! :-) Peter. -- 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

Bug#903163: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

2018-09-23 Thread Peter Lebbing
Hi Guilhem! On 23/09/2018 05:57, Guilhem Moulin wrote: > We already have some logic in place to wait until the source device is > present, so we can as well wait until the card is present. Note that GnuPG now supports multiple card readers at the same time. The solution will fail then.