** 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. [ Test Plan ] - * TBD - waiting on upstreams input to that + 1) Install the new version via the package. + + 2) Ensure your init system is able to start, stop, restart the Tor + daemon. + + 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) + + 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: + + {"IsTor":true,"IP":"{{IP of exit node}}"} + [ Where problems could occur ] - * TBD - waiting on upstreams input to that + 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. - * Think about what the upload changes in the software. Imagine the - change is wrong or breaks something else: how would this show up? + * 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. - * It is assumed that any SRU candidate patch is well-tested before - upload and has a low overall risk of regression, but it's important - to make the effort to think about what ''could'' happen in the event - of a regression. + They do not contain a library so no API/ABI checks are needed. - * This must never be "None" or "Low", or entirely an argument as to why - your upload is low risk. + 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. - * This both shows the SRU team that the risks have been considered, - and provides guidance to testers in regression-testing the SRU. + 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 does the very same minor release updates, so we would + * 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 - I'll check these Debian uploads to decide if I go tarball-only or - also some packaging changes. + Current Ubuntu set is whatever we auto-synced at the time of release: - 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 - tor | 0.4.6.10-1 | jammy/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x - tor | 0.4.8.10-1build2 | noble/universe | source, amd64, arm64, armhf, ppc64el, riscv64, s390x - tor | 0.4.9.6-1 | resolute/universe | source, amd64, amd64v3, arm64, armhf, ppc64el, riscv64, s390x - tor | 0.4.9.11-1build1 | stonking/universe | source, amd64, amd64v3, arm64, armhf, ppc64el, riscv64, s390x + 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
** 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 ] 1) Install the new version via the package. 2) Ensure your init system is able to start, stop, restart the Tor daemon. - 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 + 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) 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: {"IsTor":true,"IP":"{{IP of exit node}}"} - [ 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. + 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. + 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 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. + 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. + 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. + 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. + 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 + 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 ** 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. + * 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 ] + + Note: As suggested by the Upstream project 1) Install the new version via the package. 2) Ensure your init system is able to start, stop, restart the Tor daemon. 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) 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: {"IsTor":true,"IP":"{{IP of exit node}}"} [ 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
