intrigeriSee also:
- the corresponding design document;
- the tickets with the C: Upgrader label on GitLab.
Random ideas for future improvements
These are not worth creating tickets yet, as it's not even clear these changes are useful enough to put time in it.
Packaging could be more self-contained
Move /etc/sudoers.d/zzz_upgrade and IUK-related user creation from
the Tails main Git repository to the tails-iuk Debian package, so
that it's more self-contained and easier to test.
Button for aborting upgrade cleanly
Compute and display ETA
Multi-step incremental upgrade
E.g. 0.11 boots after 0.11.1 and 0.11.2 are out. Tails fetches https://tails.boum.org/upgrade/v1/Tails/0.11/i386/stable/upgrades.yml, that shall contain an incremental upgrade path with two target files: the 0.11 to 0.11.1 IUK, and the 0.11.1 to 0.11.2 IUK. The upgrader would download these two files and install the two IUKs in the correct order.
sharing upgrade material
Once the incremental upgrade has been applied, I may be proposed to save a copy of the target files to a location of my choosing.
allow one to download target files in the clear
The downloader program could provide an opt-in way to have the
download happen in the clear, that is without going through the Tor
network. It looks doable given it's a separate process: we may run it
as a dedicated user, and reuse the clearnet infrastructure
implemented for the Unsafe Browser.
"Retry with new circuit" button
Circuit throughput varies wildly, and since this is a large download, it'll quickly wear out users' patience if a bad circuit is picked. Or maybe this can happen behind the scenes, e.g.: Automatically switch circuit every X minutes or Y% progress? That could even make fingerprinting the download on the Tor client <-> Entry Node side of the pipe a bit more difficult, for whatever that's worth.