Thanks Richard for digging in, the performance comparison and the valuable 
upstream feedback and pointers.
Good catch about retrieving the master key written in old blocks with the 
previous (fix) passphrase even if changed later on. It seems that trimming 
could help. Do you think that we should base on work going that direction 
(overwriting old keys) and keep the current approach?

On a more general side, the approach seems to be forward-compatible with
per user dataset encryption (zfs change-key <dataset>), which creates a
new encryption root.

Steve:
* the only comment I have on the ubiquity part of the equation is based on 
Richard's feedback. Otherwise, looks good to me. I think we should wait on the 
above feedback before taking a finale decision on the approach though.
* the zfs-linux initramfs POC looks good (not tested though, currently 
travelling, but I didn't spot any issues). It should be easily pluggable later 
on once the user set it to "prompt" with their own passphrase and use the 
plymouth prompt codepath. (Not tested yet either).
Just a nitpick: Colin asked for our patches in zfs-linux to be numbered (hence 
the 4XXX- namespace), as the debian ones. It seems that it's not reliably the 
case since the 0.8.2 merge with debian, so need double checking (order seems as 
well messy after this merge right now).

Anyway, we need to wait on the kernel patches first.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1857398

Title:
  ubiquity should support encryption by default with zfsroot, with users
  able to opt in to running change-key after install

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1857398/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to