Hacker News Reader

Rewriting isn't the solution to everything, unless the code is really small and well-contained.

High-profile security bugs were found in programs written in C# and Java and every other "safe" language out there.

The unknown-unknowns are often far worse than what you currently have. Check the Uber Swift rewrite horror that was posted last week, and that was a super tiny app compared to even the smallest Office app.

Another critical factor is: C++ is currently the only true "portable" language out there, that can be compiled into Windows/Mac/iOS/Android and everything else that exists or will come up in the future. Nothing else comes even close in terms of native platform support. And its completely unrealistic to have copies with different languages for each platform like "small" apps do like Uber or Facebook. We're talking about business logic that if it isn't exactly the same everywhere (with its bugs), people can lose billions of dollars.

Even if Rust can compile into all of those platforms, I assure you, there will be dozens of very serious compiler bugs that will be uncovered over time if an app the size of Office gets rewritten into it. A good number of those will be of serious security consequences. Hell, back in the day, Excel had its own C++ compiler because of compiler bugs that couldn't be fixed on time!

> C++ is currently the only true "portable" language out there,

I thought that was C? Or am I misunderstanding, and you're using C++ because it's more advanced and can still be used anywhere C can?

Microsoft is somewhat notorious for not correctly supporting C in Visual Studio. There's MinGW, which basically works, but it arguably doesn't count as 'native' support.

I've heard people claim that recent versions of VS are better, but I've also heard people claim that they just corrupted the standards process to get everything they didn't support relegated to optional extensions, so... [shrug].

you can also use clang these days without MinGW AFAIK

Yes, you're right, C is more accurate, tho C has been getting more and more C++ features over time.

You don't even have to go as far as compiler bugs, there WILL be application bugs after a rewrite.

Rewriting in Rust, however, would likely introduce many new bugs, as most rewrites do. The economics of it would be terrible.

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.

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.

> 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.

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.

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.

If you think that rewriting huge legacy software that's powering most of the world in a current hot language is a solution to security issues, you clearly have no idea about software security.

>These products should be rewritten in a safer language, like Rust.

Sorry, but get over yourself. Firstly, if stuff had been written in Rust it would have been written 30 years after it was relevant. Secondly, if you're expecting companies to re-write code after 30 years to make it safer and do a good job? Good luck. There's a handful of people on the planet capable of doing it, there's a handful of people on the planet willing to do it, and there's 0 overlap between the two.

If these companies were seriously held accountable for bug free code, there wouldn't be better code, there would be a lot less code. Entire applications just wouldn't exist. Dozens of products would've died due to dev costs.

> potential security issue

> rewrite entire codebase