Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Case for Memory Safe Roadmaps

nsa.gov

Post reply on HN
Print view View original

131–140 of 427 posts

Re: The Case for Memory Safe Roadmaps

#131

Post by kelipso »

czbond wrote: post #50
merpnderp wrote: post #12

Earlier quoted context omitted.

Why is Python listed there and not other languages like Ruby, Javascript or Perl?

Commenting bc I had the same question. My impression of historical Python is that is an old, partially arcane language that due to D.S/AI is now popular; I would initially think it would be no better than those other interpreted. Python does these things well... mainly due to pandas/dataframes/polars.

Language wise, Python is basically just Perl with its arms cut off and bunch of makeup added. It's just very popular in the scientific community, so they have to add it.

Re: The Case for Memory Safe Roadmaps

#132

Post by OrvalWintermute »

theandrewbailey wrote: post #108
wodow wrote: post #6

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

In unrelated news, security researchers have discovered a new class of vulnerabilities common to all memory safe languages

;)

Re: The Case for Memory Safe Roadmaps

#133

Post by phkahler »

lambdaone wrote: post #59

"Undefined behavior" in general is a nightmare. After memory safety, the next target should be the enforcement of underflow/overflow trapping. With the exception of the intentional use to implement modular arithmetic, underflow/overflow should always be an error condition.

>> the next target should be the enforcement of underflow/overflow trapping

Trapping is nonsense - in production anyway. You might use it in development to catch errors. But in production there is no way to "fix" an overflow if it happens and is detected, so you'd be looking to crash on trap which in some code is preferable to silent data corruption.

I do lots of fixed-point math for embedded motor control. Representing rotor angle as a signed 16bit number is deeply engrained in me these days because taking differences to get a signed delta just works, and I never have to worry about rollover because it behaves exactly the way I want. ;-) While this is technically undefined behavior, I've never run across a compiler that worked differently.

Re: The Case for Memory Safe Roadmaps

#135

Post by chasil »

jerf wrote: post #110
DeathArrow wrote: post #55

Earlier quoted context omitted.

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

SQLite is able to carry most of the justification for C itself at this point.

Duplicating the DO-178B certification that it has obtained in an endorsed language will be an incredible burden for any who attempt it.

Re: The Case for Memory Safe Roadmaps

#136

Post by jvanderbot »

seanw444 wrote: post #74
CJefferson wrote: post #36

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

The wild west had a lot less danger and death than Hollywood makes it out to seem. Likewise, I'm going to miss the internet and computing as we know it now when it's regulated to shit like everything else. Nothing nice ever lasts. Complete safety, or actual freedom. Pick one. You can't have both.

> Pick one

Or, maybe pick a point on a spectrum.

That seems more realistic, because I'd argue you can't really have "Complete Safety" or "Actual Freedom" (by which I am guessing some people would interpret 'actual' as 'complete').

Re: The Case for Memory Safe Roadmaps

#138

Post by champagnepapi »

marcosdumay wrote: post #119
champagnepapi wrote: post #31

But how are we going to trade stocks in nano seconds without C++?!

High speed fiance is mostly done in Java and Haskell, because mistakes are expensive. (And yeah, it's one of the very few fields that Haskell enters the list.)

oh wow! I had no idea at all. I'll have to read more about this :)

Re: The Case for Memory Safe Roadmaps

#139

Post by cryptos »

jmclnx wrote: post #32

I advise training programmers instead of throwing them in front of a screen without any training. Companies these days provides no training at all. When I was hired over 40 years ago, I spent plenty of time being trained for my first 3 months. Now, nothing, and you if you want to train a new person, you do it on your own time.

Training and technical security measures shouldn't be treated as alternatives. Even trained programmers produce bugs and security issues, if at least some of them can be prevented by an additional safety net, then it would be stupid not to use it.

Re: The Case for Memory Safe Roadmaps

#140

Post by KMag »

helsinkiandrew wrote: post #94
DeathArrow wrote: post #55

Earlier quoted context omitted.

>Really, the only memory unsafe languages still in use are C and C++. Ada, Fortran, assembly?

Fortran is probably as bad as C, and Ada isn't truly memory safe - they link to Ada/Spark which is but that doesn't seem to have much widespread use. https://www.adacore.com/about-spark

Isn't Ada/Spark in avionics the main use case for Ada these days? So, huge share of a tiny market?
Post reply on HN