On Tue, Nov 10, 2026 at 11:30:12PM +0100, Sebastian Andrzej Siewior wrote: > On 2026-11-10 11:41:02 [+0200], Adrian Bunk wrote: > > Which means it doesn't help with the old question[1] whether the release > > team commits to having the transition+toolchain freeze after April to > > accomodate 4.2 LTS in forky, or how else security support for OpenSSL > > in forky is planned. > > My plan is still to go for LTS for the release. > > > openssl/trixie is upstream supported until April 2030, and while I > > understand that you hate me for mentioning that downgrading to 3.5 > > would be an option for getting OpenSSL security support in forky, > > that would also be an option. > > 3.6 becomes slowly difficult since upstream dropped the ball already. > For the upcoming December release I can either ignores the security > patches or backport them myself…
Yes, that's a good argument that a decision on whether forky will use 3.5 or 4.2 is needed soon. > Going back to 3.5 is not that simple because we have already software in > the archive using the additional symbols. Going back after doing the OpenSSL 4 transition would be a large transition, right now going back to 3.5 would require binNMUs of only 7 packages: https://people.debian.org/~bunk/openssl/openssl-3.5.html > Also 4.0+ will not just have ESNI but likely more PQC resistance. I remember a similar argument justifying having two OpenSSL versions in stretch, which was just a bad idea. > > 4.0 will be EOL before the release of forky and 4.1 in a year,[2] > > so being stuck with 4.1 would be a problem. > > > > As already mentioned this is not a one-off issue, OpenSSL plans to start > > their LTS branches every 2 years in April of our release years.[3] > > This is sort of timed with the Debian cycle. That depends on the exact timing of the freeze, which is why I am writing these emails. If the forky transition+toolchain freeze is in May, then OpenSSL fits nicely. bookworm had the hard freeze already on March 12th, switching to a different OpenSSL branch in April would not work with such a schedule. > > My point here is that whatever the result may be, this needs an explicit > > decision regarding whether OpenSSL 4.2 fits into the forky release > > schedule before a transition to OpenSSL 4. > > good that you mentioned that. Discussing this topic early also gives the release team the option to slightly adjust their schedule if that makes 4.2 possible, especially near misses like forky freezing in mid-April should be avoidable. And as already mentioned, whatever is done with OpenSSL in forky will be a precedent for what will be done when OpenSSL 5.3 LTS releases in April 2029. > Sebastian cu Adrian
