Live data from Hacker News

Linux security mailing list 'almost unmanageable'

theregister.com

11–20 of 116 posts

Re: Linux security mailing list 'almost unmanageable'

#11
post #5

Isn't it mostly the medium that's problematic? With an issue tracker it's easier to close as duplicate

An open visibility tracker would be a goldmine for finding new exploits before a fix is even available. From what I’ve seen many of the AI bug search operators are newer to security research. They’re burning their tokens trying to find kernel bugs as their claim to fame before other people with AI tools find them first. They don’t spend time de-duplicating their own bugs. Some of them may not be coming from real peop…

So make it a closed issue tracker with a public email gateway. Get Anthropic to donate LLM time to classify and combine incoming reports.

Re: Linux security mailing list 'almost unmanageable'

#12

Earlier quoted context omitted.

An open visibility tracker would be a goldmine for finding new exploits before a fix is even available. From what I’ve seen many of the AI bug search operators are newer to security research. They’re burning their tokens trying to find kernel bugs as their claim to fame before other people with AI tools find them first. They don’t spend time de-duplicating their own bugs. Some of them may not be coming from real peop…

So make it a closed issue tracker with a public email gateway. Get Anthropic to donate LLM time to classify and combine incoming reports.

If the LLM hallucinates bugs what makes you think any classification won't be hallucinated?

Re: Linux security mailing list 'almost unmanageable'

#13
post #6
post #5

Isn't it mostly the medium that's problematic? With an issue tracker it's easier to close as duplicate

If the AI is awesome at identifying security bugs in the linux kernel, it likely can also identify if the thing it's found is similar to something that is already found in the security mailing list? Or, put another way -- what flags the duplicate? The filer or the system? If my cheese factory is measured by the volume of cheese instead of the quality, I'll churn out the cheese even if it's sloppy duplicated cheese. A…

The problem is that the tech companies are paying their research/marketing departments for headlines that go "Researcher uses powerful new Saga 6.2 release to find 597 kernel vulnerabilities! (Can your company afford NOT getting their $1000/month subscription?)", not for headlines that go "Researcher spends $50.000 to find 597 bugs, then spends $25.000 figuring out 540 of them are duplicates".

Unless the kernel community starts banning & publicly shaming repeat offenders, there's zero incentive for them to put any effort in filtering out duplicates. They are mostly doing it for marketing after all, not out of a genuine interest in making the kernel better.

Re: Linux security mailing list 'almost unmanageable'

#14
post #9

Fun fact (or not so fun if you're a subscriber): Somebody is spamming kernel mailing lists under the name Marian Corcodel with a 26 MByte message multiple times per day containing a collection of nonsensical patches. Looks AI-generated, perhaps with the intention to poison LLMs. This has been going on for a few days now. https://lore.kernel.org/all/CAGg4U=GNtCObd_Nbm_1Rr5FEvPb69Yz...

I'd warn HN users not to click on that link simply because it will load a 26Mb message that will likely cause quite a strain on kernel.org's servers if everyone here does it.

Re: Linux security mailing list 'almost unmanageable'

#16
post #6
post #5

Isn't it mostly the medium that's problematic? With an issue tracker it's easier to close as duplicate

If the AI is awesome at identifying security bugs in the linux kernel, it likely can also identify if the thing it's found is similar to something that is already found in the security mailing list? Or, put another way -- what flags the duplicate? The filer or the system? If my cheese factory is measured by the volume of cheese instead of the quality, I'll churn out the cheese even if it's sloppy duplicated cheese. A…

> “AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved – and only makes that duplication worse because the reporters can't even see each other's reports.”

Re: Linux security mailing list 'almost unmanageable'

#17
post #5

Isn't it mostly the medium that's problematic? With an issue tracker it's easier to close as duplicate

And with a mailing list you don't even have to do that! The problem doesn't really change, because you have to figure out whether it is a duplicate before you can mark it as duplicate, and that's the 'managing' part of 'unmanageable'.

Re: Linux security mailing list 'almost unmanageable'

#18
post #9

Fun fact (or not so fun if you're a subscriber): Somebody is spamming kernel mailing lists under the name Marian Corcodel with a 26 MByte message multiple times per day containing a collection of nonsensical patches. Looks AI-generated, perhaps with the intention to poison LLMs. This has been going on for a few days now. https://lore.kernel.org/all/CAGg4U=GNtCObd_Nbm_1Rr5FEvPb69Yz...

I'd warn HN users not to click on that link simply because it will load a 26Mb message that will likely cause quite a strain on kernel.org's servers if everyone here does it.

https://web.archive.org/web/20260518134447/https://lore.kern...

Re: Linux security mailing list 'almost unmanageable'

#19
I like to imagine that LLM's ability to optimize code is like an extension of the training-loop in deep learning. The loss function is some kind of metric representing security and/or performance (or the lack of it) of the code and we use the LLM as the gradient/diff generator to iterate in batches over the code and fine tune it.

Imagine the current state being for the most part a collection of local maxima in security. To push the system in a more optimal state, you either need skilled people and time to overcome the barrier to a new local maximum or you throw AI at it and evaluate whether you land in a more optimal state.

I think after some time of turbulent exploit/patch cycles we will reach a stable state again, where the code converges against a new local minimum that even with AI requires significant effort (time and tokens) to overcome. Or ideally a global maximum.

With time, the LLMs improve, so the diffs/gradients get better and we will be able to reach optimal points for any software faster.

My problem with the idea is that apparently it is assumed that OSS contributors and especially maintainers will generously donate their time to get this machinery into a state that makes the optimization loop work well - just for the AI labs to turn around and sell access to the optimized models for increasingly larger amounts of money.

AI generated code can be great. Hand rolled code can be bad. The rules are the same in both cases. Make sure your code changes are focused (no random changes just because you happen to be in the file/dir or notice something) and make sure you don't break anything else along the way.

Re: Linux security mailing list 'almost unmanageable'

#20
post #2

"Torvalds' remarks contrast with recent comments from fellow kernel maintainer Greg Kroah-Hartman, who recently told The Register that AI has become an increasingly useful tool for the FOSS community." Does it? Both points can be true at the same time.

I will argue that ON AVERAGE, humans are lazy, and will use LLMs to generate walls of text and code. We like the easy way out - just pop a pill. Here we have a technology that can finally help us manage the crippling firehose of data, and instead, we are going to make it much worse. As expected.

A few of us will actually use these tools to reduce toil and achieve something useful.

Post reply on HN