Sigstore - A new standard for signing, verifying and protecting software
1–10 of 28 posts
Re: Sigstore - A new standard for signing, verifying and protecting software
#2This 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.
Re: Sigstore - A new standard for signing, verifying and protecting software
#3The RFC trying to introduce sigstore for RubyGems is an interesting look at this in practice: https://github.com/rubygems/rfcs/pull/37
Re: Sigstore - A new standard for signing, verifying and protecting software
#4This 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 so…
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.
Re: Sigstore - A new standard for signing, verifying and protecting software
#5I just recently investigated cosign for signing and verifying local container images. It seems very useful.
Re: Sigstore - A new standard for signing, verifying and protecting software
#6This 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..
Re: Sigstore - A new standard for signing, verifying and protecting software
#7Sigstore maintainer here. I'll try to answer questions!
Re: Sigstore - A new standard for signing, verifying and protecting software
#8Sigstore maintainer here. I'll try to answer questions!
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/...?
Re: Sigstore - A new standard for signing, verifying and protecting software
#9Does 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
Re: Sigstore - A new standard for signing, verifying and protecting software
#10Google [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...