Adopting Sigstore Incrementally

Developers, package maintainers, and enterprises that would like to adopt Sigstore may already sign published artifacts. Signers may have existing procedures to securely store and use signing keys. Sigstore can be used to sign artifacts with existing self-managed, long-lived signing keys. Sigstore provides a simple user experience for signing, verification, and generating structured signature metadata for artifacts and container signatures. Sigstore also offers a community-operated, free-to-use transparency log for auditing signature generation.

Is Sigstore Ready for a Post-Quantum World?

Photo by Anton Maksimov 5642.su on Unsplash A couple of weeks back, NIST made big news in the cryptographic community by announcing that they have selected four quantum-resistant encryption and digital signature algorithms for standardization. In recent years, worries about the threats that quantum computers pose to current encryption algorithms have precipitated a major effort to establish a “post-quantum” (PQ) cryptographic toolkit. NIST’s 99-page full report, which reflects six years of work by a group of expert cryptographers details the algorithms and their performance and security characteristics However, the report omits the answer to the question on every Sigstore user’s mind: is Sigstore ready for a post-quantum world?

sigstore, blockchain vs transparency logs

Co-authored by Luke Hinds (Red Hat) and Prof Santiago Torres-Arias (Purdue University). Disclaimer: The following is representative of the authors views, and not necessarily that of the sigstore community. *“Why did you chose to use a transparency log and not a blockchain?”* We get this question often, so we figured it’s best to address this head on. It could be best summarised as *‘why would we use blockchain?*’ as opposed to ‘*why did we not use blockchain?

Privacy in Sigstore

Photo by Tim Mossholder on Unsplash By default, the keyless signing flow for Sigstore exposes a user’s email: $ rekor-cli search --email zack@example.com \ # not my real email! | wc -l Found matching entries (listed by UUID): 112 Specifically, a user logs in to Fulcio with OIDC. Fulcio issues a short-lived certificate with the SAN set to your email address as reported by the OIDC identity provider, even if your email is not typically exposed on that service itself (for instance, your GitHub email will be exposed, even though it’s not generally public).

Don’t Panic: A Playbook for Handling Account Compromise with Sigstore

Photo by Tonik on Unsplash Despite your best efforts, you may no longer trust artifacts, keys, or identities when signing software. A container might turn out to have vulnerabilities, a key might be lost, or worse: a trusted account could be compromised. There’s a myth that Sigstore makes revocation harder; in fact, the opposite is true! While it is true that the signatures on software are stored forever, software verification using Sigstore does support artifact revocation.

How to verify container images with Kyverno using KMS, Cosign, and Workload Identity

Securing our software supply chains has become more critical with the rise of software supply chain attacks. Also, over the past few years, container adoption has increased too. In the light of these pieces of information, it has grown the need to sign container images to help prevent supply chain attacks. In addition, most of the containers we are using today, even if we use them in production environments, are vulnerable to supply chain attacks.

Sigstore ❤ Ruby!

We started the Sigstore project with a goal of making key management, certificates, and digital signatures accessible and easy to use for every developer and language community. It’s incredibly exciting to see our tooling and services used by new ecosystems, so we were thrilled to see the recent RFC from Shopify around improving the signing mechanisms on RubyGems using Sigstore. On behalf of the Sigstore community, we’d like to affirm that we’re here to help with this RFC in any way we can!

Sigstore: Bring-your-own sTUF with TUF

Users of Sigstore may want to leverage Sigstore tools and infrastructure, but may not want want to rely on Sigstore’s root of trust or all of the components of the public infrastructure. For example, a company may want to maintain a private transparency log for all internal build information but only make entries to a public log for published releases. Or, a user may not want to include their email addresses in a public certificate transparency log.

Celebrating 1,000,000 entries in Rekor

We’ve finally reached a million entries! We hit a million entries by the end of 2021: rekor-cli get — log-index 1000000 LogID: c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d Index: 1000000 IntegratedTime: 2021–12–27T21:34:27Z UUID: abb93264122dc2eb6da3ac77957978dda3ceb3521ab52cdff8490b23eaf791c1 As a double milestone — the turn of the year and the next order of magnitude — this is a good opportunity to look into what’s become of the Sigstore ecosystem since its inception. Throughout the last year, we’ve seen a lot of different initiatives, new types of signatures added, tools, major features, and more from the whole community.

Spooky Updates for Sigstore!

October is almost done, so it’s time for another update! The supply chains are clearly haunted, so this one has a spooky theme. The community is still growing quickly, and the fancy new “Contributor Strength” dashboard reflects it! In other numbers, we’re at 820 commits from 85 committers, and our slack channel has reached 710 members! Keep the PRs coming everyone! The Sigstore talk at Kubecon went very well, and the Sigstore booth was a huge success!