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

Linux security mailing list 'almost unmanageable'

theregister.com

Post reply on HN
Print view View original

61–70 of 116 posts

Re: Linux security mailing list 'almost unmanageable'

#61

Post by kraftman »

sillysaurusx wrote: post #48
probably_wrong wrote: post #14

Earlier quoted context omitted.

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.

I was curious how much of an impact HN could have. Napkin math: HN gets 24M views a day. Assume those views are evenly distributed across the front page (they aren’t), and that’s about 1M views for each front page post, assuming each user clicks on one post. By the rule of 10s (also not exact), there are 10x less views on comment threads. So assume around 100k views on a comment thread as a theoretical average. If ev…

Plenty of people deliberately posting to HN have their servers overwhelmed.

Re: Linux security mailing list 'almost unmanageable'

#62

Post by dathinab »

sockaddr wrote: post #55
kirtivr wrote: post #53

I'd really like maintainers to get their hands dirty with AI agents as well to help speed up the reviews. Over the last year there have been way too many stories and Twitter posts like these. Yes, maintainers are overloaded, but that's only because we haven't yet built the tools to support them. Other than such statements, I would, as a builder like to hear the sorts of tools and requirements maintainers are looking…

I'm a huge AI advocate but even I can't get on board with this. Feel free to fork the kernel and maintain your own vibe-coded disaster.

I'm confused by your answer, the previous post doesn't seem to be about vibe-coding at all.

It seems to be more about:

1. auto grouping duplicate security reports

2. auto validating if they are likely viable or likely nonsense

3. auto checking if they have recently been patched

4. auto assessing if they likely "invalide" for other reasons (e.g. they are for a very old long time no longer maintained Linux version, out of tree drivers, etc.)

I mean practically all of that isn't trivial to get working in a way appropriate for the Linux security mailing list and comes with many not so obvious complications. But also non of that is vibe coding and in most cases this is is more about AI doing a per-assemsment of send security issues to speed up the review of them, then it is about the AI doing the final decision.

Re: Linux security mailing list 'almost unmanageable'

#63

Post by Phelinofist »

l1k wrote: 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...

> perhaps with the intention to poison LLMs

How does that work?

Re: Linux security mailing list 'almost unmanageable'

#64

Post by VLM »

Make it anonymous and the problem will go away.

The problem is people trying to get individual credit for merely running a script that spams a mailing list. Many of those people are likely not even C programmers or programmers at all.

Without the immense personal reward and recognition and job offers as a motivation, the problem will disappear.

The problem will also disappear with time as the people lauding and celebrating and hiring security researchers of the past will quickly abandon LLM generated spam as a positive signal; running a prompt that sends spam is, if anything, a strong negative indicator of infosec ability and skill.

LLMs are a tool. Like all tools, most people can't or won't use them responsibly or profitably although they are useful in the correct hands.

Re: Linux security mailing list 'almost unmanageable'

#65

Post by bhaak »

trelbutate wrote: post #34

Will never understand why some people prefer mailing lists to do development, it always feels like the most convoluted way to hold a discussion, especially if there are multiple topics at the same time. It probably doesn't really change that much in this scenario but with a forum or any other topics-based platform you can at least just close and ignore these things without it affecting everyone else.

Show me a forum or topics based platform that handle threads as good as proper mail clients? Don’t mistake the poor HTML view for how managing threads with thousands of replies look like.

Local filtering is the key to ignoring threads you are not interested in. Depending on the client with 2 or 3 keystrokes you are ignoring the whole thread or this particular sub branch of it and automatically jumping to the next interesting, unread message.

Re: Linux security mailing list 'almost unmanageable'

#66

Post by kirtivr »

dathinab wrote: post #62
sockaddr wrote: post #55

Earlier quoted context omitted.

I'm a huge AI advocate but even I can't get on board with this. Feel free to fork the kernel and maintain your own vibe-coded disaster.

I'm confused by your answer, the previous post doesn't seem to be about vibe-coding at all. It seems to be more about: 1. auto grouping duplicate security reports 2. auto validating if they are likely viable or likely nonsense 3. auto checking if they have recently been patched 4. auto assessing if they likely "invalide" for other reasons (e.g. they are for a very old long time no longer maintained Linux version, out…

Exactly.

At the end of the day, we would rather have a more stable and bug-free kernel than not.

It's not that much work for me anymore to report and even fix that obscure monitor driver bug that sometimes causes my machine to bootloop, unless I boot without graphics and start the XOrg server manually.

I often find myself surprised at how easily frontier models are able to find bugs across abstraction layers, that only original authors can comprehend. We need more positivity around these contributions as well.

Re: Linux security mailing list 'almost unmanageable'

#67

Post by vitally3643 »

fhn wrote: post #52
trelbutate wrote: post #34

Will never understand why some people prefer mailing lists to do development, it always feels like the most convoluted way to hold a discussion, especially if there are multiple topics at the same time. It probably doesn't really change that much in this scenario but with a forum or any other topics-based platform you can at least just close and ignore these things without it affecting everyone else.

old people like the old tools that they grew up using

This is the reason behind essentially every reply I've ever seen to this question.

"I like it this way because it's always been this way and once you change your entire email workflow and customize your email client, it's almost as good as PHPbb"

Forums are built for threads and are immediately visible and accessible for everyone, not just people who want to spend their limited time dicking with email clients.

Mailing lists are the proto-discord: knowledge locked away from the public behind a special frontend and elitist attitudes. It's only better because the list is technically visible, but only in the worst, most low-effort way possible. You dump a raw txt copy of the entire thread unstructured onto the user and make it their problem to figure out. After all, your email client makes it easy to read, so why should you care about what anyone else needs?

Re: Linux security mailing list 'almost unmanageable'

#68

Post by kobalsky »

fhn wrote: post #52
trelbutate wrote: post #34

Will never understand why some people prefer mailing lists to do development, it always feels like the most convoluted way to hold a discussion, especially if there are multiple topics at the same time. It probably doesn't really change that much in this scenario but with a forum or any other topics-based platform you can at least just close and ignore these things without it affecting everyone else.

old people like the old tools that they grew up using

maybe the old tools are prevailing for a good reason.

I prefer people to email me because half of the time they figure out their problems while writing them.

it's not an absolute rule but people who don't do their homework gravitate towards calls and messaging because they just don't prepare their questions.

asynchronous communication puts the burden on the sender, where it belongs.

Re: Linux security mailing list 'almost unmanageable'

#69

Post by stefan_ »

Phelinofist wrote: post #63
l1k wrote: 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...

> perhaps with the intention to poison LLMs How does that work?

This is just nonsensical changes and slurs, but particularly degenerate input data can cause big issues in training:

https://x.com/gabriberton/status/2051873677998956851

Re: Linux security mailing list 'almost unmanageable'

#70

Post by perching_aix »

sillysaurusx wrote: post #48
probably_wrong wrote: post #14

Earlier quoted context omitted.

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.

I was curious how much of an impact HN could have. Napkin math: HN gets 24M views a day. Assume those views are evenly distributed across the front page (they aren’t), and that’s about 1M views for each front page post, assuming each user clicks on one post. By the rule of 10s (also not exact), there are 10x less views on comment threads. So assume around 100k views on a comment thread as a theoretical average. If ev…

> HN gets 24M views a day

This is available info?

Post reply on HN