infosec
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!
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?
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.
This post is about using container registries (Docker registries, OCI registries, whatever you want to call them) for the storage and distribution of generic, non-container-related binary artifacts. I explain the reasoning below, but first: code and demos Demos! Here’s a quick walkthrough of a draft tool (still WIP!) to securely fetch published contents from an OCI registry, called sget. sgetis part of the sigstore project, and is a standalone client that allows you to retrieve scripts or binaries from any OCI registry.
