Yes, fixing security bugs may introduce functionality bugs. But that's not a reason to not fix security bugs. Yes, the economics of it would not be great, which is why these companies are not already doing it. But someone else is paying the price, when information systems are compromised and data is stolen. We have to exact a heavy penalty on tech companies each time that happens, until the penalties change the economics.

What's the bigger threat - a theoretical unknown vulnerability in Excel or very real consequence of the entire economy and government grinding to a halt when their Excel macros and Word 97 VBA don't work with the rewritten codebase?

You don't rewrite the entire codebase overnight, or even in a single release. Instead, rewrite 10% of the code in 1 year, and within 10 years the entire product will be rewritten.

You have no idea of the size or complexity of the Office codebase. It's enormous and external developers have taken hard dependencies on every aspect of it, even undocumented behavior. Therr aren't enough Rust experts in the world, much less at Microsoft, to review code changes at that rate.

https://devblogs.microsoft.com/oldnewthing/20031224-00/?p=41... - there are probably just as many companies relying on old Office docs as old Windows programs at this point

Rewrites are always a bad idea. https://www.joelonsoftware.com/2000/04/06/things-you-should-...

So leave it to customers to deal with security breaches arising from use of your software, in perpetuity?

You fix things as they are discovered, continue adding more static analysis to catch new classes of issue, and continue on. You don't rewrite - certainly not in a new language with all new problems.

This isn't a startup with 10 developers - there are literally thousands of developers working on Office and all sorts of internal tooling built around the codebase.

> You fix things as they are discovered

This will keep companies like NSO in business for decades to come.

> there are literally thousands of developers working on Office and all sorts of internal tooling built around the codebase

That's no excuse for the security hacks this codebase is enabling. They need to stop adding new features for a decade, if that's what it takes, in order to fix the security issues. Think of all the ransomware attacks, identity theft, attacks on journalists, and democracy even, that the security issues in this codebase is enabling, and will continue to enable if business-as-usual is the way forward. The stakes are high, and these tech companies must be made to pay a heavy price for each security breach enabled by their negligence, and then the economics will be in favor of prioritizing security over features.

No, what they (we) need is to be held accountable for the software we build, just like engineers are accountable for what they build.

Fixing security bugs by changing everything may also introduce new security bugs.

If you hesitate to fix security bugs out of fear of introducing new security bugs that's the point at which you have to hire better programmers.

But you're going to introduce them anyway. Sure, hire the best programmers that you can. But recognize that your rewrite is going to introduce new bugs (funny, your answer to that was "deal with it" instead of "hire better programmers"). And recognize that, better programmers or no, some of those new bugs are going to be security bugs.

Now, that may still be better than the current situation. But glibly saying "just hire better programmers" means you're hiding your head in the sand.

Taking precautions can always backfire but would you argue that the status quo is preferable to taking those precautions in this case?

flowerlad seems to have the position that only security bugs matter; other bugs can be dealt with. I disagree with that position - non-security bugs can also be devastating. Second, even if you accept the starting position, I disagree with the idea that re-writing C++ code in Rust will remove all the security bugs.

So there's two categories of "taking those precautions". One is "fix security bugs", which, yes, of course take those precautions.

But the second category of "taking those precautions" is "re-write the whole thing in Rust". That's much more questionable whether it's worth it. How much time and effort will the rewrite take? What else could those people do with that much time? How bad are the security holes? How bad will it be to introduce the new bugs? What fraction of security holes will be closed by the rewrite?

flowerlad's idea seems to be that, in light of this latest attack, it's worth going to any lengths to fix every security hole. I think that idea is mistaken.

And, which software are we talking about? The network stack? Excel? Everything ever written in C/C++? The trade-offs are different for each piece of software. And if the answer is "everything", that sounds like roughly a decade of work for the entire software engineering workforce. That seems totally unrealistic, even in light of this latest attack.

Look, the attack was huge. I'm not trying to minimize it at all. But it still isn't worth the measures that flowerlad proposes.

> If you hesitate to fix security bugs out of fear of introducing new security bugs

I never say that. But maybe you just don't need to rewrite the whole project to fix some bugs? Sometime it is maybe the right answer but it should not be the default answer.