Hacker News new | past | comments | ask | show | jobs | submit login
Maintaining the Kernel's Web of Trust (lwn.net)
58 points by chmaynard 10 months ago | hide | past | favorite | 13 comments



From the comment thread in that article:

"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.


Here's discussion from the time it was mentioned previously: https://news.ycombinator.com/item?id=20312826


> But, to avoid signature attacks, only signatures made with other keys stored in the repository are retained; that is sufficient to build the web of trust while eliminating the results of any signature spamming that might have taken place.

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.)


It sounds like the web of trust is an incredibly difficult problem to solve, and also not a problem that the kernel needs to solve. Why do the kernel developers need a decentralized way to verify signing keys?


They don't, that's why they're just putting the keys in a git repo.



This is not relevant to this discussion: it's like someone announced that they were buying better locks for their house and you're going “this is all moot because someone could just pull the roof off”.


More like the discussion isn't relevant to reality.

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.


The integrity of the Linux source code still matters whether or not you trust your hardware vendor. Linux runs on more platforms than those two as well.


Okay, relatively moot.

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.


> 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.

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).


I'm pointing out that ensuring software integrity is a kind of toy or game in a world where the hardware is already "powned" by someone else. People aren't computing cryptographic checksums over the linux kernel by hand.

The phrase "security theatre" is probably overused, but from my POV it would seem to apply here.


Point it out all you want -- it is irrelevant to the discussion at hand.

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: