** Description changed: [ Impact ] * Upstream announced a need to actively disable older versions of Tor as we they begin the process of upgrading the Tor network to support a number of more modern features that are not supported by older versions of the Tor application. => https://blog.torproject.org/sunsetting-tor-048/ * Without such an update and due to the nature of the network this needs to interact with otherwise - Tor Clients will stop working. - Tor Onion Services, that people may use to reach their SSH daemons with behind NAT/CG-NAT, will stop working. * This update it bumping it to the latest 4.x.y stable release (their big changes are in another rust client) which brings various fixes (as that is most of what they do), a few security improvement, and for the current situation compatibility with the soon upgraded network. [ Test Plan ] Disclaimer: many of these need to initialize quite a while and the network might impose rate limiting. If testing all at once and right after the other somethings could get stuck (they did in my pre-tests). Retry that much later or from a different IP if you can. # Test 1 Note: As suggested by the Upstream project 1) Install the new version via the package. It should have 4.9.11... from proposed when doing this verification. Here an example checking this against the PPA $ apt policy tor tor: Installed: 0.4.9.11-0ubuntu0.26.04.1 Candidate: 0.4.9.11-0ubuntu0.26.04.1 Version table: *** 0.4.9.11-0ubuntu0.26.04.1 500 500 https://ppa.launchpadcontent.net/paelzer/lp-2163259-backport-tor-4.9.11/ubuntu resolute/main amd64 Packages 100 /var/lib/dpkg/status 2) Ensure your init system is able to start, stop, restart the Tor daemon. This is actually a templated service, so we use @default systemctl status tor@default systemctl stop tor@default systemctl status tor@default systemctl start tor@default systemctl status tor@default - This might also on the first time take quite long (see https://bugs.launchpad.net/ubuntu/+source/tor/+bug/2163463). + This might on the first time take quite long (see https://bugs.launchpad.net/ubuntu/+source/tor/+bug/2163463). Late restarts benefit from the data cached from the last. Eventually this needs to fully initialize before you continue. $ systemctl restart tor@default $ journalctl -f -u tor@default ... Aug 14 06:41:01 tor-r Tor[10251]: Opened Socks listener connection (ready) on /run/tor/socks Aug 14 06:41:01 tor-r Tor[10251]: Opening Control listener on /run/tor/control Aug 14 06:41:01 tor-r Tor[10251]: Opened Control listener connection (ready) on /run/tor/control Aug 14 06:41:01 tor-r Tor[10251]: Bootstrapped 10% (conn_done): Connected to a relay Aug 14 06:41:01 tor-r Tor[10251]: Bootstrapped 14% (handshake): Handshaking with a relay Aug 14 06:41:01 tor-r Tor[10251]: Bootstrapped 15% (handshake_done): Handshake with a relay done Aug 14 06:41:01 tor-r Tor[10251]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Aug 14 06:41:01 tor-r Tor[10251]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Aug 14 06:41:01 tor-r Tor[10251]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit Aug 14 06:41:01 tor-r Tor[10251]: Bootstrapped 100% (done): Done After reaching 100% here continue 3) Ensure that Tor starts without failure with the init system with the default configuration, and listens with a SOCKS Port configured on its default port in your Torrc (most likely port 9050/tcp) $ ss -eeapnt | grep tor LISTEN 0 4096 127.0.0.1:9050 0.0.0.0:* users:(("tor",pid=10251,fd=6)) ino:26111 sk:59 cgroup:/system.slice/system-tor.slice/[email protected] <-> SYN-SENT 0 1 10.185.198.39:57800 144.76.188.94:9001 users:(("tor",pid=10251,fd=11)) timer:(on,19sec,10) uid:100 ino:26125 sk:51 cgroup:/system.slice/system-tor.slice/[email protected] <-> ESTAB 0 0 10.185.198.39:47528 164.132.64.22:9300 users:(("tor",pid=10251,fd=10)) uid:100 ino:26124 sk:52 cgroup:/system.slice/system-tor.slice/[email protected] <-> 4) You can use curl to test if Tor's SOCKSPort is usable with: curl -v -x socks5h://127.0.0.1:9050 -s https://check.torproject.org/api/ip The response here should be: ... lots of status info ... {"IsTor":true,"IP":"{{IP of exit node}}"} --- # Test 2 The track record of the automated tests isn't great, they are flaky and need to reach out externally which makes them fail. => https://autopkgtest.ubuntu.com/packages/t/tor We can't fix the infra for this big time but I have found that the tests run locally at least for Noble/Resolute. Jammy had tests that later got fixed, but the packages needed for that fix didn't exist in jammy yet. So we can't fix the tests on infra in a reasonable amount of work given the case and I could say "always failed, will not be marked as regression", but I do not want to. I wondered if I could leverage these tests and for this larger bump turn them to manual execution steps (which ran on a dev machine would have external network). 1. Remember to enable the proposed pocked 2. Get the code the tests would run $ git clone https://git.launchpad.net/ubuntu/+source/tor $ cd tor/debian/tests/ 3. Install all dependencies at once # For jammy, use onionshare instead of onionshare-cli $ apt install tor netcat-openbsd torsocks curl ca-certificates onionshare-cli colorized-logs diffutils 4. run the tests yourself (derived from the failing dep-8 tests) $ tmpdir="$(mktemp -d /tmp/tortest.XXXXXX)" $ cd $tmpdir $ $ chmod +x download-release-file setup-onion-service 5. apply a test fix that I work on for 26.10 onwards - Insert the suggestion of https://bugs.launchpad.net/ubuntu/+source/tor/+bug/2163463 - I'll fix this in the long run going forward, but would not want - to stall this SRU on that. + Insert the suggestion of + https://bugs.launchpad.net/ubuntu/+source/tor/+bug/2163463 + to wait for the init to complete. + I'll fix this in the long run going forward via that bug, but + would not want to stall this SRU on that. Also needing external + network this will not run on Ubuntu infra everm and so the + SRU verification will be manual as described anyway. 6. run the test $ ./download-release-file A good run ends downloading the release file and an exit code of zero. - That looks like this: Thereby this test exercised the torsocks with a custom config, control commands, talking to real instances and downloading a file through it. That gives this a better coverage than the other test alone. [ Where problems could occur ] Note: The following is from a conversation with Upstream, which made me quite confident that while there are many fixes and a few new features none of the existing usage, config or interaction should have changed. * While this bumps minor versions the C Tor implementation hasn't seen massive changes in its user-interface and configuration files. They have added features (and thus added new configuration entries), but the old configuration files should continue to work today. They do not contain a library so no API/ABI checks are needed. The ControlPort interface has, like our configuration file, seen some added features, but nothing that should break any applications that connects to it. The ControlPort is Tor's mechanism for 3rd party applications to "control" a Tor process and is how, for example, Tor Browser makes Tor do various things based on user settings and input. The CLI, configuration format, and ControlPort should only have seen additive features, and thus shouldn't break existing installations. To admit, they have only policy but no CI to e.g. ensure former CLI works unaffected. While asking why it came up that C Tor has since 2020/2021 been mostly an idle project as their focus has been shifting towards our Rust implementation called Arti. The big features that have been added during this time are all enabled automatically and are mostly performance or security related. Which is good for this update as it reduced the potential churn it could have had. Most of the changes in C Tor are in fact just fixes and that is perfect for this update. * Once more it is worth to mention that the worst regression will happen on 1st September if we do nothing - it will stop to work. So while there could be regressions (unlikely since this is fixes and new features, not changes to old), the worst regression seems to be doing nothing. [ Other Info ] * Debian has done the very same minor release updates, so we would not be the outlier. tor | 0.4.9.11-0+deb12u1 | oldstable | source tor | 0.4.9.11-0+deb13u1 | stable | source tor | 0.4.9.11-1 | testing | source Current Ubuntu set is whatever we auto-synced at the time of release: tor | 0.4.6.10-1 | jammy/universe | source tor | 0.4.8.10-1build2 | noble/universe | source tor | 0.4.9.6-1 | resolute/universe | source tor | 0.4.9.11-1build1 | stonking/universe | source I've checked these Debian uploads to decide if I go tarball-only or also some packaging changes. It ended up taking the latest (to get fixes from upstream and packaging) but also reverting anything that was deemed non-backportable. See the upload changelogs for that. * Strictly speaking, the 4.9.6 in Resolute would be ok in regard to the discontinuation in the network, but it has security bugs and therefore the best would be to bump all active releases to the latest. Otherwise upgraders e.g. N->R would regress as they lose the general bug fixes that are in 4.9.11 over 4.9.6 * Time is scarce, which is why I'm helping to get this out fast for now (but guided them how to get upload rights and otherwise use patch pilots and such). The sunset of <4.9 is planned for 1st September, hence it would be nice to have that done before that. ----- original report ----- Tor[28740]: Please upgrade! This version of Tor (0.4.8.10) is obsolete, according to the directory authorities. Recommended versions are: 0.4.9.4-rc,0.4.9.5,0.4.9.6,0.4.9.7,0.4.9.8,0.4.9.9,0.4.9. 10,0.4.9.11 [it's that time again.] Ubuntu: 26.10 tor: # apt-cache policy tor tor: Installed: 0.4.8.10-1build2 Candidate: 0.4.8.10-1build2 Version table: *** 0.4.8.10-1build2 500 500 https://ubuntu.hysing.is/ubuntu noble/universe amd64 Packages 100 /var/lib/dpkg/status ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: tor 0.4.8.10-1build2 Uname: Linux 6.13.0-gnmlibre x86_64 ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 CasperMD5CheckResult: unknown Date: Tue Aug 11 16:04:29 2026 ProcEnviron: LANG=en_US.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=screen.xterm-256color XDG_RUNTIME_DIR=<set> RebootRequiredPkgs: Error: path contained symlinks. SourcePackage: tor UpgradeStatus: Upgraded to noble on 2024-04-26 (838 days ago) modified.conffile..etc.tor.torrc: [modified] mtime.conffile..etc.tor.torrc: 2026-08-11T15:45:52.916988
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2163259 Title: Tor sunsets <=4.8 - update to 4.9.11 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tor/+bug/2163259/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
