Unattended upgrades in background for Debian packages
Reasons for Automatic Updates:
Reasons against Automatic Updates:
* <u>Apparently mysterious <ref name=mysterious>
to those who don't know that automatic updates are enabled by default; would result in questions such as this: Broken link: <nowiki>[[Special:AWCforum/st/id178/Weird_traffic_display_in_arm.html]]</nowiki>
</ref> system load</u>: 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 seem slow during upgrades. In the past, there was an issue of [https://forums.whonix.org/t/whonix-xfce-for-virtualbox-users-ram-increase-required/8993 VMs freezing during upgrades (kernel module compilation)] due to a too low default RAM setting.
* <u>Apparently mysterious <ref name=mysterious /> network load</u>: On already slow (Tor) connections, downloads could make online tasks performed by the user slower than usual or even unusable.
* <u>Metered connections</u>: Some people may be on different kinds of internet connections. Sometimes they may use a connection with unlimited quota and want to postpone downloading updates.
* <u>Security</u>: Due to the apt security bug [https://security-tracker.debian.org/tracker/CVE-2016-1252 CVE-2016-1252], it was better to [[Stay Tuned]] and manually upgrade rather than upgrading automatically. <ref>
During APT upgrading, signature verification can be tricked, resulting in arbitrary package installation and system compromise.
* https://security-tracker.debian.org/tracker/CVE-2016-1252
* https://www.debian.org/security/2016/dsa-3733
* https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467
* https://lists.debian.org/debian-security-announce/2016/msg00316.html
* https://forums.whonix.org/t/apt-get-upgrading-security-issue-cve-2016-1252/3288
* <u>Backdoors and compromises</u>: If Debian's update mechanism ever gets compromised <ref>
If a malicious package was uploaded to Debian's APT repository or if there was a critical bug in APT.
</ref>, then it would make sense for users to read [[systemcheck|{{project_name_short}} News]] before manually updating. Quote [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorBOX/Dev/ArchivedDiscussion/SECURITY#security-automatic-updates-rejected Old discussion]: 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 across 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 someone else has noticed the problem and notified Canonical, and you stay safe. 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, such as the openssl issue, Fedora/RedHat, kernel.org, and Flame malware. Not all of them would be mitigated by using manual updates (only downloading 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 fixes 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...
* <u>Locked APT database usability issue</u>: When APT is already fetching or installing upgrades in the background and the user starts it manually, the user will see the following error message. This is happening in Qubes Debian and [[Qubes|{{q_project_name_long}}]] templates. APT would need to give better feedback to the user or abort the background process and start the foreground process.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/
* <u>Anonymity specific</u>: If the user is using Debian as 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 the 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?
* Is a stale mirror attack a 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?
* There's an application for Lubuntu, that could potentially be used as a starting point for implementing this. It wraps apt-get, running it with command-line options and parsing terminal output from it. https://git.lubuntu.me/Lubuntu/lubuntu-update:
** debconf questions - easily handled using the KDE debconf frontnd, the Lubuntu tool does this
** dpkg interactive conflict resolution dialog - built into Lubuntu's tool, it can show diffs for the files that are a problem, and allow the user to keep or reject each conffile
** DNS failures - better error reporting can help deal with that
** connection failures (ISP’s preventing connections to apt repositories for whatever reason; targeted attacks) - better error reporting can help deal with that
** installation issues due to broken dependencies - the apt log output is shown in the app so the user can see if this kind of thing goes wrong, and if so, why
** hold back packages - would have to double-check but the tool may handle this already
** notifications about packages available for autoremoval - wouldn't be difficult to implement
** packages in Debian stable, that that have no security support (T135) - this one could be tricky
** slow retrival attacks (Defined by TUF: Attacks and Weaknesses (w).) - apt itself can't prevent against this, there's a progress bar so the user can tell if things are being severely slowed down, adding a cancel button would help here
** endless data attacks (Defined as per TUF.) - also something that apt would have to solve, not sure if this is possible with apt?
** retrieved package release who’s valid-until field [when forgotten to refresh the repository, eventual roll back (TUF) or indefinite freeze (TUF) attack] - packages have a valid-until field? This also sounds like something apt would take care of
** invalid signatures - could be handled with better error reporting
** expired signing keys - needs better error reporting
** interrupted upgrades - needs better error reporting, might be handled already
** failing Debian maintainer scripts - needs better error reporting, might be handled already (remember the log output from apt is shown)
** locked apt (some other process still using apt or died) - might be handled already, also can just use better error reporting
** permission issues - if you mean authentication failure when attempting to upgrade, that's almost certainly implemented already, if not, better error reporting needed again
* Possible to make an application that simply notifies *when* updates are available and lets the user handle the process of installing them?
* The Tor Project did not ask us not to download updates over Tor. See: [[Dev/Tor#Why_Waste_Network_Bandwidth_by_Downloading_Operating_System_Updates_over_Tor.3F|You should not waste the Tor network's bandwidth by downloading operating system updates over Tor!]]
* In old forum: https://web.archive.org/web/20211231041032/https://sourceforge.net/p/whonix/discussion/general/thread/2753b89c/
Auto Upgrading Tor Browser
[[Tor_Browser#Update_Tor_Browser|Update Tor Browser]]
or create an account