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…
Linux security mailing list 'almost unmanageable'
11–20 of 116 posts
Re: Linux security mailing list 'almost unmanageable'
#12Earlier 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.
Re: Linux security mailing list 'almost unmanageable'
#13Isn'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…
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'
#14Fun 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...
Re: Linux security mailing list 'almost unmanageable'
#15Re: Linux security mailing list 'almost unmanageable'
#16Isn'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…
Re: Linux security mailing list 'almost unmanageable'
#17Isn't it mostly the medium that's problematic? With an issue tracker it's easier to close as duplicate
Re: Linux security mailing list 'almost unmanageable'
#18Fun 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'
#19Imagine 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"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.
A few of us will actually use these tools to reduce toil and achieve something useful.