Add LUKS support

[devvythelopper]

Many people (and organisations) want (or require) full disk encryption (besides the fact that zfs when I last checked still had a bug that can corrupt the data that is transmitted via zfs send from encrypted snapshots). Please include something like https://github.com/agorgl/zbm-luks-unlock into the core zbm image.

[zdykstra]

There are no plans to add LUKS support to the default image. We provide tooling to build your own, and that repo provides documentation on how to use it.

[devvythelopper]

But that requires rebuilding the image for every release... Isn't the whole point of zbm a kind of plug and play with the ability to boot multiple distributions and snapshots?

Full disk encryption with LUKS2 containers is so basic a feature, that most laptop users and many desktop users simply use it. It is the default really for many users, while ZFS encryption will always be a niche product (the reason being its very design).

If LUKS was built into zbm, I for one would not have to build my own image at all, no tooling, no overhead, no time investment -- the default image would just do all that I need. My guess is, that this is a K.O. criterion for many. For me it is. Others might not write a feature request. Ease of use always wins out in the end. Its why Amazon or github for that matter are so successful.

And its such an easy thing to do, too -- for you. Besides what the repo already implements, one would only need to be able to specify other disks/partitions to decrypt via a zfs property/properties on the root dataset (for encrypted swap since ZFS does not support hibernation -- provided they use the same passphrase), and voila: ZBM could do it all out of the box.

[ahesford]

There's a lot of misunderstanding in your response. Let's clarify some things.

1. I don't know why you'd have to rebuild an image for every release. Even if you are building custom ZBM images, you should only ever rebuild them when ZFSBootMenu itself includes a new feature you want to use, or when you upgrade your pool to a ZFS version that ZBM either refuses to import or warns you that it can only import read-only. We actively discourage users from frequently rebuilding custom ZBM images. Needlessly tweaking a working bootloader is a recipe for inconvenience.
2. LUKS encryption may be commonly used or widely desired. However, there are myriad ways to accomplish ZFS atop LUKS volumes, and implementing them in ZFSBootMenu would either require we try to support a broad subset, or we form a strong opinion in favor of a particular approach. Neither is palatable. None of us use LUKS with ZBM, so we don't have strong opinions about how to do it. Trying to support the multitude of approaches is undesirable because it would involve a lot of sophistication that would tax our ability to reliably test the implementation and would expose complexity to the user in the form of additional configuration knobs.
3. We do not invest our time in this project to save you from investing your time to use it. ZFSBootMenu is developed as a tool that we enjoy using and maintaining. Users who find value in it are invited along for the ride, and we always welcome suggestions for improvement. However, we take those suggestions at our discretion.
4. We are not interested in becoming the next Amazon or GitHub. We are not interested in actively recruiting new users. If the userbase grows organically, let it grow.
5. You are unqualified to assess what would be easy for us to do until you have done the work yourself and understand the scope.

In my experience, every observation to the effect of "you just need to do [some trivial thing]" from users unwilling to knuckle down and implement requested features themselves should be dismissed with extreme prejudice. It means you haven't thought through the myriad edge cases that need to be considered in a project that seeks to provide reliable and flexible utility to a broad range of users.

Do not lobby further. We are uninterested.

[devvythelopper]

Thank you for the extended reply. Of course you are free to make the choice of investment of your time. I do not think I deserve the harsh wording, or the generalizations you throw at me. If you do not want to engage further with the topic please ignore the rest of my reply.

Since you attack me so harshly, I feel like I should expand on the scope and the reasons I have in mind for using the words I used.

ad 1. agreed.

ad 2. there is exactly one very common way of using LUKS encryption, implemented by the default installer GUI of the most widely used linux distributions (Debian derivates, Redhat, etc), and if I had to put a number on it my guess would be, that this is used by at least 90% of (laptop and desktop) users who use LUKS encryption at all. The common way is this: 1 or 2 encrypted LUKS2 containers, using the same encryption passphrase entered by the user manually on boot. 2 containers if SWAP is in a separate container and is not reencrypted on every boot. (Of course to the implementation it does not matter if its 2 or 10 containers). The contents of these containers is either partitioned or not. After decrypting both containers, a single call to partprobe, or a call to partprobe for all opened containers should suffice, if needed at all. Then all relevant zpools should be importable. After importing the root pool, the OS (fstab configuration, etc.) has to take care of the rest.
(And even if the user wanted a more complex LUKS based layout, they could implement this now within the configuration of the booting kernel/distribution in a way that is no longer related to what ZBM has to take care of. And if the user wants to enhance this with Smartcard/key on usb stick, then providing the more basic implementation makes it easier when they use your build tools).

ad 3. no disagreement here

ad 4. my argument is not aimed at the market share per se... It's just a personal preference I use within my own work: I want to provide value, and value is greatly increased by ease of use. That said I do know that ease of use is actually a big challenge and that creating complicated or quick and dirty and consequently hard to use software is much less time consuming. So I appreciate it if you do not want to do something time consuming... however

ad 5. I have in fact implemented the type of use case described above under multiple linux distributions manually [not the GUI way] (and I understand ZBM to be in fact a very minimal linux distribution). I have now (you could have asked instead of attacking me) described the scope I had in mind, and provided the reasons why I think no more than this is needed or reasonable on your part.

Personally I try to judge any request in the most positive light I can, and then maybe ask the person to provide more scope/reasons. In any case, there is no need to be dismissive or to assume that someone does not know what they are talking about, just because they call something simple. Or to assume that they are unreasonable, just because they request a feature that could be implemented in a very complicated way.

[zdykstra]

You're missing the point. I have no desire to add support for LUKS right now. Any arguments you present are moot. There's a solution out there that addresses the problem using features we explicitly created to make things of that nature easy to do.

Use it or don't, but do not call me lazy because I won't spend my time developing your pet feature.