Sigstore Blog

First, yes: there absolutely should be better tools for authors to sign & authenticate their own tools, with heightened cryptographic authentication means. Projects like sigstore get this (and wish to respect privacy![1]). But what's spoken of here is a deep imposition, and doesn't empower authors, but demands of them. > I fail to see how MFA resolves the fundamental trust equation Nothing ever will. Your desire for a cathedral is incompatible fundamentally & at every level with the bazaar. Trying to drive open-source society towards an industrialized security state for the convenience of your probably non-contributing, not-paying industrialized software production needs is vastly unfair. If you have needs, you need to take your own responsibility. If you have risks, you need to pay to hedge them. Go hire NodeSource to help you get the Certified Modules you can trust. Go sign contracts with authors to get the support you need. Heck, just checkin your package-lock.json and go see what you are downloading: npm is immutable! You could literally do anything to help safeguard yourself, but you ask for absolute protection, something that even the biggest best corporations can never truly promise. Trying to prevent even one reasonably placed malicious employee from causing disruption is a near impossible task. But you ask for a fundamental safety. This is laughable. None of us can expect nor deserve that. > Until GitHub requires government-issued photo ID in addition to…

https://www.sigstore.dev/ The emerging standard for verifying artifacts, e.g. in container image signing, npm, maven, etc https://blog.sigstore.dev/npm-public-beta/ https://www.sonatype.com/blog/maven-central-and-sigstore

Interesting! Looks like it's being used by some npm packages [1] and soon homebrew will be using it [2]. Any other interesting usage? As a user, the npm usage doesn't seem very prominent. On an npm's web page, there's a checkmark next to the version number on the right side that I hadn't paid any attention to before, with more information at the very bottom of the page. Here's an example. [3] [1] https://blog.sigstore.dev/npm-provenance-ga/ [2] https://blog.sigstore.dev/homebrew-build-provenance/ [3] https://www.npmjs.com/package/fast-check

Not only would it work for NPM, but it already does[1] :-) [1]: https://blog.sigstore.dev/npm-public-beta/

A public good project I work on (sigstore) penned an article on why a suitable application found it a challenge to leverage Blockchain https://blog.sigstore.dev/sigstore-blockchain-vs-transparency-logs-d67…

Balancing privacy vs transparency is definitely something that's tricky! You may be interested in https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 which goes into some of the background of why email addresses are used and some of the things we're thinking about in this area for Sigstore. Disclosure: I'm the creator of gitsign and wrote this blog post.

I'm a maintainer on Sigstore, and we published this blog post in support of this effort too! https://blog.sigstore.dev/sigstore-ruby-ce3591838fe8

Sigstore.dev supports revocation: "Don’t Panic: A Playbook for Handling Account Compromise with Sigstore" (2022) https://blog.sigstore.dev/dont-panic-a-playbook-for-handling-account-c… "Why you can’t use Sigstore without Sigstore" (2023) https://blog.sigstore.dev/why-you-cant-use-sigstore-without-sigstore-d… : > Revocation in Sigstore. A recent post on this blog notes that signatures alone don’t tell you whether to trust an artifact; for that, you need a verification policy. This verification policy is a much more natural place to handle revocation than the identity layer; see Don’t Panic for an example. This allows us to avoid the scalability problems of global revocation lists (see CRLite for a discussion of these issues). The mantra here is revoke artifacts, not keys. Artifact Attestation > Verifying an artifact attestation for binaries: https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifa… : gh attestation verify PATH/TO/YOUR/BUILD/ARTIFACT-BINARY -R orgname/reponame If it is not possible to retract/revoke releases then, there again, the installer MUST verify against a signed list of revoked releases