[FFe] Add support for recovery key in mantic

Bug #2033537 reported by Olivier Gayot
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
curtin
Fix Released
Undecided
Unassigned
subiquity
Fix Released
Undecided
Unassigned

Bug Description

Request
-------
* Add support in Subiquity for setting up a LUKS recovery key.

Why Needed
----------
* We committed to add support for adding a recovery key in mantic. It is also important so that the desktop installer can make use of the new API as early as possible.

What Changed
------------
* A new endpoint GET /storage/generate_recovery_key was added to Subiquity server. It returns a 48 decimal digits key - suitable for LUKS encryption. This will be needed for the desktop installer if they want a button to generate a key.
* Autoinstalls using guided LVM or manual partitioning can now generate a recovery-key and back it up in the target system. By default, no recovery key is used - which mimics the previous behavior.
* The UI also has a new checkbox in guided and manual partitioning. The checkbox controls whether a recovery key is generated (it does not allow the user to see or modify it) and it only enabled if encryption is being used.
* When a recovery key is generated, it is exposed in the live system under the home directory of the user that runs the subiquity client (except for autoinstalls). At the end of the installation, the recovery key gets copied to /var/log/installer in the target system (usually under /target).
* The /storage API has been updated to support the recovery_key property.

Code to be merged
-----------------
* curtin change: https://code.launchpad.net/~ogayot/curtin/+git/curtin/+merge/437897
* subiquity change: https://github.com/canonical/subiquity/pull/1766

Other testing
-------------
* A green, full installation was performed using Subiquity on the upstream/main branch with the changes mentioned above.
* Unit tests have been added to Subiquity and curtin to cover the recovery key use-case.

Other info
----------
* there is no need to do a new upload of curtin in the archive for subiquity to use the new options. A snap build of subiquity pulls curtin from the upstream git repository (at a specific revision) and not from the archive. This means there is no immediate risk of regression for packages that depend on curtin from the archive.

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Thank you for the detailed explanation of the changes in both subiquity and curtin for this. As said, such paper trail, even for snaps, is of great importance in case we need to identify regressions.
Anyway, +1 on this FFe. Please proceed.

Changed in subiquity:
status: New → Triaged
Changed in curtin:
status: New → Triaged
Olivier Gayot (ogayot)
Changed in curtin:
status: Triaged → Fix Committed
Changed in subiquity:
status: Triaged → Fix Committed
Olivier Gayot (ogayot)
Changed in curtin:
status: Fix Committed → Fix Released
Changed in subiquity:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.