top | item 44915397

(no title)

drumnerd | 6 months ago

I would never ever let an LLM anywhere near C code. If you need help from LLM to write a NIF that performs basic C calls to the OS, you probably can’t check if it’s safe. I mean, it needs at least to pass valgrind.

discuss

order

simonw|6 months ago

You can use something like Claude Code or Codex CLI and tell it to run valgrind as part of iterating on the code.

faangguyindia|6 months ago

how does it work? does it shell out to subagent? or it has full access to cli? what makes it not perform rm -rf /

overbring_labs|6 months ago

I mean, you aren't wrong. I'm looking into converting it into Rust with Rustler right now.

abrookewood|6 months ago

Yep, was wondering why you didn't go down that path in the first place. Seems way safer.

true_religion|6 months ago

Security is a spectrum. If you totally control the input going into a program, it can be safe even if you didn't test it for memory leaks. The only errors that occur will be truly erroneous, not malicious and for many solutions that's fine.

At the very least, it's fine for personal projects which is something I'm getting into more and more: remembering that computers were meant to create convenience, so writing small programs to make life easier.

Alive-in-2025|6 months ago

For personal projects, ok security is different. But get out of that, and I'd do it even for that, you need defense in depth. You think you sanitized your input but your C program has a bug and a vulnerability - or your Java program or whatever has bugs. Almost everything has some bugs, and thus your vulnerabilities will hit eventually in your C program, even if you were careful.

I'd say absent some temporary hack to do something, my bad experiences won't let me say something is low risk. I worked at Microsoft years ago, and after the zillions of vulnerabilities were attacked by people around the time of windows 95 and computers on the net, we did serious code reviews in my team of the data access libraries. There were vast numbers of vulnerabilities. A group of 3 or 4 of us would sit in a room for 3 hours a day, one person a scribe, and we'd go over this c code that was ancient even then - we found problems everywhere, it was exhausting and shocking. The entire data access infrastructure was riddled with memory leaks, strings that were not length limited, input parameters that were not checked or sanitized, etc. I'm sure it was endemic across all components, not just there. We fixed some things, but we found so much shit.

Thank got I wasn't on the team trying to figure out what to do about those problems. I think they end of lifed a lot of stuff.

Ygg2|6 months ago

> Security is a spectrum.

It's less spectrum and more that it's relative. Depends on attacker and what they seek to gain.

An unsecured server is an unsecured server. But there is a world of difference if they are attacked by CIA or local script kiddies.

rs186|6 months ago

Outside personal projects, my take is that security really just comes in two flavors: CVE vs no CVE. I pick the former.