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.
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.
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.
> 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.
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.
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.
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.
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.
>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?
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.
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.
Unnecessarily complicated APIs are a security code smell precisely because they help hide bugs, leaky abstractions, insecure state, and other exploitable issues.
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.
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.
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.
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.
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)."
haunter 1 day ago
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 1 day ago
mixdup 1 day ago
mondainx 1 day ago
jasomill 21 hours ago
Meanwhile, ISO images of software currently used in production have been memory-holed to free up space on a multiterabyte SAN.
tosti 18 hours ago
p_l 1 day ago
0c3ca83 1 day ago
https://github.com/openssl/openssl/blob/c69b5af10a754051274e...
fweimer 1 day ago
“ 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...
jasomill 21 hours ago
nirui 1 day ago
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 1 day ago
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 1 day ago
masfuerte 1 day ago
CodesInChaos 1 day ago
egorfine 1 day ago
hannob 1 day ago
Context: https://cryptography.io/en/latest/statements/state-of-openss...
dralley 1 day ago
Still a shame that it went backwards.
hannob 1 day ago
ahartmetz 1 day ago
Surely they thought of it but didn't say it out loud... to keep it exploitable, maybe?
hannob 1 day ago
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 12 hours ago
How noob exactly are the people working on... checks notes... OpenSSL for crying out loud?! These are beginner's mistakes.
woodruffw 1 day ago
Source: I am friends with the maintainers who wrote this and was one of the people who reviewed it in draft form.
pseudosaid 1 day ago
woodruffw 1 day ago
noitpmeder 1 day ago
palata 1 day ago
timschmidt 1 day ago
palata 1 day ago
timschmidt 1 day ago
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 1 day ago
timschmidt 1 day ago
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.
woodruffw 1 day ago
timschmidt 1 day ago
thayne 1 day ago
woodruffw 1 day ago
timschmidt 1 day ago
incanus77 1 day ago