Bug#903163: Adding OpenPGP smartcard support to LUKS
Hi Jonas et al., > I don't think that adding a new binary package for OpenPGP smartcard > support is a good idea and would oppose to it Might smartcard support require some smartcard-specific packaged dependencies that would be solved somewhat elegantly by having a separate binary package? (Just to clarify, do you mean a new binary package as part of src:cryptsetup or a new binary package as part of some other hypothetical source package?) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#903163: Adding OpenPGP smartcard support to LUKS
Hi Guilhem and Chris, greetings from Portugal to Taiwan :) Am 16.07.2018 um 19:28 schrieb Guilhem Moulin: > I'm in favor of adding OpenPGP smartcard support to src:cryptsetup, but > not more that one set of hook & boot scripts. Ack. > 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. Ack. > 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.) I don't think that adding a new binary package for OpenPGP smartcard support is a good idea and would oppose to it. If we followed that logic (e.g. in order to allow more fine-grained dependencies), we'd have to split other keyscripts into own binary packages as well. Also, given the limited scope of keyscripts these days[1], I don't think that's worth the effort and to much overhead. Cheers, jonas [1] The systemd cryptsetup helper implementation doesn't support keyscripts and upstream refuses to implement support for it. So we're left with keyscripts support in the initramfs and the SysVinit init scripts. signature.asc Description: OpenPGP digital signature
Bug#903163: Adding OpenPGP smartcard support to LUKS
On Mon, 16 Jul 2018 at 18:39:59 +0100, Chris Lamb wrote: > So, whilst I will be at DebCamp too (yay) I unfortunately won't have > any hardware to test with and for various reasons I should keep > commitments low at this point. Sure thing! I was planning to do some triaging anyway :-) (#888916 has been open for a while already and it's unfortunate that we didn't find time to provide any follow-up yet.) > (Can we get something into shape on a branch for Kyle to test, or are > the bug references you cite above enough?) AFAIK we don't have anything to show other than the two bugs and the link to the respective repositories, but hopefully we'll have something after DebCamp. I'll poke you once this is the case! :-) -- Guilhem. signature.asc Description: PGP signature
Bug#903163: Adding OpenPGP smartcard support to LUKS
Dear Guilhem, > > My gut tells me we should incoropate OpenPGP support directly into > > I assume you mean OpenPGP *smartcard* here Yes, mea culpa; wasn't paying attention! :) > 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. Of course and I totally agree with this and your following paragraphs. So, whilst I will be at DebCamp too (yay) I unfortunately won't have any hardware to test with and for various reasons I should keep commitments low at this point. (Can we get something into shape on a branch for Kyle to test, or are the bug references you cite above enough?) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
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. signature.asc Description: PGP signature
Bug#903163: Adding OpenPGP smartcard support to LUKS
Dear Guilhem, > 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 Debian's src:cryptsetup simply based on ensuring its on-going maintainability, etc. Especially important given that, for example, an API change or other breakage might result in an unbootable system. 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? :) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#903163: Adding OpenPGP smartcard support to LUKS
On Mon, 09 Jul 2018 at 10:14:50 -0700, Kyle Rankin wrote: > Given it is just a shell script, I would vote for incorporating OpenPGP > smartcard support directly into cryptsetup-initramfs so it's available for > users who want encrypted storage without having to know about a standalone > package. With my cryptsetup maintainer hat on, I don't mind either way. In any case we shouldn't ship multiple hooks providing essentially the same functionalities (#888916, #903163). I have a Gnuk Token so I should be able to test and maintain this :-) In general, rather than using our internal interface, authors of third party hooks should either 1/ ask us to document and publish the bits they need, or 2/ convince us to incorporate their hook & script into cryptsetup-initramfs, effectively making us maintainers. Back to https://github.com/eriknellessen/gpg-encrypted-root, I see the hook is copying private key material to the initramfs, but /initrd.img is just a cpio archive which is created with mode 0644 minus umask… so without additional protection in place [0] (which the README doesn't mention) any local user can read the (hopefully symmetrically encrypted) private key material! It's not clear to me why they need the private key files, but at the very least a loud warning should be shown if the umask is too permissive. -- Guilhem. [0] For instance setting UMASK=0077 in /etc/initramfs-tools/initramfs.conf. signature.asc Description: PGP signature
Bug#903163: Adding OpenPGP smartcard support to LUKS
Given it is just a shell script, I would vote for incorporating OpenPGP smartcard support directly into cryptsetup-initramfs so it's available for users who want encrypted storage without having to know about a standalone package. -Kyle
