from Hacker News

Sigstore - A new standard for signing, verifying and protecting software

by kuahyeow on 5/3/22, 9:45 PM with 27 comments

• by RandomBK on 5/4/22, 1:15 AM

  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.

• by nooney on 5/4/22, 3:56 AM

  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...

• by password4321 on 5/4/22, 3:51 AM

  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

  https://news.ycombinator.com/item?id=8203164 (2014)

• by dlor on 5/4/22, 3:05 AM

  Sigstore maintainer here. I'll try to answer questions!

• by alilleybrinker on 5/4/22, 1:59 AM

  The RFC trying to introduce sigstore for RubyGems is an interesting look at this in practice: https://github.com/rubygems/rfcs/pull/37

• by badrabbit on 5/4/22, 11:30 AM

  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?

• by netman21 on 5/4/22, 2:49 AM

  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..

• by mshekow on 5/4/22, 4:56 AM

  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-...

• by chimbosonic on 5/4/22, 10:23 AM

  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).

  https://github.com/chimbosonic/hagrid-container

• by pineconewarrior on 5/4/22, 5:42 AM

  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?

• by adammfrank on 5/4/22, 2:23 AM

  I just recently investigated cosign for signing and verifying local container images. It seems very useful.