Merge ~vorlon/ubiquity:lp.1857398 into ubiquity:master

[Steve Langasek]

[Dimitri John Ledkov (xnox)]

Stock passwords are banned in the State of California, thus we should use a unique passphrase generator. [1]

It should be stored on the boot-volume, and included in the initrd for automatic unlocking. Until user chooses a new one.

Does resetting the passphrase re-encrypt the volume with a new master key? If not, we should do that somehow.

[1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=201720180SB327

[Steve Langasek (vorlon)]

> Stock passwords are banned in the State of California, thus we should use a
> unique passphrase generator. [1]

> [1] https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=2017
> 20180SB327

Reading the text of this law, this applies only to passwords set by the manufacturer of a network-connected device, used for accessing the device over the network. So this applies neither to Ubuntu as a product (because it's not a device), nor to disk encryption passwords as a feature (because the password does not grant remote access to the device).

> It should be stored on the boot-volume, and included in the initrd for
> automatic unlocking. Until user chooses a new one.

The downside of this approach is that it makes the user's data more fragile in the face of data loss (due to hardware failure or user action) that impacts the boot pool. Given that the user doesn't necessarily even know that their root pool *is* encrypted, this is a potential time bomb. I think the added resilience of a default well-known passphrase is important.

> Does resetting the passphrase re-encrypt the volume with a new master key? If
> not, we should do that somehow.

I don't know if it does or doesn't. I agree this is desirable. But that wouldn't be part of the ubiquity side of things.

[Didier Roche-Tolomelli (didrocks)]

I have only one comment based on Richard's feedback. The rest is on the bug itself.
I agree that generating and setting the fix passphrase on the bpool will be more fragile, especially as the implementation detail will be unknown to the user who might reformat only part of his disk.
Overall, looks good to me and good catch for future compatibility!

review: Needs Information

[Dimitri John Ledkov (xnox)]

I believe we now have alternative ways of setting up hybrid luks+zfs encryption to use native zfs encryption, yet also support LUKS keyslots.

review: Disapprove

Unmerged commits

d399d8e... by Steve Langasek on 2019-12-24

scripts/zsys-setup: encrypt by default since it's not possible to add encryption to a pool post-installation. LP: #1857398

diff --git a/debian/changelog b/debian/changelog
index 9fdb914..6d9cdae 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ubiquity (20.04.5) UNRELEASED; urgency=medium
+
+  * scripts/zsys-setup: encrypt by default since it's not possible to add
+    encryption to a pool post-installation.  LP: #1857398
+
+ -- Steve Langasek <[e-mail]>  Mon, 23 Dec 2019 17:37:00 -0600
+
 ubiquity (20.04.4) focal; urgency=medium
 
   * When removing packages, also remove automatically installed packages that
diff --git a/scripts/zsys-setup b/scripts/zsys-setup
index fcd0a49..e4d17b9 100755
--- a/scripts/zsys-setup
+++ b/scripts/zsys-setup
@@ -289,6 +289,7 @@ init_zfs() {
 
 	# Pools
 	# rpool
+	echo -n ubuntuzfs > /run/zfs-root-default
 	zpool create -f \
 		-o ashift=12 \
 		-O compression=lz4 \
@@ -300,6 +301,9 @@ init_zfs() {
 		-O canmount=off \
 		-O dnodesize=auto \
 		-O sync=disabled \
+		-O encryption=on \
+		-O keylocation=file:///run/zfs-root-default \
+		-O keyformat=passphrase \
 		-O mountpoint=/ -R "${target}" rpool "${partrpool}"
 
 	# bpool