This looks quite interesting, and is sponsored by the Linux Foundation and several other orgs. Code signing is definitely a mess in the Linux world.
One thing I'm less happy about is how these sort of projects always tend to build up a whole parallel universe, dragging along a whole suite of dependencies and related projects (Cosign, Rekor, Fulcio, etc.)
I understand why we might want to fill gaps in existing open source tools, but it makes adopting these platforms a massive migration effort, where I need to go to several project's documentation to learn how everything works. Naming wise, I would also much prefer boring, descriptive names over the modern fancy project names.
I only started digging into this space last week, but I think cosign, rekor, and fulcio are not related projects but rather critical components of sigstore. Cosign is the cli for signing and verifying artifacts, Rekor is the transparency log, and Fulcio is the certificate authority.
> the signature blocks themselves can contain data. This data isn’t validated by the hash verification process, and while it isn’t code per-se, an executable with such data could examine itself, find the data, and make use of it
Are there plans to integrate it with something like Crev[0] for tying trusted code/security reviews to the binary artefacts?
I suppose the people you trust to audit some code will likely not be the same people you trust to do build verification for you, but it might be nice to manage those trust relationships in a single UI/config.
It'd be wonderful to have a quick what-it's-for and what's-it-not-for, eli5 style, on that home page. The current page is a bit light on details.
Is sigstore relevant only for signing Linux distributions, or do you see it being relevant for language specific package managers, like rubygems/npm/pip/...?
Two hard facts are: 1) You need to get Microsoft onboard 2) It doesn't mean much without developer ID verification and financial cost
Short of those two, it just becomes a way to maintain walled gardens by app stores or a means of replacing opensource gpg package signing with centralized web-of-trust? I guess the cosign part means some decentralization like GPG ? I am not bashing it, it can help with Supply chain attacks, but I predict adoption woes and being used by malicious actors a lot without those two items. Is Firefox signed by Mozilla legit or is Firefox signed by Mozilla Corporation legit?
Given the work they are (ironically) doing on open source supply chain security[0], it would be embarrassing if they didn't end up implementing something similar for apps in the Windows Store.
> 2) It doesn't mean much without developer ID verification and financial cost
Even without verifying an ID, tools will be able to accumulate trust in long-standing identities, and flag when you are installing a package made by an identity that no one has ever heard of (which could be a sure sign of a typosquatting attack[1], for example).
You're right, though, that in some reductionist sense, "all we're doing" is moving the trust problem from binaries to (source code to reviews/audits to) pseudonymous digital identities. Closing the gap between those identities and the legal system is a cultural/political question that needs to be thought about separately, but I do think that having a decentralised web-of-trust system would greatly increase the cost for attackers and make attacks significantly less frequent.
This is all great. Signing and verifying software is important. But it is woefully inadequate in a post Solarwinds-Notpetya-FLAME world. We need something that allows an organization to verify that code has not been maliciously tampered with. I can only think of a combination of sandboxing to detect detonation and C&C comms, and reverse engineering to compare the updates with previous versions. The last is problematic because most licensing bars reverse engineering but oh well..
NotPetya delivered itself via an official update, but then did nothing for a month. It was triggered using a response to a standard update check message. Seconds later it was compromising everything in sight.
My point being that sandboxing, etc. would not have helped you at all.
I know this might seem random and a bit of a big ask, but would you consider publishing some of your website's front-end bits on your github, too? It's a really nice job and seems highly optimized and I am curious about how it was made and delivered.
[+] [-] RandomBK|3 years ago|reply
One thing I'm less happy about is how these sort of projects always tend to build up a whole parallel universe, dragging along a whole suite of dependencies and related projects (Cosign, Rekor, Fulcio, etc.)
I understand why we might want to fill gaps in existing open source tools, but it makes adopting these platforms a massive migration effort, where I need to go to several project's documentation to learn how everything works. Naming wise, I would also much prefer boring, descriptive names over the modern fancy project names.
[+] [-] koalaman|3 years ago|reply
[+] [-] nooney|3 years ago|reply
[0]: https://security.googleblog.com/2022/04/improving-software-s...
[1]: https://github.blog/2022-04-07-slsa-3-compliance-with-github...
[+] [-] password4321|3 years ago|reply
https://docs.microsoft.com/en-us/archive/blogs/ieinternals/c...
> the signature blocks themselves can contain data. This data isn’t validated by the hash verification process, and while it isn’t code per-se, an executable with such data could examine itself, find the data, and make use of it
https://news.ycombinator.com/item?id=8203164 (2014)
[+] [-] dlor|3 years ago|reply
[+] [-] dane-pgp|3 years ago|reply
I suppose the people you trust to audit some code will likely not be the same people you trust to do build verification for you, but it might be nice to manage those trust relationships in a single UI/config.
[0] https://github.com/crev-dev/crev
[+] [-] mceachen|3 years ago|reply
Is sigstore relevant only for signing Linux distributions, or do you see it being relevant for language specific package managers, like rubygems/npm/pip/...?
[+] [-] vlovich123|3 years ago|reply
[+] [-] alilleybrinker|3 years ago|reply
[+] [-] badrabbit|3 years ago|reply
Short of those two, it just becomes a way to maintain walled gardens by app stores or a means of replacing opensource gpg package signing with centralized web-of-trust? I guess the cosign part means some decentralization like GPG ? I am not bashing it, it can help with Supply chain attacks, but I predict adoption woes and being used by malicious actors a lot without those two items. Is Firefox signed by Mozilla legit or is Firefox signed by Mozilla Corporation legit?
[+] [-] dane-pgp|3 years ago|reply
Given the work they are (ironically) doing on open source supply chain security[0], it would be embarrassing if they didn't end up implementing something similar for apps in the Windows Store.
> 2) It doesn't mean much without developer ID verification and financial cost
Even without verifying an ID, tools will be able to accumulate trust in long-standing identities, and flag when you are installing a package made by an identity that no one has ever heard of (which could be a sure sign of a typosquatting attack[1], for example).
You're right, though, that in some reductionist sense, "all we're doing" is moving the trust problem from binaries to (source code to reviews/audits to) pseudonymous digital identities. Closing the gap between those identities and the legal system is a cultural/political question that needs to be thought about separately, but I do think that having a decentralised web-of-trust system would greatly increase the cost for attackers and make attacks significantly less frequent.
[0] https://news.ycombinator.com/item?id=27930594
[1] https://www.theregister.com/2017/08/02/typosquatting_npm/
[+] [-] netman21|3 years ago|reply
[+] [-] varunsharma07|3 years ago|reply
[+] [-] MattPalmer1086|3 years ago|reply
My point being that sandboxing, etc. would not have helped you at all.
[+] [-] mshekow|3 years ago|reply
[+] [-] chimbosonic|3 years ago|reply
https://github.com/chimbosonic/hagrid-container
[+] [-] pineconewarrior|3 years ago|reply
In other words, kudos?
[+] [-] vquemener|3 years ago|reply
https://github.com/sigstore/sigstore-website
[+] [-] adammfrank|3 years ago|reply