[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#903163: Adding OpenPGP smartcard support to LUKS



Hi Chris,

On Mon, 16 Jul 2018 at 10:15:47 +0100, Chris Lamb wrote:
>> Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the
>> hook is copying private key material to the initramfs, but […]
> 
> My gut tells me we should incoropate OpenPGP support directly into

I assume you mean OpenPGP *smartcard* here: symmetric OpenPGP encryption
is supported 2:1.0.3-3 released 12 years ago (and that's the hook and
boot scripts which Peter then Erik forked) :-)

> Does that work for you in principle Guilhem? I'm assuming we can
> "just" merge in the aforementioned package (!) and fix up some of the
> issues, including the umask one you already outlined.
> 
> What would be the next steps here? :)

I'm in favor of adding OpenPGP smartcard support to src:cryptsetup, but
not more that one set of hook & boot scripts.

Since there is already #888916 open requesting merging of some initramfs
scripts providing OpenPGP smartcard support, and 888916 < 903163, it'd
polite of us cryptsetup package maintainers to review Rian's code as
well before including anything.

We've been quite busy lately with the massive refactoring and the couple
of regressions that followed, but I hope to take a closer look at both
proposals during DebCamp next week.  Naturally, help is welcome :-)

I'm not sure it's worth shipping another “Architecture: all” binary
package to src:cryptsetup, though (as opposed to including the keyscript
to cryptsetup-run and the initramfs bits to cryptsetup-initramfs, like
we're doing for decrypt_gnupg, decrypt_keyctl, decrypt_opensc, etc.).
Sure, splitting cryptsetup-run and cryptsetup-initramfs further means we
can assign more fine-grained dependencies, but in the end it'll just be
a tiny shell script in each package, so is it worth the effort?  Also
`update-initramfs -u` will complain if the required binaries (pcsd, gpg,
etc.) cannot be copied; and the user has to install these to be able to
set up the mapping in the first place.

(If we add another “Architecture: all” binary package we should also
split cryptsetup-run and cryptsetup-initramfs for the sake of
consistency.  Not sure it's worth the effort, but now-ish would be a
good time to do this since we've already split cryptsetup-initramfs
away.  I personally don't have strong feelings either way; CC'ing Jonas
who might have a different opinion.)

Cheers,
-- 
Guilhem.

Attachment: signature.asc
Description: PGP signature


Reply to: