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

221–230 of 427 posts

Re: The Case for Memory Safe Roadmaps

#221

Post by MobiusHorizons »

phkahler wrote: post #161
Alifatisk wrote: post #104

Earlier quoted context omitted.

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?

No offense to Ruby, but if I were going to push people to change to a new language I would not recommend Ruby. It had its time of popularity and I feel like it's just a niche language now, surpassed by others.

From a memory safety perspective, I would say the same about python. The libraries that make it popular are all written in c++ to my knowledge. Anyone not already using python usually has better tools to choose from these days.

Re: The Case for Memory Safe Roadmaps

#222

Post by UncleMeat »

2devnull wrote: post #154
slimsag wrote: post #80

Earlier quoted context omitted.

Well, there are groups that want a government mandate for this, though. If you don't know, Consumer Reports is paid by groups interested in encouraging the government to apply regulations to certain areas. A bike helmet manufacturer may pay them to create a report, host events, and otherwise lobby on their behalf to e.g. create regulations about people needing to use bike helmets. It is my understanding that many Rus…

Rust programmers want the government dollarinos? Amazing. It did feel a bit coordinated.

"${LANGUAGE} programmers" aren't really a thing. Our important skills translate fairly cleanly between ecosystems.

Re: The Case for Memory Safe Roadmaps

#223

Post by dylan604 »

datameta wrote: post #208
osigurdson wrote: post #156

Earlier quoted context omitted.

We will see. I suspect things will not turn out as expected.

There might be a layer of humor you didn't pick up on.

or that this hype about the tech replacing programmers is not going to pan out. so maybe it is you who didn't pick up on something? to be able to provide commentary on a joke does not mean the joke was missed

Re: The Case for Memory Safe Roadmaps

#224

Post by BaculumMeumEst »

In the world of graphics programming, you've got:

- continuing accumulation of documentation and utility libraries from Khronos

- excellent learning materials from the community

- tons of legacy code

all using C++.

https://github.com/KhronosGroup/Vulkan-Utility-Libraries

https://github.com/cg-tuwien/VulkanLaunchpad

https://cescg.org/our-services/an-introduction-to-vulkan/

Until I see professionals get funding to build, maintain, document, and create training materials for Rust bindings, I'm going to continue to assume there will not be movement in that sector. I don't think industry is going to throw away the C++ ecosystem and build greenfield projects on a foundation of hobby projects.

Re: The Case for Memory Safe Roadmaps

#225

Post by hackideiomat »

RhodesianHunter wrote: post #157
anthk wrote: post #111

Earlier quoted context omitted.

>Java Java it's a pest fest for exploits. From those, I'd choose Go, C# (and not totally sure because of AOT/JIT's) and Rust.

>Java it's a pest fest for exploits. Sure, if you haven't used it since the nineties and pay zero attention to new development.

Right, there haven't been crazy Java exploits going around the past few months, only Rust and Go!

Re: The Case for Memory Safe Roadmaps

#226

Post by avgcorrection »

natsucks wrote: post #163
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.

"In attempts to mitigate the dangers of memory unsafe code in C and C++, many software manufacturers invest in training programs for their developers. Many of these training programs include tactics designed to reduce the prevalence of memory unsafe vulnerabilities produced by those languages. Additionally, there are numerous commercial and industry trade association training programs. Further, various organizations…

But what’s your point? Do we expect each other to read the submission (the report) or something? :)

Re: The Case for Memory Safe Roadmaps

#227

Post by matthewdgreen »

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…

What I don't understand is the excitement for using Rust vs. using garbage collected languages like Golang, at least for high-level applications (performant or low-level systems applications are excepted here.) My experience is that an experienced programmer can be a lot more productive quickly with Golang, since they don't need to climb the Rust borrow-checking learning curve. Rust doesn't even free you from the need for a runtime or standard library.

Re: The Case for Memory Safe Roadmaps

#228

Post by sneed_chucker »

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

As I understand, there's a very long tail of continued Ada use in military and aviation.

So depends on your definition of "dead"

Re: The Case for Memory Safe Roadmaps

#229

Post by jonnytran »

Thaxll wrote: post #175
jonnytran wrote: post #96

Earlier quoted context omitted.

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

Go is memory safe, that post does not means anything in real life scenario. Do you have a single example in the last 14 years of memory safety exploit using the Go runtime? I'm talking about public and known exploit not ctf and the like.

The same author has a post from 2022 [1].

> Is it possible to achieve arbitrary code execution on any Go version, even with PIE, and with no package import at all, just builtins? Yes!

Whether it's capture the flag is irrelevant, IMO, because anything that's allowed by the compiler will emerge given enough complexity.

1: https://blog.stalkr.net/2022/01/universal-go-exploit-using-d...

Re: The Case for Memory Safe Roadmaps

#230

Post by estebank »

pier25 wrote: post #198
Filligree wrote: post #79

Earlier quoted context omitted.

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.

A specially crafted networking package or file can cause a vulnerable application to get confused enough to interpret input meant to represent data as binary code to be executed. If you have an application that doesn't interact with any inputs, yes, you can avoid a lot of exploits. If the vulnerable application runs in a server, you might be temporarily safe in your local machine, until that server starts being used as a delivery mechanism against all its clients.
Post reply on HN