Upcoming C-tor security release - 0.4.9.12
Greetings everyone! Next Tuesday, September 8th, we will do a C-tor release (0.4.9.12) containing fixes for a set of high severity issues. And then, as a heads up, C-tor will likely enter a release cadence every 2-3 weeks for the foreseeable coming month(s) as we continue to fix more and more security issues we received from this new reality that we happen to all be in where LLMs are in an echo chamber stuck in a tight loop over our C code ;). Cheers! David -- NeD2Y6SX2RdikJfl0oSgWfrO+dQkz9M114CVJBuzW3w=
On Thu, Sep 03, 2026 at 09:11:01AM -0400, David Goulet via tor-dev wrote:
Greetings everyone!
Next Tuesday, September 8th, we will do a C-tor release (0.4.9.12) containing fixes for a set of high severity issues.
And then, as a heads up, C-tor will likely enter a release cadence every 2-3 weeks for the foreseeable coming month(s) as we continue to fix more and more security issues we received from this new reality that we happen to all be in where LLMs are in an echo chamber stuck in a tight loop over our C code ;).
Hey David, Is the 2-3 week cadence a permanent change? If so, that might pose a problem for operating system vendors with slow package building servers. For example, it usually takes 2-4 weeks to build the HardenedBSD package repositories. (4 weeks if starting the build from scratch, 2-ish weeks for the average incremental build.) And then there's the matter of deploying the updated versions in our infrastructure. A lot of work between building packages and deploying them in our own infrastructure. As a resource-constrained downstream, I'm not entirely sure if we can keep up with that kind of cadence. I'm hoping it's just temporary while security issues get triaged and worked through. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 (719) 756-1197 / activist_opsec.27 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4...
On 10/09/2026 18.45, Shawn Webb via tor-dev wrote:
Is the 2-3 week cadence a permanent change? If so, that might pose a problem for operating system vendors with slow package building servers. For example, it usually takes 2-4 weeks to build the HardenedBSD package repositories. (4 weeks if starting the build from scratch, 2-ish weeks for the average incremental build.)
And then there's the matter of deploying the updated versions in our infrastructure. A lot of work between building packages and deploying them in our own infrastructure.
As a resource-constrained downstream, I'm not entirely sure if we can keep up with that kind of cadence. I'm hoping it's just temporary while security issues get triaged and worked through.
Hey Shawn, Nice to hear from you again! To be very honest, we do not know. As long as we continue to receive the current amount of LLM-assisted security bugs, we will likely aim at keeping this new pace. This ensures that Tails and Tor Browser can also get "our" C Tor updates as part of their new increased cadence due to their upstreams (Debian and Firefox) also increasing their frequency of releases/updates. This is unfortunately the reality for many FOSS projects right now. In the ideal world, this wouldn't be a problem, but given our limited resources internally, we also need to constantly prioritise what we aim at fixing in the current window, and try to fix as many of the things we can before the window closes. Batching up larger amounts of bugs would also put added risks on our users both in terms of the bugs themselves, but also if we introduce regressions as part of our effort of trying to fix the bugs. I'm sorry we have to push the pressure downwards, but we don't really feel like we have many other options here :-( Cheers, Alex -- Alexander Hansen Færøy
participants (3)
-
Alexander Hansen Færøy -
David Goulet -
Shawn Webb