Rendered at 18:49:01 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
haunter 2 days ago [-]
> Dropped Windows-on-Itanium (VC-WIN64I) and Windows CE (VC-CE) targets
from Configurations.
What a throwback. afaik Windows Server 2008 R2 had Itanium updates until 2020 and paid support until this year. Pretty good run to
say at least
mrweasel 2 days ago [-]
Make you wonder what they've been testing this on. Even NetBSD doesn't have a recent release for Itanium. Crazy that you can run NetBSD 11.0 on HPPA, but not Itanium, given that HPPA is in some sense the pre-cursor to Itanium.
mixdup 2 days ago [-]
Age is probably less relevant than current installed base/active users
mondainx 2 days ago [-]
More than likely in "government"; they are always behind and keeping legacy stuff around. I found Windows 1.0 floppies in a drawer, back-in-the-day.
jasomill 1 days ago [-]
Back in the day? If I ever need SunOS 4 installation tapes, 8” distribution floppies for Intel’s ISIS-II PL/M-80 compiler, or a copy of the Microsoft OS/2 1.10 SDK, I know just the filing cabinet at work where I can find them.
Meanwhile, ISO images of software currently used in production have been memory-holed to free up space on a multiterabyte SAN.
tosti 1 days ago [-]
That's awful on multiple levels. Software in use should be easy to grab from the SAN shelf, and multi-terabyte was impressive 2 decades ago.
2 days ago [-]
p_l 2 days ago [-]
Honestly more HPPA gear to test against than Itanium
On a more common platform, Windows has ARM64EC, which is basically ARM64 (LE) with x86-64 calling conventions.
nirui 2 days ago [-]
I kinda wonder what if Microsoft (or any major software company) would give their engineers a few decades of time just to refactor their existing systems, opposite of piling on new features. Will it result a much cleaner code, better architect, and stable product?
The last Windows I daily use was Windows 7 Home (same era with Windows Server 2008). The newer ones don't really improved much featurely from my (user) point of view, and from what I've heard, it's getting more sloppyer every newer version.
zbentley 2 days ago [-]
> what if Microsoft would give their engineers a few decades of time just to refactor their existing systems
They wouldn't, even if they didn't care about shipping new features. The technical complexity inside Windows/Office/old core MS offerings arises only in small part from ordinary tech debt--that is, things fixable without changing observable behavior. The lion's share of that complexity is because of Microsoft's priority to avoid breaking compatibility (backwards, or with hardware/software combos that work) at all costs.
That means that a refactor-only decade would achieve little unless that compatibility priority were changed.
hnlmorg 2 days ago [-]
Microsoft did do exactly this with NT. It’s all the crap on top that ruins it.
2 days ago [-]
masfuerte 2 days ago [-]
The Windows user-mode innards have been significantly refactored. Many of the core system DLLs that apps link to are just redirects to the actual implementation now. Much of the jank seems to be in the UI.
CodesInChaos 2 days ago [-]
It's just as likely it would end up as an overengineered mess. And that's without considering backwards compatibility constraints, which are one of the biggest maintenance burdens.
egorfine 2 days ago [-]
This will NOT please the shareholders. And that's all that matters.
hannob 2 days ago [-]
I don't see "we fixed some of the the excessive performance regressions that we introduced in 3.0". Unfortunate...
It has improved significantly since the early days of 3.0. Not back to 1.1.1 levels of performance, but enough that it's probably not a dealbreaker for most people.
Still a shame that it went backwards.
hannob 2 days ago [-]
To put that in perspective: I noticed that private key parsing was 70 times slower in early 3.x versions. I think it's only 8 times slower in current versions. That's still... a lot slower. For no good reason.
ahartmetz 2 days ago [-]
>We do not fully understand the motivations that led to the public APIs and internal complexity we’ve described here. We’ve done our best to reverse engineer them by asking “what would motivate someone to do this” and often we’ve found ourselves coming up short.
Surely they thought of it but didn't say it out loud... to keep it exploitable, maybe?
hannob 2 days ago [-]
Never attribute to malice what can sufficiently be explained by the love of software developers for overengineering and complexity.
Seriously, I have no trouble explaining this. Overengineering is just how many people think software development works. It's unfortunate, it causes plenty of problems, but it's not a sign of malicious intent.
ahartmetz 23 hours ago [-]
> the love of software developers for overengineering and complexity
How noob exactly are the people working on... checks notes... OpenSSL for crying out loud?! These are beginner's mistakes.
woodruffw 2 days ago [-]
No, that's not what's being implied. They're just saying they don't understand why OpenSSL has added so many indirections to otherwise straightforward operations.
Source: I am friends with the maintainers who wrote this and was one of the people who reviewed it in draft form.
pseudosaid 2 days ago [-]
yet you too dont have an idea why asinine decisions were championed
woodruffw 2 days ago [-]
I have a pretty good idea. And it has nothing to do with malice or exploitability.
noitpmeder 2 days ago [-]
Care to share...???
palata 2 days ago [-]
Didn't they say it already? They basically think that the OpenSSL API is convoluted. That's my understanding of the comment above, at least.
timschmidt 2 days ago [-]
Unnecessarily complicated APIs are a security code smell precisely because they help hide bugs, leaky abstractions, insecure state, and other exploitable issues.
palata 2 days ago [-]
Did I say they weren't? Not sure why I'm being downvoted here.
timschmidt 2 days ago [-]
Op did immediately above you i.e.: "nothing to do with malice or exploitability"
and when asked to explain you responded with: "Didn't they say it already?"
Which any reader can verify they have not at the time of 1:42pm EST Oct 23 2026.
woodruffw 2 days ago [-]
There are two different things here: there’s code that is vulnerable because of unnecessary complexity, and there is imputing malice or an intent to hide exploitability through complexity. OpenSSL exhibits the former, not the latter.
timschmidt 2 days ago [-]
> OpenSSL exhibits the former, not the latter.
The OpenBSD folks came to the exact opposite conclusion after auditing the code:
"In a nutshell, This was a very effective exploit mitigation technique countermeasure. It could not have been designed better to make an attack like heartbleed both hard to detect and have dire consequences. OpenBSD's memory allocator, Valgrind, and Coverity do not notice the memory issues."
Further, known exploits like the one crafted for XZ take advantage of plausible deniability and trust in contributors at every opportunity. Meaning that even if you wanted to disclaim malice, you cannot do so effectively.
woodruffw 2 days ago [-]
They don’t appear to, at least not in my reading. “It could not have been designed better” reads more like an indictment of quality than an accusation of malfeasance.
timschmidt 2 days ago [-]
The chosen phrasing is literally one step short of accusing the author of intent. "It could not have been designed better to [avoid detection] and cause harm" leaves open the possibility of accident, in the way that saying "this guillotine could not have been designed better to chop heads" leaves open the possibility of one spontaneously assembling from raw materials.
thayne 2 days ago [-]
In my experience the phrase "it couldn't have been designed better to [negative thing]" is typically used, in a sarcastic, and usually exaggerated way, to mean "they did such a bad job, that they couldn't have done [negative thing] better, even if they had been intentionally trying to do [negative thing] (which they weren't)."
woodruffw 2 days ago [-]
I mean, that seems intentional to me.
timschmidt 2 days ago [-]
Better your threat model depend on that assumption than mine.
incanus77 2 days ago [-]
Gee, I wonder what it could’ve been…
chemodax 2 days ago [-]
AWS-Lc looks very promising replacement for OpenSSL these days.
Bender 2 days ago [-]
I looked into this and was tempted as there is less read locking and better RNG performance but they stripped the SSL_get1_curves() API which I depend on for bot detection plus I would have to recompile nginx and all its modules everywhere so in the end it was not tempting enough for me. Perhaps I am just lazier in my older age.
mrweasel 2 days ago [-]
We ran a number of tests, including sending a percentage of real traffic to endpoints running AWS-LC and Wolfssl. Technically yes, OpenSSL 3.X is slow, measurably so, but not enough that we wanted to deal with it. That's for our use case, I can easily imagine there being others, where maybe you have different hardware or way more traffic, where it would be worth while. For basic TLS termination in haproxy, it wasn't really worth it to us.
thayne 2 days ago [-]
It also depends on exactly which version of OpenSSL. We ran similar tests with multiple versions of openssl. Openssl 3.0, which was the version in the official packages of our LTS distro was unacceptably slow. With 3.4, it was still worse than 1.1.1 but the regression was an acceptable level.
It also definitely depends on your hardware, and how you use it. The main source of the performance regression is more lock contention, so it is more noticeable if you have more threads running on more cores.
otterley 2 days ago [-]
Nothing wrong with being frugal with your time!
neverpanic 2 days ago [-]
There were massive improvements to performance in some of the areas criticized by PyCA and haproxy. X.509 handling will also be faster in the average case, with more improvements planned for 4.2.
tangential, but I've always wondered what the point of these random pictures of a lock, gears, or unrelated little voxel art are for? Pre-LLMs, they were often hit or miss in terms of how much they added depending on if they were a random stock image or something someone drew.
But now, with LLMs, they're more available to customize, and it seems like people aren't actually thinking anymore about why they should be there. I think I'm implicitly biasing against the rest of the content in articles which have them as a result, since it's probably a sign of some level of lack of care/thought.
computer23 2 days ago [-]
You need an image for the thumbnail that's essentially required for most blog templates and in social media.
2 days ago [-]
grenoire 2 days ago [-]
SEO-maxxing.
adzm 2 days ago [-]
I think this is the only software project I use that still requires me to have perl
ShakataGaNai 2 days ago [-]
Guys, after this week, can we make sure to have more details in the title? Like "Look! Cool new OpenSSL features" so we're not PTSD'ing our way into release notes expecting it to say something about patching critical CVEs?
mlhpdx 2 days ago [-]
> Support for DTLS 1.3 (RFC 9147).
Refer to the ossl-guide-dtlsv13(7) manual page for details.
DTLS 1.3 is a huge improvement over 1.2 for efficiency and simplicity. I can’t speak to the OpenSSL implementation but it’s great that support is finally released.
Naru41 2 days ago [-]
However, it's unfortunate that demo code provided by OpenSSL uses a simplified implementation, spawning a thread for each client connection.
It would become much more practical if it were integrated with libuv or libevent.
markasoftware 2 days ago [-]
Interesting they're adding new support for DTLS 1.3 when afaict most new applications are defaulting to QUIC datagram mode. I have something built around DTLS 1.3 and am using wolfssl for that reason, will have to check this out.
neverpanic 2 days ago [-]
Apparently the telecom industry uses DTLS, not QUIC, and eventually wants post-quantum cryptography for regulatory reasons, so needs DTLS 1.3.
mlhpdx 2 days ago [-]
QUIC for embedded? I haven’t seen that, but there is a lot of DTLS. Particularly with 1.3, it makes QUIC look like a behemoth in code.
What a throwback. afaik Windows Server 2008 R2 had Itanium updates until 2020 and paid support until this year. Pretty good run to say at least
Meanwhile, ISO images of software currently used in production have been memory-holed to free up space on a multiterabyte SAN.
https://github.com/openssl/openssl/blob/c69b5af10a754051274e...
“ The executable format that works on HPE Nonstop Compute's OSS is ELF64-bit, Big_Endian, X86_64. ”
https://inbox.sourceware.org/gcc-help/AM7PR02MB6483A12F6B98D...
The last Windows I daily use was Windows 7 Home (same era with Windows Server 2008). The newer ones don't really improved much featurely from my (user) point of view, and from what I've heard, it's getting more sloppyer every newer version.
They wouldn't, even if they didn't care about shipping new features. The technical complexity inside Windows/Office/old core MS offerings arises only in small part from ordinary tech debt--that is, things fixable without changing observable behavior. The lion's share of that complexity is because of Microsoft's priority to avoid breaking compatibility (backwards, or with hardware/software combos that work) at all costs.
That means that a refactor-only decade would achieve little unless that compatibility priority were changed.
Context: https://cryptography.io/en/latest/statements/state-of-openss...
Still a shame that it went backwards.
Surely they thought of it but didn't say it out loud... to keep it exploitable, maybe?
Seriously, I have no trouble explaining this. Overengineering is just how many people think software development works. It's unfortunate, it causes plenty of problems, but it's not a sign of malicious intent.
How noob exactly are the people working on... checks notes... OpenSSL for crying out loud?! These are beginner's mistakes.
Source: I am friends with the maintainers who wrote this and was one of the people who reviewed it in draft form.
and when asked to explain you responded with: "Didn't they say it already?"
Which any reader can verify they have not at the time of 1:42pm EST Oct 23 2026.
The OpenBSD folks came to the exact opposite conclusion after auditing the code:
"In a nutshell, This was a very effective exploit mitigation technique countermeasure. It could not have been designed better to make an attack like heartbleed both hard to detect and have dire consequences. OpenBSD's memory allocator, Valgrind, and Coverity do not notice the memory issues."
https://www.openbsd.org/papers/bsdcan14-libressl/mgp00007.ht...
Just a single damning slide among many here: https://www.openbsd.org/papers/bsdcan14-libressl/
More here: https://www.libressl.org/papers.html
Further, known exploits like the one crafted for XZ take advantage of plausible deniability and trust in contributors at every opportunity. Meaning that even if you wanted to disclaim malice, you cannot do so effectively.
It also definitely depends on your hardware, and how you use it. The main source of the performance regression is more lock contention, so it is more noticeable if you have more threads running on more cores.
See https://openssl2026.sched.com/event/2VSQR/performance-the-li... and its slides https://2026.openssl-conference.org/slides/2026-d3-1400-perf.... Recording should also be available soon-ish.
But now, with LLMs, they're more available to customize, and it seems like people aren't actually thinking anymore about why they should be there. I think I'm implicitly biasing against the rest of the content in articles which have them as a result, since it's probably a sign of some level of lack of care/thought.
DTLS 1.3 is a huge improvement over 1.2 for efficiency and simplicity. I can’t speak to the OpenSSL implementation but it’s great that support is finally released.
https://github.com/openssl/openssl/blob/master/demos/dtlslis...
It would become much more practical if it were integrated with libuv or libevent.
0. https://www.libressl.org/
I've been linking a lot of stuff against boringssl during that time, I suppose...
A sad day. End of an era *salute*
i think a project like this would slough old architecture like mad and let major versions tick, but they forge on...
(Not a strange question given the recent PHP vulns found by AI.)