"I have considered running a non-connected SKS instance, but at this point in time everyone seems to consider SKS as pretty much dead -- it's not maintained and nobody is willing to step up or so much as touch it due to any number of reasons (largely, because OCaml is just too esoteric)."
I wonder if they've tried reaching out to the OCaml community. I'd be surprised if there weren't people in it that would be happy to step up to help, were they aware of the need and its importance to Linux kernel development.
They could also try actually paying someone to maintain it. As the article notes, the Linux kernel development ecosystem is no longer staffed fully by volunteers. There's a lot of corporate money in it now, including big contributions from the likes of IBM and Redhat. They could certainly afford to hire someone to take on this responsibility, if it was deemed necessary.
I didn't understand how this alone is sufficient to prevent signature spamming, once a single compromised or bad-actor signature is in the repo.
"https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/... suggests a bit different process, which currently seems to require manual importing of individual signatures into one's keyring.
And the automated updating of user's keyring is only of such manually-imported signatures. (And the commit from which the updates are taken must be signed by a key that was signed directly by the key of Torvalds or the user.)
The house is constantly being renovated and repaired, including the locks, doors, hinges, and every knob and button, by a lot of people, some of whom are even actual contractors, and now a few of those have ID badges.
Meanwhile, in Ecuador... (massive database leak ~20M people's data). That's just this morning.
Apologies for the snark, but I feel it's important to keep in mind in discussions of trust and security the enclosing scope or context. You can't trust the "integrity of the Linux source code" if you are checking it with compromised hardware, or running it on compromised hardware.
> Linux runs on more platforms than those two as well.
I am not a security specialist, just a plain ol' paranoiac, but at this point in history, given what we've seen and heard so far, I would bet most platforms are compromised hardware. I don't really have anything more constructive to add so I'll shut up now.
You are incorrect in this instance. The topic at hand is ensuring software integrity. Your scope of analysis is what I'll call "full-stack integrity" (hardware, firmware, software, etc).
The phrase "security theatre" is probably overused, but from my POV it would seem to apply here.
If said discussion was asserting integrity at a hardware level, you would have a point. But it doesn't do that. There is a reason it is narrowly prescriptive.