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

We have a year to fix security everywhere

jyn.dev

Post reply on HN
Print view View original

361–370 of 373 posts

Re: We have a year to fix security everywhere

#361

Post by bleuarff »

bigyabai wrote: post #336
bleuarff wrote: post #189

Earlier quoted context omitted.

The necessary IQ for destroying the world is dropping. Op does not say it's low enough today , but that will probably come sometime. Denying the possible harm these tools are capable of doesn't help.

It would be much harder to deny it if any of you were capable of describing the risks. The current discussion is a national-scale Handwavium mine.

If these systems allow anyone with an internet access or a few grands to run an open model to obtain the necessary information to e.g. build a bomb, spread an infectious agent, hack water or electrical infrastructures, I think that creates significant threats to the population.

Re: We have a year to fix security everywhere

#362

Post by ErroneousBosh »

sho wrote: post #359
ErroneousBosh wrote: post #328

Earlier quoted context omitted.

Every time I've asked an LLM to provide some code, it's given me an example from my own github repos. Granted, I've only asked it about some of the weirdly specific technological niche that my code inhabits.

Well that's funny, because you were making some pretty blanket statements upstream about how they "never" do this and "always" do that. And yet your experience seems extremely limited and niche, by your own admission. Maybe you should experiment a little more. I think you will quickly learn that your previous impression is wrong. The days of them being merely some sort of jumped up autocomplete are years gone.

Look, I know you believe in the Mystical GPU Sky Fairy, but AI is not in any sense "intelligent". It doesn't think. It's a pattern-matching system like an Eliza bot with a huge corpus to draw from.

It is not thinking. It cannot think. It cannot create.

Re: We have a year to fix security everywhere

#363

Post by orlp »

uecker wrote: post #272
orlp wrote: post #22

Earlier quoted context omitted.

Supply chain risks are essentially a solved problem. 1. Set a minimum age on dependencies: https://github.com/rust-lang/cargo/issues/15973 2. Scan all dependency code with AI Even if you don't do #2 yourself as long as anyone does in the age window you've set, you're protected. In the age of AI the "you can't read all dependency code" argument doesn't work anymore. On top of the above modern age argument, let's compa…

If I look at actual incidence involving memory safety issues compared to supply chain issues in general, it is the later which is much a higher risk to me. And yes, there were successful supply chain attacks on Rust developers, even just recently: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... despite this being a "solved" problem. I think this becomes worse with AI not better, while memory safety ri…

> If I look at actual incidence involving memory safety issues compared to supply chain issues in general, it is the later which is much a higher risk to me.

Again, can you even just name a single supply chain attack that was *shipped* in Rust software? Against the thousands and thousands of known memory vulnerability bugs throughout time?

> And yes, there were successful supply chain attacks on Rust developers, even just recently: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... despite this being a "solved" problem.

No, your linked blog post predates the brand-new min-age requirement. The minimum age would have prevented it, since it was detected by AI within an hour. If anything it supports my point.

Plus, as I already mentioned, that is a build.rs supply chain attack that targets developers, not shipped software.

Re: We have a year to fix security everywhere

#364

Post by mc-serious »

shelled wrote: post #202

I see a lot of people focused on servers and production environments, and of course that's needed, because that's business after all — but the personal computer seems to be absent from this discourse. Not everyone can buy a spare mac studio, and they might still need to install these tools on their personal computing devices, like their personal/home laptops. At that point, it's not even about whether a Claude Code,…

[flagged]

Re: We have a year to fix security everywhere

#365

Post by Shorel »

jcgl wrote: post #99
rukuu001 wrote: post #47

Earlier quoted context omitted.

A couple high-profile crash & burns will get their attention.

Just like well-publicized data breaches over the years got people’s attention? Color me skeptical.

The CEO of the company I work for is extremely paranoic about data breaches.

We do a lot of prevention and recovery testing.

So yes, it can happen.

Re: We have a year to fix security everywhere

#366

Post by a96 »

dbdr wrote: post #10

> Invest in formal verification, fuzzing and property testing, and memory-safe languages. LLMs are good at writing Lean and fuzz tests. I don't care whether you use Go or Rust but for the love of god please don't use C or C++ for new code. How accepted is this thinking in your respective domains?

Not sufficiently. Companies aren't keen on taking on new ideas unless it pays. Buzzword matchers only match old buzzwords. People in the trenches are too busy to try new stuff and/or don't want to push new things because of management or other obstacles.

Most products are built on top of legacy code after all. You stick to the tech that those contain.

Re: We have a year to fix security everywhere

#367

