[lelanthran]

> For EMV you had C connected directly to the network under a steady stream of attacks and only had an issue once? I find that hard to believe. What’s more likely is a Java websever frontend talking to some C processing / crypto

EMV terminals. No Java involved.

> As a famous quote states, it’s ok if your code has an uptime of 3 minutes until the first bug if the bomb explodes in 2

Look, first you commented that it's not possible for nontrivial or non-networked devices, now you're trivialising code that, if wrong, directly killed people!

All through the 80s, 90s and 2000s (and even now, believe it or not), the world was filled with millions and millions of devices programmed in C, and yet you did not live a life where all the devices around you routinely crashed.

Crs, Microwaves, security systems... they didn't routinely crash even though they were written in C.

[vlovich123]

EMV terminals are not under daily cybersecurity attack - you need to have physical access unless you designed your system weirdly. You probably had loads of vulnerabilities. But also depending on when you did it, all you had to process was a bar code which is also isn’t some super complicated task.

I’m not trivializing the safety of munitions. I’m attempting to highlight that safety and stability in a munitions context is very different and memory safety issues could easily exist without you realizing. My overall point is that you are silently making the argument that C programmers (or programmers in general) used to be better, which is a wild argument to be making about a culture in which fuzzing didn’t even exist as a concept. You’re also confusing memory safety with implying a crash. That simply isn’t the case - it’s more often exploitable as a security vulnerability than an immediate crash by violating assumptions made that weren’t in the happy path of those microwaves and security systems. That millions of devices were and still are routinely exploitable.

You’re also making a fallacious line of reasoning that the C today is the same C that was in use in the 80s, 90s, and 2000s. It’s not and has gotten harder and more dangerous because a) multi threading became more of a thing and b) compiler authors started exploiting “undefined” behaviors for extra optimization.

It’s just wild for me to encounter someone who believes C is a safe language and is suitable to connect to I/O too when there’s so many anecdotal and wide statistical evidence gathered that that’s not the case. Even SQLite, the darling of the C community, is not safe if asked to open arbitrary SQLite files - there’s various security attacks known and possible.

[lelanthran]

> EMV terminals are not under daily cybersecurity attack - you need to have physical access unless you designed your system weirdly.

They are under daily attack - in public, at tills, operated by minimum-wage earners.

> You probably had loads of vulnerabilities.

Sure. Hundreds of thousands of terminals sitting in the field, networked, under the control of minimum wage employees, each holding credit card details for hundreds of cards at a time...

Yeah, you're right, not a target at all!

> But also depending on when you did it, all you had to process was a bar code which is also isn’t some super complicated task.

You are hopelessly naive. Even in the magstripe era, certification was not easy.

> It’s just wild for me to encounter someone who believes C is a safe language

When did you meet this person?

Look, the bottom line is, the errors due to memory safety in programs written in C is so small it's a rounding error. It's not even statistical noise. You spent your life surrounded by these programs that, if they went wrong, would kill you, and yet here you are, not only arguing from a place of ignorance, you are reveling in it.

Just out of interest, have you ever used an LLM to write code for you?

[vlovich123]

Physical attacks are difficult to pull off at scale, especially anonymously. There’s a huge evidence trail linking the people involved to the scheme. And a device being in the hands of a minimum wage employee is very different from a bored and talented and highly skilled person probing your software remotely. Now who’s naive?

As for certification and it being difficult, what does that have to do with the process of bread in Paris? Unless you’re somehow equating certification with a stamp of vulnerability imperviousness in which case you’re seeing your own naivete instead of in others. Btw, Target was fully certified and fully had their payment system breached. Not through the terminals but through the PoS backend. And as for “but you’re here living and breathing”, there’s constant security breaches through whatever hole, memory safety or otherwise. Persistent access into the network is generally only obtainable through credential compromise or memory safety.

> When did you meet this person?

You. You’re here claiming that memory safety issues are statistical noise yet every cloud software I’ve seen deployed regularly had them in the field, sometimes even letting a bad one through to canary. And memory safety issues persisted despite repeated attempts to fix issues and you couldn’t even know if it was legitimately an issue or just a HW flaw due to being deployed at scale enough that you were observing bad components. It’s a real problem and claiming it’s statistical noise ignores the consequences of even one such issue being easily accessible.

[lelanthran]

> You. You’re here claiming that memory safety issues are statistical noise yet

Claiming that the exploit rate percentage is statistical noise is different from claiming that it's a safe language.

Looks like you have a premade argument to argue.

You haven't answered my question, though: Have you used LLMs to generate any code for yourself?