Google [0] and GitHub [1] both released blog posts recently describing how to use Sigstore with GitHub Actions to sign build artifacts.
[0]: https://security.googleblog.com/2022/04/improving-software-s...
[1]: https://github.blog/2022-04-07-slsa-3-compliance-with-github...
Does this standard prevent unsigned portions, a la Dropbox/Chrome telemetry with Authenticode?
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
Sigstore maintainer here. I'll try to answer questions!
The RFC trying to introduce sigstore for RubyGems is an interesting look at this in practice: https://github.com/rubygems/rfcs/pull/37
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?
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..
I found this blog article to be a good introduction to sigstore and the related projects (such as Fulcio): https://www.giantswarm.io/blog/securing-the-software-supply-...
Sigstore and cosign are so simple to use. I setup all the containers I maintain to be signed (This is done within the Github Action).
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.
In other words, kudos?
I just recently investigated cosign for signing and verifying local container images. It seems very useful.
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.