Post by a96 »

thunderfork wrote: post #3
hn_submit wrote: post #2

Or we could just dump Linux and Windows and switch to a microkernel operating system, which is much more secure. These endless patching cycles are simply not going to work in the long run. Operating systems get orphaned all the time, especially the ones in cheap Chinese stuff.

"throw away all software written before 2026" does technically solve this problem, if you ignore everything else the article is talking about (deployment and continuity of service)

Make that 2036 or whenever there might be a feasible microkernel available outside of niche applications. Better get started on that. Again.

Re: We have a year to fix security everywhere

#368

Post by lelanthran »

preg_match wrote: post #347
lelanthran wrote: post #335

Earlier quoted context omitted.

> The analogy I use is to physical tools. A screwdriver is simple, but building a house with only a screwdriver is complex. A suite of power tools is complex, but building a house with them is simple. The analogy I prefer is that it's safer to ride a bike down to the store than flying a space shuttle down to the store. [EDIT: Added trailing 'down to the store']

The absolute danger of a space shuttle is much greater than a bike. But the absolute danger of C++ versus C is… equivalent. All the suspicious memory things you can do in C++, you can do in C. In fact, with a couple more added in C (type punning via unions, for instance, is not standards compliant in C++, there are casts for that). That’s not to say C++ is a good language. It’s a rotten, no good evil language. And th…

> The absolute danger of a space shuttle is much greater than a bike. But the absolute danger of C++ versus C is… equivalent.

Okay, let's pretend, for the sake of this conversation, that the absolute danger in the event of failure for both the bike and the space shuttle are exactly the same.

My analogy still holds in this hypothetical case: the odds of a failure operating a space shuttle is much much larger than the odds of a failure when operating a bicycle. Using C++ is a much larger cognitive load than using C, same as launching and piloting a space shuttle is a much larger cognitive load than riding a bicycle.

It doesn't matter that the space shuttle has hundreds, if not thousands, of safeguards built into both the vehicle and the process, while the bicycle doesn't have so much as a seatbelt; the bicycle is still safer to operate because of the lower cognitive burden.

There are simply more rules to remember in C++ to ensure that you don't get exploited than in C. Ask the average working C++ devs about the danger between virtual vs concrete destructors in derived classes and half of them won't know what you mean. Ask about putting objects into a std vector, and maybe half of them will remember the surprise they felt when it first broke (because it worked until that point).

C++ provides global ways of avoiding footguns, but those global ways are not easily inspectable in the local scope. The problem is the sheer number of C++ footguns is simply overwhelming[1]. There's a handful of C footguns to commit to memory (signed overflows, used-after-free, etc), and they're all visually inspectable in the local scope.

When I need to a language better than C, I don't reach for C++.

------------------

[1] Even world-renowned C++ superstars with decades under their belt can't come back to it after a mere 2 years. You don't see that with C.

Re: We have a year to fix security everywhere

#369

Post by jcgl »

Shorel wrote: post #365
jcgl wrote: post #99

Earlier quoted context omitted.

Just like well-publicized data breaches over the years got people’s attention? Color me skeptical.

The CEO of the company I work for is extremely paranoic about data breaches. We do a lot of prevention and recovery testing. So yes, it can happen.

The world is a big place. Of course it happens. But, colloquially speaking, "getting people's attention" suggests that more than a rounding error took heed.

I'm glad your CEO cares. It makes a difference and I hope you feel good about that. And the world would be a better place if more did care. But, to a first approximation, it seems like organizations don't care about data breaches.

Re: We have a year to fix security everywhere

#370

Post by uecker »

orlp wrote: post #363
uecker wrote: post #272

Earlier quoted context omitted.

If I look at actual incidence involving memory safety issues compared to supply chain issues in general, it is the later which is much a higher risk to me. And yes, there were successful supply chain attacks on Rust developers, even just recently: https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on... despite this being a "solved" problem. I think this becomes worse with AI not better, while memory safety ri…

> If I look at actual incidence involving memory safety issues compared to supply chain issues in general, it is the later which is much a higher risk to me. Again, can you even just name a single supply chain attack that was *shipped* in Rust software? Against the thousands and thousands of known memory vulnerability bugs throughout time? > And yes, there were successful supply chain attacks on Rust developers, even…

Well, the affected arrayref crate was downloaded 2k times. It is also not the first case.

If AI magically finds all bugs in short time we have no problems anyhow. We also do not need Rust.

A minimum age requirement is a good thing, but also only some small step and certainly does "solve" supply chain issues just because it may have prevented this specific case.

Post reply on HN