Hacker Newsnew | past | comments | ask | show | jobs | submit | tom_'s commentslogin


Tough crowd, but I for one hate this stuff too and thank you for the heads up. "Engraved invitation to chaos", fucking hell. I think I just lost 3 IQ points. Who's the target audience here?

Everything I needed to know about printf, I learned from the reference manual. Anybody could do the same. Here's a reasonable one: https://en.cppreference.com/c/io/fprintf - look, it's like 5 pages or whatever, and the last 2 are examples and xrefs. You sit there and read it 2 or 3 times and you'd be done faster than Task Manager Man can read his script.


> The affected releases include iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, and macOS Tahoe 26.5.

Where does this quote come from? I can't see it in https://support.apple.com/en-us/127115, the article link at time of writing. It mentions CVE-2026-28952, but we're forced to guess why. I'd take the reference to mean that this issue is fixed, but I'm just some internet rando, so what the hell do I know?

If I do a google search for "CVE-2026-28952", it points me to various pages. Here's one, for example: https://www.cve.org/CVERecord?id=CVE-2026-28952 - which is a bit more explicit, though of course this is not from the horse's mouth:

> This issue is fixed in iOS 18.7.9 and iPadOS 18.7.9, macOS Sequoia 15.7.7, macOS Sonoma 14.8.7, macOS Tahoe 26.5


Because it's const void *pa, you don't need the cast. A void * pointer will convert to any other kind of pointer. Now you only need to mention the type once. (I forget the const-related rules, but since the consts match in this case I don't think it'll be relevant.)

Is that even the fix though? The problem sizeof*groups expression has already been removed by that point. This fixes something but it's not obviously related to the vulnerability description.

git log -S suggests 4cd93df95e697942adf0ff038fc8f357cbb07cf9, which looks more likely: https://cgit.freebsd.org/src/commit/?id=4cd93df95e697942adf0... - though not to say you don't want the later commit too. I'm sure you do.


What if there is no long game? Just people at Google optimising for their current KPIs.

It's more likely that it isn't coincidental at all: software development-oriented LLMs became a lot better towards the end of 2025, and so there's a non-zero chance that people are using them to find new security exploits.

(People are not sleeping on this and it is not something people have failed to notice. I don't use LLMs at all and even I have noticed it - largely because there is approximately nobody that isn't talking about it.)


I think the other side is much more important. With company mandates to use AI as much as possible, there has been a deluge of low-quality PRs. Everybody is feeling tired from reviewing those, and quite possibly numerous security issues have been introduced since.

The most dangerous is where the new feature works well and is using safe APIs, but integration is quietly broken somewhere. The risk of incoherent state is way higher because you no longer have a small set of people that knows the complete theory of the software and can find discrepancies.

Ahh, that's a good point, and I actually hadn't thought of that angle! I was thinking of it purely from the point of view of the attackers using LLMs to generate interesting new exploits, with a side helping of letting myself get mildly annoyed, possibly incorrectly, by the writing style.

But yes, it's also possible the defenders have been kind of forced into having the slop machine shit out a huge pile of shit-ass changes, one way or another, that end up making the attackers' job even easier. (Even assuming no mechanisation at their end! Which is of course in nearly-June of 2026, probably unrealistic. And LLMs do appear to be really quite good at that side of the equation...)


This really feels like what's happening where i work. Management wants everything done yesterday. Juniors and seniors alike are giving me pure slop PRs to review. I point out an issue and the next draft from Claude has two more. It's extremely exhausting, and it's not like I'm reviewing every PR or catching every issue.

I was trying to go against the tide for the longest time by providing detailed reviews, understanding every line of code, leave meaningful comments, improve architecture, etc.. Then management started pushing AI more and more and explicitly called out PR reviews as a bottleneck, timelines shortened, and more and more slop got pushed.

I gave up and I'm now a happy "AI enthusiast" at my company, handing out AI slop reviews for AI slop PRs. Deep down, I don't care anymore, if that's what they want, that's what they'll get, and it's no longer my problem if stuff leaks through that brings down prod or worse. Oh, and I'm also in line for a promotion this coming quarter thanks to my new found "velocity".


> I was trying to go against the tide for the longest time by providing detailed reviews, understanding every line of code, leave meaningful comments, improve architecture, etc..

I tried that too, until I realized the people I was supposed to mentor take my comment, feed it to the LLM, and let it make the fix.

And in the meantime they learned nothing.


There is a 100% chance that people are using LLMs to find vulnerabilities and build exploits. If it was possible for something to be a 101% chance, that's what it would be.

Apologies to all - I am British. The phrase "non-zero" does cover every case other than zero, but the intent is that it covers some cases more than others. What I'm trying to say is: yes. My intent was just to push back on this specific (and slightly bizarre to me) instance of kind-of-vagueposting, to my eyes written to imply that it might be some sort of unnoticed conspiracy, detectable only by the most enlightened of observers, attuned to the subtle signals that most people miss: that people are using LLMs to find security exploits.

Indeed. It's similar to a different sliding scale that I've noticed is much more common amongst Brits than it is by other nationalities (in my limited experience):

    Zero number of...
    Insignificant numbers of...
    Not-significant numbers of...
    Not-insignificant numbers of...
    Significant numbers of...
    Very significant numbers of...
Along with the other similar scales (roughly in order):

    None of
    One or two of
    A couple of
    A few of
    Some of
    Many of
    Lots of
    Most of
    Almost all of
    All of

Right, no, what I'm snarkily saying is that basically everybody who has ever looked for a vulnerability before is now using LLMs to do it. It's a huge thing in exploit development right now.

Whatever age range you have to be in to remember the most viral videos from 2012, some measurable percentage of HN's readership probably aren't in it.

Things take time to play out!

Perhaps actual thinking is not automatically necessary for that either! - and the LLM is proof.

Then what is thinking necessary for? Not for proving novel results; not for coding; not for writing prose; not for arguing a point; not for interpreting artworks; etc.

> not for writing prose; not for arguing a point; not for interpreting artworks

To be fair, LLMs are pretty bad at all of these. They struggle to avoid cliches and to produce prose with actual substance (below a stylistic facade that is undeniably convincing).


They struggle to avoid cliches and to produce prose with actual substance

I have bad news for you about the writings of most Ph.D.s and University professors...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: