Include cryptsetup in containerized builds

[gorbak25]

When building zfsbootmenu using the default build container it's not possible to include the crypt dracut module or the encrypt mkinitcpio hook.
The default build container should install cryptsetup for those modules/hooks to work. Including those modules/hooks is required for the contrib/luks-unlock.sh script to work.

[zdykstra]

This will result in both the crypt and dm Dracut modules being added into all release and recovery builds, in addition to anything built locally with the image. At the minimum release builds need to have crypt and dm modules blacklisted. We'll possibly want to address this in some other fashion, though.

[zdykstra]

Oops, looks like both of those modules are already blacklisted in release and recovery builds. However, we'll still want to address how they should be handled by regular builds as well. Those modules are quite slow and having them in user images by default isn't optimal.

[gorbak25]

Let's first ensure that we're on the same page about the recovery build. From what I understand that build is meant to be an all-inclusive rescue environment which should support most storage setups out of the box. The lack of luks support is generally a problem(imagine decrypting an encrypted usb stick/hard drive etc...). On the other hand when supporting everything under the sun that build might become extremely bulky. Where should be the cutoff point of "the build is good enough"(cryptsetup? tpm? tmp2? gpg? wpa_supplicant?).

I think that crypt, dm and rootfs-block should be blacklisted in all builds besides the recovery one while providing documentation stating that those modules might be safely removed from the blacklist(and stating that systemd modules are not supported and should never be removed from the blacklist). I might try to provide a writeup in the documentation stating how to get zfsbootmenu to work with luks FDE(which is currently my setup, the build I'm using is here).

The options I see right now:

1. Provide cryptsetup in the build image but blacklist crypt, dm and rootfs-block in all builds
2. Include a build flag in config.yaml which includes cryptsetup in the release image, otherwise it blacklists crypto modules

Are there options I'm missing?

[zdykstra]

Let's first ensure that we're on the same page about the recovery build. From what I understand that build is meant to be an all-inclusive rescue environment which should support most storage setups out of the box. The lack of luks support is generally a problem(imagine decrypting an encrypted usb stick/hard drive etc...). On the other hand when supporting everything under the sun that build might become extremely bulky. Where should be the cutoff point of "the build is good enough"(cryptsetup? tpm? tmp2? gpg? wpa_supplicant?).

Recovery builds are a pretty new thing, so they're a bit nebulous. However, I don't have any real objection to cryptsetup being made available in both the builder image/container, and the recovery image.

I think that crypt, dm and rootfs-block should be blacklisted in all builds besides the recovery one while providing documentation stating that those modules might be safely removed from the blacklist(and stating that systemd modules are not supported and should never be removed from the blacklist). I might try to provide a writeup in the documentation stating how to get zfsbootmenu to work with luks FDE(which is currently my setup, the build I'm using is here).

The options I see right now:

1. Provide cryptsetup in the build image but blacklist crypt, dm and rootfs-block in all builds
2. Include a build flag in config.yaml which includes cryptsetup in the release image, otherwise it blacklists crypto modules

Are there options I'm missing?

The first option is what I've generally settled on. It'll be the closest match to existing behavior from the myriad ways to build ZBM. That also will allow us to reduce the number of different places Dracut modules have to be blacklisted, centralizing a few core blacklisted items in zfsbootmenu.conf.

Adding in @ahesford so that he can weigh in on what he'd like to see here.

[ahesford]

Adding cryptsetup to the recovery image is fine, if that is sufficient to stand up (manually) a LUKS volume and perform some recovery operations in ZBM.

Because we officially recommend native encryption, I don't want to get bogged down trying to make either the recovery or release builds capable of automatically loading pools on LUKS volumes. The purpose of the release image is to provide the greatest common divisor for widespread support; the purpose of the recovery image is to provide a cache of tools that might not be convenient to use, but are at least available in times of desperation.

I'm content to tell people that automatic support for LUKS requires a locally built, custom ZBM image.

The contrib script to perform unlocking with keys in LUKS was intended as a demonstration that should be customized for individual use. We're happy to merge improvements to that script based on feedback from those who actually use it (neither zdykstra nor I have LUKS setups), but we do not intend to provide guarantees that the script is functional or easy to use.