Photo by Brett Jordan on Unsplash
Time flies in open source! This post provides a few updates on Sigstore since our last update in March. We’ve been lucky to continue welcoming new community members and contributors, with 39 contributors from over 15 companies and our Slack channel is rapidly approaching 300 members!
Let’s jump into some more project updates:
As mentioned above, the Rekor binary transparency log now natively supports signed JARs. You can give this a try today with your favorite jars! Here’s an example of the latest stable Jenkins release!
$ rekor-cli upload — artifact https://get.jenkins.io/war-stable/2.277.3/jenkins.war — type=jar — artifact-hash=3e22c7e8cd7c8ee1e92cbaa8d0d303a7b53e07bc2a152ddc66f8ce55caea91abCreated entry at index 3317, available at: https://api.rekor.dev/api/v1/log/entries/5bf721a65011f3c1273d728021cf669603e7b96b68d3e86249801a8eeb0a8c34
We’ve also made a large series of changes to Rekor’s log signing model so we can better manage the private signing keys. This change also unblocks us from improving our support for trusted timestamps, which will be a major area of focus going forward.
As we continue to improve the stability of Rekor, we also understand that many organizations do not want to rely on the availability of third-party systems. We don’t want to force you to either, so we’re working on improving support for bundled assertions which would allow most users to perform complete verifications offline, without needing to reach out to the Rekor service. An early design plan is here, we’d appreciate any feedback!
We focused on containers early on in Sigstore, but our goal has always been broader. A theme you’ll notice across all of our project updates below is that we’re laying the groundwork to make signing easier for all types of software artifacts.
We’ve started making great progress on Java JAR files with binary transparency in Rekor and a “keyless” signing plugin for Maven. We also have a native Ruby signing plugin for Gems in progress. Next up on the list are WASM modules and In-Toto attestations.
Our initial focus on OCI Images and containers was also part of a broader strategy that is starting to pay off. The OCI format and specifications were designed to be generic enough to store artifact types other than container images, and we’re seeing other communities start to take advantage of this capability with projects like HomeBrew, TektonCD, Helm, WASM and more.
The great part of this is that our tooling for signatures and transparency will carry over to these new formats automatically! This means that users can already be used to sign WASM bundles, OCI Artifacts, OPA Policy Bundles, and anything else packaged into an OCI registry with cosign, taking advantage of our CA and Binary Transparency services for free. The CNCF’s ArtifactHub project currently supports publication and discovery for all of the following artifact types, and we expect this list to continue growing!
Cosign v0.3.1! is now available, with a long list of fun and useful features like hardware-token based signatures, integrations with popular CI systems, and a lot of UX improvements to the command line surface. This release also includes a new, experimental “headless/keyless” mode for automated CI signatures that don’t require any credentials.
The new hardware-based signature support allows users to configure and start signing containers with any hardware key that supports the PIV interface, all without leaving the cosign CLI. We’re working out our strategy for using these devices to sign the binary releases of cosign itself, as well as TUF metadata for the entire sigstore project.
If you want to use cosign as part of an automated release pipeline, our GCP KMS support is now stable, and we’re actually dogfooding it ourselves to sign releases of the Distroless base container images and the popular Kaniko container build tool. These releases make use of our Google Cloud Build and Github Actions integrations, you can check out these scripts for inspiration on signing your own releases.
Signing is only one piece of the puzzle, so we’re also working on improved support for verification of base image signatures. We’re thrilled to be working with the Kubernetes release engineering team to validate signatures of the Distroless base images as part of the upstream ingestion process. This will give us invaluable feedback on our tooling as well as help protect a critical component of the cloud-native supply chain.
Our next major focus in cosign is a stable specification and format for signatures. This will hopefully enable other admissions controllers and build tools to validate and create signatures compatible with cosign. The first draft of this specification is available here, and we’d love any feedback on how to make it easier to use, more flexible, or more secure!
We’re hoping to work with the TektonCD, JenkinsX, Shipwright and other popular container-based CICD platforms to make signing and transparency easy and automatic. Please let us know if you’re interested in helping out or integrating signatures into your tooling!
Finally, our root CA (Fulcio) is also stabilizing quickly! We’re happy to announce the first draft of our community-based root-key protection plan is ready for feedback. Our goal is to design a distributed root-of-trust that allows a wide set of community members to act as “key holders”. This root-of-trust will be used to protect our transparency logs, code-signing CA certificates and timestamp servers.
We’re hoping to make this key ceremony and process fun and secure, and involve the broader community as much as possible. Please take a look at the plan and give us any feedback you have!
As always, we truly welcome contributors and users to our community. We take pride in being friendly to new folks and fostering a welcome and safe environment. Being a large open source project, there is always lots to do and it’s not always complex coding tasks, helping with documentation, general testing or just telling others about sigstore are all valued contributions.
We’re working to stabilize our APIs and platform as fast as possible, please come help out if you want it ready even faster! We tag all new contributor issues with a good-first-issue tag, which is a great way to get your feet wet working in the Sigstore ecosystem.
If you’re stuck and can’t find any ideas, you could also join our office hours! These are casual calls where maintainers are just working on issues together and we’re always happy to help get new contributors setup to help out. We run these during US office hours and Euro / Asian friendly hours. Follow our community calendar for updates!