security
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!
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?
The protocol and format explained! (Updated June 5th 2021) In my last post, I showed how cosign can be used to sign and verify container images today. In this post, I’ll explain how it works at each step of the way. Life of a Cosign Signature We’ll start with cosign generate-key-pair . This command creates an ECDSA-P256 key pair (a private and a public key). The public key bytes are encoded in a PKIX formatted file.
I’ve seen a lot of questions about signing container images in the last few months, and unfortunately there aren’t many great options or answers today. So I decided to write a simple tool called cosign. It can sign container images! Here’s what it looks like to use: You can get it installed and start signing containers in minutes. There are almost no configuration options, by design. There is only one supported signature algorithm (ECDSA-P256) and one payload format (Red Hat Simple Signing).
Not really. But Kind of? Did you know that you probably already have a working PKI system for signing artifacts on your laptop today, with no keyservers, web-of-trust, or configuration? You can use it to sign files, and to find the public keys for other people and use them to verify files they signed. So why aren’t more people using this? I think it’s just gone overlooked because it’s a relatively new feature in apretty old piece of software.
