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 ;).
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,
···
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 ;).
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
···
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.
--
Alexander Hansen Færøy
_______________________________________________
tor-dev mailing list -- tor-dev@lists.torproject.org
To unsubscribe send an email to tor-dev-leave@lists.torproject.org
