Nice write-up. Thanks for sharing.

Some may not remember BitKeeper being used to maintain the Linux kernel source code and how a discrepancy was found (22 years ago) between that repo and the CVS repo. This kind of led to git and signed commits that we have today, etc.

Here's a short write up: https://blog.citp.princeton.edu/2013/10/09/the-linux-backdoo...

Anything but PKI I guess? I'll never understand why the FOSS ecosystem is so stubborn on this matter. PKI based systems like authenticode work fine (FYI: The Windows/NT kernel has an entire dedicated Code Integrity Subsystem just for PKI/authenticode).

The Linux foundation, Linux distribution projects and other FOSS organization can issue code signing certs. The infrastructure burden isn't more significant than key servers or git repos. You can trust specific root CA's, there is no need to trust every public/commercial CA. As a result of commercial adaption, PKI has a lot of tooling and support that PGP lacks.

PGP is just so awkward to use. Fetching keys from key servers, googling if you have the right key,etc... a couple of weeks ago one of my Linux VMs on a rolling release wouldn't update packages because of a missing key. I only solved it after finding a stack overflow post suggesting to fetch a specific key.

The PGP ecosystem feels a lot like security theatrics instead of a well designed system that considers real-world threat models. Not that PKI lacks its own problems, but it is far more sturdy, easy to use and has a consistent user experience.

PGP relies too much on its users not making a mistake. A lot of its security properties depend on users carefully fetching the right key or attending key signing parties or whatever shoddy scheme you have to come up with. Anarchy doesn't work well in real life. I implicitly trust the Linux kernel devs as well as the maintainers of my Linux distribution. There is no reason why I shouldn't trust them to issue CA certs and issue code signing certs for ELF binaries, kernel modules and even scripts (powershell does this on windows!). Especially with things like flatpak and vendoring being so popular these days, PKI makes a lot of sense.

Any time I have to install commercial software, I have to add a whole new repo and trust that vendor's PGP keys. Imagine if instead those vendors were required to obtain code signing certs from distros and sign their packages. Actually, package signing is nice and all but the lack of actual well supported executable/script signing is disappointing.

I get the whole modular Unix philosophy around this whole topic. But the FOSS ecosystem has come a long way and pretending dependencies don't exist or that projects live isolated on an island is disconnected from reality.

There are lots of trust issues with open source software due to how hard it is to mange supply chain security. Practical approaches like PKI in my opinion can contribute a lot to the improvement of trust for such projects.

I don't see what the system here mentioned here (a list of centrally tracked keys in git) doesn't do that a PKI system does.

I'm also not sure why a distro would be interested in signing keys for third parties, why isn't said software packaged by the distro?

A distro is an OS. it is responsible for the security of the system. third party packages running on it securely is also its responsibility. Right now, that responsiblity is offloaded to users, expecting them to add the right keys and repos.

If you look at Windows, MacOS, Android, iOS, virtually any other mass-adapted OS, the OS provides authentication and integrity services for all packages, including third-party packages and programs.

Providing a framework where developers can attest their software and ensure it is trusted is a bare-minimum expectation for a modern OS.

The Git tracking part isn't an issue, what they should instead do is Git track CA root and intermediate certs and setup a website or workflow where details like the developer, the security checks done, the permissions and privacy implications of the software are attested by the distro and a certificate is issued.

The ideal state is such that all software not developed on that system should not be allowed to run unless its authenticity and integrity are validated and the admin/user signs off on the authenticated properties of the software.

The article was talking about the Linux kernel. The kernel doesn't care about the software is runs with, so why should they run a CA (and if the Linux Foundation did run a CA, no one would care, see what happened to LSB)?

The distro is a compete system, and doesn't care about your third party software (again, why should they), as they already have a system to manage software, if the developer wants to do their own thing, that's a them problem. If you want to install random unpackaged stuff, go ahead, it's your machine (as nearly every OS allows), and if you don't want to run random stuff, don't install it.

Seems this is related to SHA1 being used on gnupg. Will be interesting on how this plays out when SHA1 in gpg is obsoleted. I am not looking forward to that.

Then there is the added complexity of git using SHA1, I do not know if that has been changed yet.

Fun times ahead.

FWIW, I changed my git commit signing to ssh-ed25519 from gnupg about a month ago.

Didn't GPG change its default to ed25519 four years ago?

https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/0004...

ssh-ed25519 is different from a gnupg ed25519 key, since it doesn't have any of the technical baggage that gnupg has. Even with ed25519, sha1 is still hardcoded into RFC4880, the standard that gnupg implements. Fingerprints are typically 40 characters long since they are hex sha1 hashes. There's RFC9580 that changes this to sha256, but it's still very new and currently being finalized.

But even then, when using ed25519+sha256 to generate a signature, you're still going to do this over a sha1 hash because of the way git works.

or... gpg gets obsoleted along with sha1

It's his second language. I think we can cut him some slack.

It's not like that's even a common mistake, in my experience

"since " is the normal grammar in German and has the semantics of "since subtract(now, )" as you would expect

German. "seit" for both.

since we are at time constructs, german also uses "wenn" when english uses "if" or "when".

from constructive corrections, we learn our grammatical, semantical mistakes, hence we move forward to better understand each other.