The upstream Linux kernel doesn't differentiate between security bugs and "normal" bug fixes. So the new kernel.org CNA just assigns CVE's to all fixes. They don't score them.

Look at the numbers from the whitepaper:

"In March 2024 there were 270 new CVEs created for the stable Linux kernel. So far in April 2024 there are 342 new CVEs:"

Yes ! That's exactly the point. Trying to curate and select patches for a "frozen" kernel fails due to the firehose of fixes going in upstream.

And in the kernel many of these could be security bugs. No one is doing evaluation on that, there are simply too many fixes in such a complex code base to check.

Oh that's really sad. I hope they use a more up to date version of Samba :-).

I don't see that argument in the blog or paper.

Did you read them ?

There are many more unfixed bugs in vendor kernels than in upstream. That's what the data shows.

You're missing something.

New bugs are discovered upstream, but the vendor kernel maintainers either aren't tracking, or are being discouraged from putting these back into the "frozen" kernel.

We even discovered one case where a RHEL maintainer fixed a bug upstream, but then neglected to apply it to the vulnerable vendor kernel. So it isn't like they didn't know about the bug. Maybe they just didn't check the vendor kernel was vulnerable.

I'm guessing management policy discouraged such things. It's easier to just ignore such bugs if customer haven't noticed.

Gordon, Gordon, don't you ever get tired of your obsession ?

"Towards thee I roll, thou all-destroying but unconquering whale; to the last I grapple with thee; from hellâ(TM)s heart I stab at thee; for hateâ(TM)s sake I spit my last breath at thee."

Very astute comment. The white paper shows that the frozen "vendor" kernel model really doesn't work. And if people can't / won't upgrade then maybe alternative security precautions around a known insecure kernel is the best we can do.

I'm just gonna leave this here..

https://www.youtube.com/watch?...

Once Plex started trying to charge me for casting to my SONOS devices I moved to emby.

https://emby.media/index.html

They do have some smart TV support:

https://emby.media/community/i...

(Comment I also added to the register article - but I like /. too :-).

I offered to go with Linus to Sao Paulo zoo once to help him avoid having to meet Lula, the president of Brasil which he really didn't want to do :-). I did so only on the condition he do an interview with me. I was fed up of people asking Linus about Linux, so I only asked him questions about the Sinclair QL, which both he and I enjoyed. Interview is still available on youtube here:

https://www.youtube.com/watch?...

https://twitter.com/GoogleNoDe...

There are companies who do "pay for play" Samba development. You pay 'em and tell them what you want in Samba, and they'll write it and upstream it for you.

Might be more than you want to pay though.

Samba does implement DFS, I wrote lots of the code for it and updated it recently :-).

I think you mean it doesn't implement DFS replication in the same way that Windows does.

Samba is only configured one way, via the smb.conf file.

Runtime control can be done via smbcontrol, but the base config file is always smb.conf.

When using local uses passwords *must* be separate as the SMB protocol and Linux passwords use completely different crypto.

Of course if you want synchronised passwords just add the Linux machine into the Active Directory Domain using Samba's winbind and users and passwords are identical of course.