
Ubuntu's Server Installer Leaked Encrypted Storage Passphrase to Its Log - RMPR
http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Subiquity-LVM-Pass-Bug
======
nemetroid
I believe this commit is the fix:

[https://github.com/CanonicalLtd/subiquity/commit/7db70650fea...](https://github.com/CanonicalLtd/subiquity/commit/7db70650feaf513d7fb6f1ca07f2d670a0890613)

I was a little surprised by how it did so just by adding a function, so I
looked briefly into how the serialization seems to work.

The FileSystemModel holds a numbers of actions, which it renders[0] into a
config for the Curtin program. Part of this process consists of converting
instances of various classes into dicts[1] (which presumably become JSON later
on). This config is written to various files in /var/log/installer/ during
setup.

The conversion into dicts is highly dynamic: it looks up all the fields of the
object to be converted, and for each field looks for a
"serialize_<field_name>" function on the object. If such a function is
present, it is used to serialize the field. If not, the field is typically
serialized using its literal value.

One such action class is DM_Crypt[2], which has a "key" field containing the
secret. With this commit, the serialize_key() function will be used to write
the key itself into a temporary file, and only store the location of the file
into the config.

0:
[https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf5...](https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf513d7fb6f1ca07f2d670a0890613/subiquity/models/filesystem.py#L1563)

1:
[https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf5...](https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf513d7fb6f1ca07f2d670a0890613/subiquity/models/filesystem.py#L376)

2:
[https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf5...](https://github.com/CanonicalLtd/subiquity/blob/7db70650feaf513d7fb6f1ca07f2d670a0890613/subiquity/models/filesystem.py#L1179)

~~~
rmrfstar
I'm not a crypto nerd or an os dev.

Is it _ever_ ok to let the key leave ram unencrypted? serialize_key() seems
like a recipe for doom.

