Nope. That's why I changed all my players to BlueOS.

I replaced all my SONOS connects with BlueSound node Nano devices. A pricey replacement, but worth it.

As a bonus I was now able to turn off SMB1 on my home Samba server !

Known VPN services have identifiable server addresses that can be blocked. Instead, you can set up a cheap raspberry pi (or other) at your home and use an encrypted SSH connection to that [raspberry pi] from far away. Then turn on your SOCKS proxy (part of WiFi Details on Macintosh) and check to see that your IP address shows to the world you access as that of your raspberry pi. I do this all the time, including right now. It also helps to watch sports events.

It seems right that since I announced the BBS Documentary production on Slashdot, I should also take the time to give testimony to one of its primary interviewees that took it from side fun project to meaningful historical work.

My goal had been to do a documentary on the BBS Experience, working from interviews with flexible friends and nearby folks, and then work up to the "Big Ones", the names who had been in my teenage mind when I ran a BBS, like Ward Christensen, Chuck Forsberg, Randy Suess, and others. But then I had someone from Chicago checking in to make sure I wasn't going to skip over the important parts the midwest had told in the story. So it was that a month into production, barely nailing down how I would fly post 9/11 with a studio worth of equipment, that I found myself at CACHE (Chicago Area Computer Hobbyist Exchange) and meeting Ward himself.

They say "Never meet your heroes." I think it's more accurate to say "Have the best heroes" or "Be the kind of person a hero would want to meet." Ward was warm, friendly, humble, and very, VERY accomodating to a first-time filmmaker. I appreciated, fundamentally, the boost that he gave me and my work, knowing I was sitting on hours of footage from The Guy.

There were many other The Guy and The Lady and The Groups for BBS: The Documentary, but Ward's humble-ness about his creation and what it did to the world was what made sure I never overhyped or added layers of drama on the work. Ward was amazing and I'll miss him.

> Every large NAS vendor (Synology, QNAP, etc) has their own SMB server they wrote themserlves

That's untrue. Both Synology and QNAP use Samba. QNAP contributes code and bugfixes back to samba.org (Hi Jones !).

Thanks.

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.