{{Header}} {{#seo: |description=Why does {{project_name_long}} (not) use Automatic Updates? Why does {{project_name_long}} (not) use a GUI Update Notifier or GUI Updater? }} {{intro| Why does {{project_name_short}} (not) use Automatic Updates? Why does {{project_name_short}} (not) use a GUI Update Notifier or GUI Updater? }} = Introduction = == APT upstream bugs == {{Anchor|Bugs}} * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745735 apt: Provide meaningful exit codes for gpg failures] * (Fixed issues. * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776152 provide meaningful exit codes for network failures] * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778357 audit 'apt update' exit codes] * [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=696335 exit-code 0 when apt update fails] * https://wiki.debian.org/Teams/Apt/Specs/UpdateExitStatus ) == Security Issues when using apt-get update in Scripts == Scripts need to use apt-get with --error-on=any. Otherwise, network errors do not result in a non-zero exit code. APT sources that failed would not be noticed. Security updates might be missing. = Simplified Assisted Updates = == One-Click Upgrade Button for Debian Packages == This is a very difficult problem. [[Unspecific|Unspecific to {{project_name_short}}]]. It applies to any APT-based distribution. Automation is very challenging due to issues introduced at a higher level (Debian). APT is not good at conflict resolution with configuration files. For instance, the user may have installed arbitrary packages and modified their configurations, while upstream may have updated the configuration files. In such cases, dpkg will prompt the user to decide whether to keep the old or adopt the new configuration file. I.e., APT triggers a [[Configuration_Files#dpkg_interactive_conflict_resolution_dialog|dpkg interactive conflict resolution dialog]]. See also [[Configuration_Files|Configuration Files]]. Additionally, other issues can arise, such as: * Problems with GPG verification * Expired package list metadata (e.g., valid-until) https://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html * General system issues caused by interruptions during previous updates Dedicated projects have also failed at simplifying APT, such as Synaptic, Apper Bugs such as Apper recommending a restart while APT (command line) is still processing. , PackageKit, and Software Center. All of these efforts failed to implement a universal solution for all scenarios. When higher-level initiatives (Linux distributions) struggle with user-friendliness, it becomes nearly impossible to address these issues at a lower level in {{project_name_short}}. See also these related [[#APT upstream bugs]], which would make implementing an automated script more difficult. Additionally, consider this [https://forums.whonix.org/t/find-packages-without-security-support-consider-installation-of-debian-security-support-by-default/19262 issue with packages lacking full security support], even though these are in the Debian stable repository. For further complexity, refer to [[Operating System Software and Updates]], where issues such as unsigned packages and required restarts are currently documented. The challenges of securely and reliably implementing an automated one- or zero-click update utility have been extensively discussed. For instance: [https://forums.whonix.org/t/qubes-templates-graphical-updater-apper-broken/19029 This is a massive undertaking equivalent to a standalone project.] (Not {{project_name_short}} specific, although discussed in the {{project_name_short}} tracker!) During [[Release Upgrade]]s, the APT command autoremove is required. 
Err:4 http://HTTPS///fasttrack.debian.net/debian bullseye-fasttrack InRelease
  500  SSL error: wrong version number [IP: 127.0.0.1 3142]
For more information on this specific issue, refer to: [https://forums.whonix.org/t/update-issue-fasttrack-500-ssl-error-wrong-version-number/15876 Update issue: FastTrack 500 SSL error - wrong version number.] = Automatic Updates = == Unattended upgrades in background for Debian packages == Reasons for Automatic Updates: * Better usability. Reasons against Automatic Updates: * Apparently mysterious to those who don't know that automatic updates are enabled by default; would result in questions such as this: Broken link: [[Special:AWCforum/st/id178/Weird_traffic_display_in_arm.html]] 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 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. * Apparently mysterious 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 connection with unlimited quota and want to postpone downloading updates. * Security: 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. During APT upgrading, signature verification can be tricked, resulting in arbitrary package installation and system compromise. Sources: * 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 * Backdoors and compromises: If Debian's update mechanism ever gets compromised If a malicious package was uploaded to Debian's APT repository or if there was a critical bug in APT. , 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...
* Locked APT database usability issue: 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. 
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 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.) Needs Research: * 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? Non-issues: * 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!]] Forum discussion: * 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]] = Update Notifier / GUI Updater = == Rejects ideas == === apper (kde) package === Apper is user-friendly since there is only one big update button and it also honors proxy settings in ''/etc/apt/apt.conf'', which are required for Tor stream isolation. Automatic update checks have been disabled in ''/etc/apt/apt.conf.d/10periodic'' because the execution time would be too predictable. systemcheck runs at startup (non-predictable) and every day at a random time. Apper / Synaptic was removed in {{project_name_short}} 8. See: https://web.archive.org/web/20201214130721/https://github.com/Whonix/Whonix/issues/104 Too many bugs, too confusing. * Broken link: [[Special:AWCforum/st/id166/Gateway_update_errors.html]] * Broken link: [[Special:AWCforum/st/id42/You_have_194_updates_(can't_be_a....html]] === update-notifier (gnome) package === The overall user interface is very good. However, it asks a confusing question to update "safely" without removing packages. After updating "safely," it still reports updates. Open question: how to provide update-notifier in several languages? Would all GNOME language packages be needed? Would require configuration with something like: 
gconftool-2 --config-source xml:readwrite:/etc/gconf/gconf.xml.mandatory
Would also require: 
cp /etc/xdg/autostart/update-notifier.desktop /etc/xdg/autostart/update.desktop
And removing `shownotin=kde` from `/etc/xdg/autostart/update.desktop`. === update-notifier-kde package === This package is confusing. It shows how many updates are available, but it only provides one button: "Later." = Conclusion = 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 = {{reflist|close=1}} {{Footer}} [[Category:Design]] [[Category:Development]]