- 1 Introduction
- 2 Simplified Assisted Updates
- 3 Automatic Updates
- 4 Update Notifier / GUI Updater
- 5 Conclusion
- 6 Footnotes
apt-get upstream bugs
- apt: Provide meaningful exit codes for gpg failures
- provide meaningful exit codes for network failures
- audit 'apt-get update' exit codes
Security Issues when using apt-get update in Scripts
The issue is, that apt-get does not provide meaningful exit codes for gpg and network failures. "Not meaningful" here means, that `apt-get update` exits `0`, even if it failed. This makes it hard to figure out in scripts if `apt-get update` actually succeeded loading repository metadata or failed.
The threat model here is using multiple repositories. Such as Debian's main repository as well as Debian's security repository. For consistent and secure builds, both have to be enabled. Now, an adversary could make fetching the Debian main repository succeed, but simulate a gpg or network failure for the Debian security repository. Then the build would go on only with the Debian main repository, without the Debian security repository.
In other words... Here is a practical example...
Consider the following sources.list which is fine.
deb http://security.debian.org wheezy/updates main contrib non-free deb http://ftp.us.debian.org/debian wheezy main contrib non-free
Consider the following sources.list which is fine which contains an intentional typo for demonstration purposes.
deb http://not-security.debian.org wheezy/updates main contrib non-free deb http://ftp.us.debian.org/debian wheezy main contrib non-free
Now, when you run...
sudo apt-get update ; echo $?
The output shows.
Err http://not-security.debian.org wheezy/updates Release.gpg Could not resolve 'not-security.debian.org' Hit http://ftp.us.debian.org wheezy Release.gpg ... W: Failed to fetch http://not-security.debian.org/dists/wheezy/updates/Release.gpg Could not resolve 'not-security.debian.org' W: Some index files failed to download. They have been ignored, or old ones used instead. 0
Security repository was excluded. That's an attack an adversary can mount or it can happen for other reasons also. The bad thing here is, apt-get exited `0`. Therefore hard to detect these situations in scripts. (Bugs are reported upstream - see ticket description - could take a very long time until fixed upstream.)
The way this was solved in Whonix 10 is by using a wrapper. /usr/lib/apt-get-wrapper, that parses `apt-get update`'s output. Awful hack, but the real fix would require fixing apt-get upstream at Debian.
Simplified Assisted Updates
This is a very difficult problem. Unspecific to Whonix. Applies to any apt-get based distribution.
Automation is very difficult due to issues introduced at a higher level (Debian and The Tor Project).
apt-get is not 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. I.e. apt-get is showing an dpkg interactive conflict resolution dialog. See also Whonix Configuration Files.
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, 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.
See also these related #apt-get upstream bugs, which would make it harder to implement a script automating this. See also this issue with packages that lack full security support, even though those are in Debian stable repository.
See also Security Guide about Updates for yet more complexity that needs to be covered, that we're currently only documenting (unsigned packages, restart required).
See the following ticket, where it has been discussed at length, why an automated, one or zero click update utility cannot be securely and easily implemented by "just writing some utility".
(Not Whonix specific, even though discussed at Whonix tracker...!)
- On major upgrades we need apt-get autoremove.
Unattended upgrades in background for Debian packages
Reasons for Automatic Updates:
- Better usability.
Reasons against Automatic Updates:
- apt security bugs such as CVE-2016-1252 
- 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.)
- When the apt-get is already updating in background and the user starts it manually the user will see the following error message. This is happening in Qubes Debian and Qubes-Whonix templates. apt-get would need to give better feedback to the user or abort the background process and start the foreground process.
sudo apt-get update Reading package lists... Done E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable) E: Unable to lock directory /var/lib/apt/lists/
- 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 reliable no way for a machine to determine if a new version has been released.  
And due to other issues (not passing the
TUF (The Update Framework)'s  threat model [
TUF: Attacks and Weaknesses]), the torbrowser downloader (tb-updater) shouldn't blindly trust what the version check claims is the most recent version. Therefore the user still has to check if it is sane. Could be very well a downgrade attack at some point.
This issue has now been solved by upstream. See:
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 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 is 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.
Everybody who has been following Qubes development in the recent years know Marek very well, I'm sure, and realize he has been the lead developer of Qubes OS for a while now.
- During apt-get upgrading signature verification can be tricked resulting in arbitrary package installation, system compromise. sources:
- 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.
- counter downgrade / stale mirror attacks on RecommendedTBBVersions - sign / verify tbb versions file
- better support for TBB / TPO software downloaders
- https://github.com/theupdateframework/tuf/blob/develop/SECURITY.md http://www.webcitation.org/6F7Io2ncN
https | (forcing) onion
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! See Conditions for Contributions to Whonix, then Edit! IP addresses are scrubbed, but editing over Tor is recommended. Edits are held for moderation.