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

191–200 of 427 posts

Re: The Case for Memory Safe Roadmaps

#191

Post by disgruntledphd2 »

synergy20 wrote: post #68
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.

absolutely correct, in fact now some new hires are expected to do a few git-commit the first day(looking at you, Meta). no wonder so many bugs here and there.

> absolutely correct, in fact now some new hires are expected to do a few git-commit the first day(looking at you, Meta).

Meta have a phenomenally good training program, called Bootcamp for basically everyone in engineering, so they're probably not the example you're looking for.

Re: The Case for Memory Safe Roadmaps

#192

Post by gsuuon »

andromeduck wrote: post #57
czbond wrote: post #50

Earlier quoted context omitted.

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.

Python replaced Matlab too.

I think the familiarity when moving from Matlab to Python helps a lot with adoption.

Re: The Case for Memory Safe Roadmaps

#193

Post by corethree »

School-Cotton wrote: post #181
jvanderbot wrote: post #151

Earlier quoted context omitted.

Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Ru…

Rust is memory safe by default, with unsafety as an optional feature that you basically never need to use unless you’re writing extremely low-level code, need absolute maximum performance, or are interfacing with libraries written in other languages. C++ is unsafe by default. Of course it’s just as easy to write bugs in unsafe Rust as it is in C++ (actually, it’s probably even easier), but defaults matter.

No I've seen libraries that need the user to use it by default. The wgpu library is one example. It's not even that low level. Rust stuff is a little too safe that it influences code organization and modularity as well.

Re: The Case for Memory Safe Roadmaps

#194

Post by ahmedfromtunis »

How about a new drop-in replacement language for c/c++?

I'm in no way an expert in any aspect that relates to this problem, but it's reasonable to believe that it would be but a mildly challenging task if companies like Google, meta, Microsoft and the likes joined forces.

A year of concentrated efforts might be sufficient to rid us with this problem once and for all. Billions of lines of codes would gain (some) safety instantly.

Re: The Case for Memory Safe Roadmaps

#195

Post by timbit42 »

local_crmdgeon wrote: post #90
projektfu wrote: post #44

Earlier quoted context omitted.

Ada people scratching their heads....

How many of them are left? I thought it was very much a dead language

It's still very popular in air traffic control. Some older NASA and military projects used it and are still in use.

Re: The Case for Memory Safe Roadmaps

#196

Post by bumby »

none_to_remain wrote: post #48
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.

People figured out how to build buildings prior to creating building codes

Define "figured out." Did people know how to cobble together a structure? Of course. Did they inherently know all the best practices that reasonably balance safety, cost, and timeliness? Probably not.

The same can be applied to software. An ability to cobble together a "Hello World" does not necessarily mean I want you programming a controls system on a nuclear power plant.

Re: The Case for Memory Safe Roadmaps

#197

Post by zozbot234 »

jonnytran wrote: post #96
wodow wrote: post #6

Their "Appendix: Memory Safe Languages" lists: C#, Go, Java, Python, Rust & Swift

It's unfortunate that there's no mention that not all these languages are equally safe. Go isn't memory safe when using goroutines. See: Golang data races to break memory safety: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

It's not safe when using goroutines to access shared mutable data (and most Go code does this). If you stick to message passing a.k.a. "share data by communicating" you don't run into memory unsafety. But this kind of design is more vulnerable to other concurrency issues, viz. race conditions and deadlocks.

Re: The Case for Memory Safe Roadmaps

#198

Post by pier25 »

Filligree wrote: post #79
pier25 wrote: post #53

Correct me if I'm wrong... But don't these types of memory attacks require local access to the machine?

Absolutely not. You’re confusing it for Spectre, probably.

The article mentions:

> Memory safety vulnerabilities are coding errors affecting software’s memory management code in which memory can be accessed, written, allocated, or deallocated in unintended ways.

How can you do any of this without software running in the local machine?

Honestly asking.

Re: The Case for Memory Safe Roadmaps

#199

Post by UncleMeat »

jvanderbot wrote: post #151
jerf wrote: post #22

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

Why are C and C++ considered the same, in these conversations? C++ at least has tools to make life significantly more safe. I can write a buffer overflow in any language, and on the scale of difficulty, ASM-C-C++-Rust-Python covers my experience (from easiest to fuck up to hardest). Yet nobody is calling for us to rewrite everything in python. Why is the line drawn at Rust? It's perfectly simple to trash memory in Ru…

People are calling for the use of languages like java or python when it is appropriate. Rust is just specifically mentioned (along with Swift, to some degree) when it comes to applications that have a couple of fundamental requirements that prevent the use of other languages. These might be requirements like no pausing for GC or the ability to run without a VM.

Rust (and Swift) are viable languages for solving most problems that people usually reach for C or C++ to solve today and both make it considerably more difficult, by default, to introduce the most common class of serious security vulnerabilities in the modern world.

Re: The Case for Memory Safe Roadmaps

#200

Post by VikingCoder »

osigurdson wrote: post #147
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.

I think people should take responsibility for their own awesomeness.

I think you do not appreciate that some people have jobs that don't give them adequate support to be awesome.

I just watched the most recent Last Week Tonight, where they went in depth on Freight Trains [1]. Specifically they talked about 3 mile long trains that currently only have two operators - one conductor and one engineer - and the industry is trying to cut it down to one.

That's just an analogy for software development. But I've definitely seen people be over-worked and under-supported.

[1]: https://www.youtube.com/watch?v=AJ2keSJzYyY

Post reply on HN