[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Re: Upcoming C-tor security release - 0.4.9.12
- To: tor-dev@xxxxxxxxxxxxxxxxxxxx
- Subject: [tor-dev] Re: Upcoming C-tor security release - 0.4.9.12
- From: Alexander Hansen Færøy via tor-dev <tor-dev@xxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 10 Sep 2026 23:09:20 +0200
- In-reply-to: <aqLdu7SPkwGHTGv6@mutt-hbsd>
- List-id: discussion regarding Tor development <tor-dev.lists.torproject.org>
- References: <rqojfa4chusf7c2culwcg4lhmstlt24f44agcglyrojjvmuxqa@mwb2qivn6nqd> <aqLdu7SPkwGHTGv6@mutt-hbsd>
- Reply-to: Alexander Hansen Færøy <ahf@xxxxxxxxxxxxxx>
- User-agent: Mozilla Thunderbird
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
_______________________________________________
tor-dev mailing list -- tor-dev@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-dev-leave@xxxxxxxxxxxxxxxxxxxx