Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
B
blueprints
  • Project overview
    • Project overview
    • Details
    • Activity
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
Collapse sidebar
  • tails
  • blueprints
  • Wiki
  • incremental_upgrades

Last edited by intrigeri Jan 12, 2021
Page history

incremental_upgrades

  • Random ideas for future improvements
    • Packaging could be more self-contained
    • Button for aborting upgrade cleanly
    • Compute and display ETA
    • Multi-step incremental upgrade
    • sharing upgrade material
    • allow one to download target files in the clear
    • "Retry with new circuit" button
    • Surviving key compromise

See 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.

tails#7878

"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

  • https://wiki.ubuntu.com/ImageBasedUpgrades/GPG
Clone repository
  • Home
  • Monthly reports
  • Sandbox