Thanks but still sticking to C++...
The Case for Memory Safe Roadmaps
101–110 of 427 posts
Re: The Case for Memory Safe Roadmaps
#102Earlier quoted context omitted.
It is, but it doesn't mean folks won't.
I don't understand the point you're trying to make. You're the person who wrote it would be mandated, and now you're admitting it's a ridiculous position to take. If you have some point to make please do so earnestly. Layering in levels of irony makes any point you're trying to make difficult to understand or follow, even if labelled with /s. This is going off-topic, but there is a style of internet arguing that I ha…
I guess the GP is trying to say that those languages will enter the compliance checklist of some unavoidable rule, and that recommendation will turn into an effective mandate.
What is a quite real possibility. For example, there are plenty of places out there that can't stop expiring passwords every 1 or 3 months because it's in one of those lists. But I do agree that complaining about the recommendation because of this is completely out of topic, the focus should be on the rule that actually mandates it.
Re: The Case for Memory Safe Roadmaps
#103Re: The Case for Memory Safe Roadmaps
#104Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift
Why is Python listed there and not other languages like Ruby, Javascript or Perl?
I don't think Ruby is used a lot at NSA, other than that, it's weird that it did not get mentioned.
They should've instead just said Python and languages alike?
Re: The Case for Memory Safe Roadmaps
#105Can someone explain why we can't double-down on C++ and, through compiler wizardry and reduction in toolset (say, strings can only be fixed-size at 32 chars, 64, or 256 long. No raw pointers, allocator zeroes out all freed memory), achieve a memory-safe language?
Obviously, making certain concessions would be a deal-breaker for some, but it might be viable for legacy codebases. If you were to try to make C++ memory-safe, where does it begin to break down?
Re: The Case for Memory Safe Roadmaps
#106Ah, they must have found an exploit in Rust then
Re: The Case for Memory Safe Roadmaps
#107Earlier quoted context omitted.
Next thing they'll be giving requirements for people building bridges, houses, and gas and electricity fittings. Seriously, I think the time has long since passed software needs regulating. It's a major part of modern society, and as far as I'm aware, most people aren't opposed to building standards in principle.
People figured out how to build buildings prior to creating building codes
Re: The Case for Memory Safe Roadmaps
#108Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift
Conspiracy: The NSA has compromised the runtimes of those languages to run arbitrary payloads and spy on everything that runs through them. I mean, "catch terrorists".
Re: The Case for Memory Safe Roadmaps
#109Earlier quoted context omitted.
Crossing an air gap hasn't stopped a determined attacker in the past: https://en.m.wikipedia.org/wiki/Stuxnet
Let's be real. Creating an air gap hasn't stopped a very few, unlimited resource, APTs. Don't let perfect be the enemy of good enough.
To really be real if air-gapping is a significant mitigation for your risk profile then you are likely the target of one of those rare APT's. You should probably also be using a memory safe language if you think you need air gapping.
Re: The Case for Memory Safe Roadmaps
#110Earlier quoted context omitted.
Really, the only memory unsafe languages still in use are C and C++. If it weren't for the behemoth of legacy code we'd really have this problem more-or-less licked. Unfortunately, that behemoth is still rampaging across the landscape. "Rewrite it in Rust" gets a bit of pushback, perhaps even justified, but at this point in time I'll take anything that just reduces that behemoth in size. The journey of a thousand mil…
>Really, the only memory unsafe languages still in use are C and C++. Ada, Fortran, assembly?
Fortran does not end up where I'm too worried about its security. C and C++ does. At the scale I'm talking about I'm not sure we'd even say Fortran is "in use".
Assembly is in use, yes, but in 2023 I feel there is generally an understanding of the risks and I haven't seen the "write everything in assembly" crew in about 15 years. The problem is that there's still too many programmers blithely using C and C++ without realizing the risks and thinking they can cowboy through the problems. For every line of vulnerable, dangerous assembly I bet there's thousands of lines of C or C++.
There is also the problem that there have been some big bugs that got through even static analysis and fuzz testing, but I'd still be at least reasonably satisfied if all the critical software in C and C++ would be supported by those tools. Interpreters and compilers have had non-zero error rates too.
At the scale I'm talking about, Ada is a non-entity as well. It isn't used. "But it is! I'm a professional Ada programmer!" says someone reading this to themselves. In which case I would say, you darned well know what I mean and don't pretend otherwise just to try to score useless internet points. Ada is not a relevant force on the programming world. That may be sad, but it's true.