Introduction[edit]

APT upstream bugs[edit]

apt: Provide meaningful exit codes for gpg failures ^[archive]
(Fixed issues. ^[1])

Simplified Assisted Updates[edit]

One click upgrade button for Debian packages[edit]

This is a very difficult problem. Unspecific to Whonix ™. Applies to any APT based distribution.

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

APT 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 is showing an dpkg interactive conflict resolution dialog. See also Configuration Files.

Also other things can go wrong, such as problems with gpg verification, package lists, which are no longer valid-until^[2], general brokenness due to aborts during last action and so forth. Others dedicated projects have failed at simplification of APT, such as synaptic, apper^[3], 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 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 ^[archive].

See also Operating System Software and 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".

It's a huge task of the size of a separate project. ^[archive] (Not Whonix ™ specific, even though discussed at Whonix ™ tracker...!)

At Release Upgrades APT autoremove is required.

Automatic Updates[edit]

Unattended upgrades in background for Debian packages[edit]

Reasons for Automatic Updates:

Better usability.

Reasons against Automatic Updates:

Apparently mysterious ^[4] system load Depending on system performance and other tasks concurrently performed by the user (such as on the host and/or in other VMs) this might make the user's machine unsuspectingly seems slow during upgrades. In past there was an issue of a VMs freezing during upgrades (kernel module compilation) installation ^[archive] due to a too low default RAM setting.
Apparently mysterious ^[4] network load: On already slow (Tor) connections downloads could make online tasks performed by the user slower than usual or even unusable.
Metered connections: Some people may be on different kinds of internet connections. Sometimes they may use a connecti-on with unlimited quota and want to postpone downloading updates.
Security: Due to apt security bug CVE-2016-1252 ^[archive] it was better to Stay Tuned and manually rather than automatically upgrading. ^[5]
Backdoors and compromises: If Debian's update mechanism ever gets compromised ^[6], then it would make sense for users to read Whonix ™ News before manually updating. Quote Old discussion ^[archive]:
(anonymous) Automatic updates are dangerous. All updates are dangerous. They are remote root backdoors (with some restrictions and checks of course). The problem is, if "something" goes wrong it will automatically propagate accross all users in a very short amount of time. On the other hand, if you update manually a day later or so, it's likely that somone else has noticed the problem and notified Canonical and you stay save. Lots of things can "go wrong": a dev system, a build system, the key or the crypto system could become compromised. It has happened several times, openssl issue, Fedora/RedHat, kernel.org, Flame malware. Not all of them would be mitigated by using manual updates (only donwloading the patches, reviewing them and manually applying them would. Sadly for that to be usable the TCB is too complex and large, it just wouldn't scale. Software updates are messy but right now a necessary evil. I feel more comfortable not letting them run in the background without any verbose output. The one day more or not will not impact security. With Linux distros it already takes time anyway between upstream fix and downstream release. Further, if it's a 0day you already lost that one (and have to rely on the additional security that aos provides). A single security issue should never impact security in a fatal way. It still does in aos 0.* but I hope that can be changed. i.e. we need to migrate away from using the same OS for t-w and t-g. This includes the kernel and I'm not really sure what alternatives there are. Essentially there's only *BSD. See new ticket...
Locked APT database usability issue: When the APT is already fetching or installing upgrades 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 would need to give better feedback to the user or abort the background process and start the foreground process.

sudo apt 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/

Anonymity specific: If the user is using Debian a host operating system or connecting to the same mirror, Connect to a Server Anonymously and Non-anonymously at the Same Time 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 update" is run randomized to prevent a clear network fingerprint? If not, this needs a custom implementation/diverting some scripts.
Are times when "apt full-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?

Non-issues:

The Tor Project did not ask us, not to download updates over Tor, see: You should not waste the Tor network's bandwidth by downloading operating system updates over Tor!

Forum discussion:

in old forum https://sourceforge.net/p/whonix/discussion/general/thread/2753b89c/ ^[archive]

Auto Upgrading Tor Browser[edit]

Update Tor Browser

Update Notifier / GUI Updater[edit]

Rejects ideas[edit]

apper (kde) package[edit]

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 was removed in Whonix ™ 8, see: https://github.com/Whonix/Whonix/issues/104 ^[archive]

Too many bugs, too confusing:

update-notifier (gnome) package[edit]

Overall user interface 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 confusing. It shows how many updates are available, but it has only one button "later".

Conclusion[edit]

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.

Footnotes[edit]

↑
↑ http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html ^[archive]
↑ Bugs such as apper recommends restarting while APT (command line) is still working.
↑ ^4.0 ^4.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
↑
During APT upgrading signature verification can be tricked resulting in arbitrary package installation, system compromise. sources:
↑ If a malicious package was uploaded to Debian's APT repository or if there was a critical bug in APT.

Whonix ™ is Supported by Evolution Host DDoS Protected VPS. Stay private and get your VPS with Bitcoin or Monero.

	100px
Fosshost	About Advertisements

Follow:

Support:

Donate:

Love Whonix ™ and want to help spread the word? You can start by telling your friends or posting news about Whonix ™ on your website, blog or social media.

Priority Support | Investors | Professional Support

The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.

Dev/Automatic Updates

From Whonix

< Dev

Contents