blob: fcf5b21cf4773ebc98a6392e1f373aadc483a48c (plain
* the [[corresponding design document|contribute/design/incremental_upgrades]];
* the tickets with the _Incremental upgrades_ category on [[!tails_redmine "" desc="Redmine"]].
# 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
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
### 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.
### Surviving key compromise