- 1 Automatic Updates
- 2 Update Notifier / GUI Updater
- 3 Footnotes
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 , 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., 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
Unattended upgrades in background for Debian packages
Reasons for Automatic Updates:
- Better usability.
Reasons against Automatic Updates:
- Apparently mysterious  system load.
- Apparently mysterious  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 , 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.)
- 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?
- The Tor Project did not ask us, not to download updates over Tor, see FAQ: You should not waste the Tor network's bandwith by downloading operating system updates over Tor!
Auto Upgrading Tor Browser
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 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
apper (kde) package
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
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.
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.
- Bugs such as apper recommends restarting while apt-get (command line) is still working.
- 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
- If a malicious package was uploaded to Debian's APT repository or if there was a critical bug in apt-get.
Log in | OpenID | Contact | Impressum | Datenschutz | Haftungsausschluss