Well another month has passed and as per usual in the sigstore world, a lot has happened! Since our last update in August we have over double the amount of contributors working on sigstore! There has been a leap from 46 to 98! wow! KubeCon NA 20201 sigstore will be at KubeCon North America with it’s own booth, so if you’re in person at the event, come and say hi! We will be at booth number S86
Welcome to our project update for August. As always the community is continuing to expand. We are now close to 600 members in our slack workspace. We now have 46 contributors and are growing each day. The month of August saw 254 commits and 526k lines of code were changed! Lots of exciting things are happening, read more for our project updates and our presence at KubeCon, NA. cosign Cosign hit 1.
Short-lived certificates are great — a short lifetime removes the need for complicated revocation policies and reduces an attacker’s window of opportunity. Yet using short-lived certificates in the software supply chain brings a lifetime problem: how can users trust artifacts after the certificate’s expiration? Repeatedly signing artifacts and requesting certificates is tedious. Really, distributors only need to prove that artifacts were signed when the certificate was valid… with timestamps! Enter SigStore’s new, free, open-source RFC 3161 timestamping service on the transparency log Rekor!
The cosign project started in February 2021 with a goal of making it easy to sign and verify containers on any OCI registry today. The community support has been incredible! We’ve added 7 maintainers from 5 organizations, and have merged 394 commits from 32 contributors across 10 organizations. Cosign has been tested on 13 OCI registries and is now packaged in five different package managers. We’ve cut seven releases over six months and are now thrilled to declare our first general availability release, cosign 1.
It’s happening! Cosign’s 1.0 release is slated for July 28. If you were curious before but were hesitant about a pre-release project, now’s a good time to try it out and leave some comments. For the initial release we plan on supporting: * Signing images with KMS (GCP, AWS, Azure, Vault), YubiKeys, and locally stored keys * Verifying image signatures using the same, plus public keys specified by URL * Verifying images in Dockerfiles * Uploading & signing arbitrary blobs (and 📄✍🏻👨🏻🦳 🇺🇸SBOMs🦅) * Stable APIs in pkg/ for integrating Cosign into build systems and policy engines
Another month, another set of exciting updates! The Sigstore community has been working at a ferocious pace to harden our platforms and tools, while working on the larger picture of supply-chain security. The pieces are coming together, and the bigger vision of OSS supply chain transparency is getting a little less blurry. This means the Sigstore community is starting to engage deeper in our peer communities as we integrate and share knowledge in both directions.
I’m thrilled to announce that the Sigstore community is holding our first Root Key ceremony on June 18th at 2pm Eastern, and I’m even more thrilled to announce that it will be hosted LIVE by the always incredible DanPOP on his CloudNative.tv show, Spotlight Live. This Trust Root will eventually be used to secure the keys used by the entire Sigstore project, but more importantly we’re planning to make our trust root available for any open source project that wants to use it!
Photo by Joshua Hoehne on Unsplash If you’re new to the Sigstore project, we officially launched on March 9th 2021 with a mission of improving the open source supply chain by making it easy to sign and verify code. We’re planning to provide free tools, APIs, and services as a public-benefit/non-profit. This post is to give a quick recap of where we are today, where we’re headed and what we’re focusing on next.
Why does it need to be so TUF? If you’re anything like me and spend time reading blog posts and GitHub discussions around how to securely package and release software, you’ve probably heard of The Update Framework. Unfortunately, if you’re actually anything like me it probably seemed overwhelming and confusing at first. This blog post explains the mental model I’ve built up for TUF, and some of the concepts that finally made it understandable and digest-able for me.
I’ve heard a TON of questions about how to sign an open source software release lately. Once you get past the impossible tooling/crypto questions, you quickly realize you’ve barely scratched the surface in complexity. These problems aren’t all specific to OSS, but community-driven projects do face some unique challenges that stretch beyond technical and into the philosophical realm. What does it mean to sign a release? Who should do it? Where should the keys live?
