Jump to: navigation, search

Dev/Automatic Updates

< Dev

Automatic Updates[edit]

One click upgrade button for Debian packages[edit]

Automation is very difficult due to issues introduced at a higher level (Debian and The Tor Project).

apt-get isn't good at conflict resolution with config files (the user may have installed arbitrary packages, changed their configs and then upstream may have updated the config file. dpkg will ask if the user wants to take the new or the old config file. Also other things can go wrong, such as problems with gpg verification, package lists, which are no longer valid-until, general brokenness due to aborts during last action and so forth. Others dedicated projects have failed at simplification of apt-get, such as synaptic, apper[1], packagekit and software center. All failed at implementing this for everyone in all cases. When separate projects failed as a higher level (Linux distributions aren't user friendly themselves in the first place), there is nothing that be could fixed in Whonix at a lower level.

Unattended upgrades in background for Debian packages[edit]

Reasons for Automatic Updates:

  • Better usability.

Reasons against Automatic Updates:

  • Apparently mysterious [2] system load.
  • Apparently mysterious [2] network load.
  • Some people may be on different kinds of internet connections. Sometimes they may use a connection with unlimited quota and want to postpone updating.
  • If Debian's update mechanism ever gets compromised [3], then it would make sense for users to read Whonix News before manually updating.
  • Old discussion
  • If the user is using Debian a host operating system or connecting to the same mirror,

DoNot#Do_not_connect_to_any_server_anonymously_and_non-anonymously_at_the_same_time.21 applies. (Since using stream isolation, in worst case, as far as I can see, the server only knows what packages you wanted to download, if that happens.)

Needs Research:

  • What happens when a stale mirror is detected? Will the user be informed?
  • Stale mirror attack not of concern, since exit relays change anyway?
  • Are times when "apt-get update" is run randomized to prevent a clear network fingerprint? If not, this needs a custom implementation/diverting some scripts.
  • Are times when "apt-get dist-upgrade" is run randomized to prevent a clear network fingerprint? If not, this needs a custom implementation/diverting some scripts.
  • What are the reasons why distributions such as Debian/Ubuntu/Qubes OS are not using automatic updates by default?


Forum discussion:

Auto Upgrading Tor Browser[edit]

For the Tor Browser version check is unreliable. Sometimes upstream messed up versions, uploads faulty version files or changes the version format. There is no way for a machine[4] to determine if a new version has been released. And due to other issues (not beating the TUF threat model), the torbrowser downloader shouldn't blindly trust what the version check claims is the most recent version. Therefore the user still has to check if it's sane. Could be very well a downgrade attack at some point. If this was a text editor like application for some company who value usability more than security, I would have automated it already, but in case of Whonix that would be too insecure for my taste.

Update Notifier / GUI Updater[edit]

Rejects ideas[edit]

apper (kde) package[edit]

whonixcheck runs apt-get update. Checks if there are updates with /usr/lib/update-notifier/apt-check. If there are updates, it opens apper --updates, if installed. (Otherwise notifies about updates only in whonixcheck result.)

Apper is user friendly since there is only one big update button and does also honor proxy settings in /etc/apt/apt.conf which are required for Tor stream isolation.

Automatic update check has been disabled in /etc/apt/apt.conf.d/10periodic because the execution time would be too predictable. Whonixcheck runs at startup (non-predictable) and every day at a random time.

Apper / Synaptic subject for removal for Whonix 8, see: https://github.com/Whonix/Whonix/issues/104

Too many bugs, too confusing:

update-notifier (gnome) package[edit]

Overall ui is very good. Asks a confusing question to update "safely" and not removing packages. After updating "safely" it still reports updates. Open question: how to provide update-notifer in several languages? Would be all gnome language packages needed?

Would have to configure it with something like "gconftool-2 --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory". Would have to

cp /etc/xdg/autostart/update-notifier.desktop /etc/xdg/autostart/update.desktop

And remove shownotin kde from /etc/xdg/autostart/update.desktop.

update-notifier-kde package[edit]

Is a bit confusing. It shows how many updates are available, but it has only one button "later".


As long there are no tools which can handle always all cases for all users, it's the best of the worse choices to teach users how to update using the CLI tools. Those always work reliably.


  1. Bugs such as apper recommends restarting while apt-get (command line) is still working.
  2. 2.0 2.1 to those who don't know that automatic updates are enabled by default; would result in questions such as this: Special:AWCforum/st/id178/Weird_traffic_display_in_arm.html
  3. If a malicious package was uploaded to Debian's APT repository or if there was a critical bug in apt-get.
  4. script

Log in | OpenID | Contact | Impressum | Datenschutz | Haftungsausschluss

https | .onion [note] | Mirror | Mirror

This is a wiki. Want to improve this page? See Conditions for Contributions to Whonix, then Edit it! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.

Whonix (g+) is a licensee of the Open Invention Network. Unless otherwise noted above, content of this page is copyrighted and licensed under the same Free (as in speech) license as Whonix itself.