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.
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.
aragilar · 5h ago
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?
jmclnx · 1d ago
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.
freeopinion · 1d ago
Didn't GPG change its default to ed25519 four years ago?
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.
arccy · 23h ago
or... gpg gets obsoleted along with sha1
NooneAtAll3 · 1d ago
> since more than 20 years.
a bit sad that "since for time_points, for for time_duration" grammar rule isn't as well known as it should
crote · 1d ago
It's his second language. I think we can cut him some slack.
NoahKAndrews · 23h ago
It's not like that's even a common mistake, in my experience
immibis · 19h ago
"since <duration>" is the normal grammar in German and has the semantics of "since subtract(now, <duration>)" as you would expect
Tomte · 1d ago
German. "seit" for both.
owl_vision · 21h ago
since we are at time constructs, german also uses "wenn" when english uses "if" or "when".
owl_vision · 21h ago
from constructive corrections, we learn our grammatical, semantical mistakes, hence we move forward to better understand each other.
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...
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'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?
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.
https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/0004...
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.
a bit sad that "since for time_points, for for time_duration" grammar rule isn't as well known as it should