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
Here’s a quick walkthrough of a draft tool (still WIP!) to securely fetch published contents from an OCI registry, called
sgetis part of the sigstore project, and is a standalone client that allows you to retrieve scripts or binaries from any OCI registry.
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!
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. I’ll also outline some areas we need help, and how to get involved!
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.
Naming is hard, but TUF really isn’t a framework in the traditional sense. In my head, a framework is something like a…
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? How do users verify it? Why are we even doing this again? If you (understandably assumed) that this was a solved problem, you’re in good…
The protocol and format explained!
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.
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. The public key looks like this:
— — -BEGIN PUBLIC KEY — — -
— — -END PUBLIC KEY — — -
The private key is marshaled into PKCS8 formatted bytes…
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).
Public keys are stored in plain old PKIX files. They look like:
-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEroVS8KdYXp5SSI5YDwwQymSByQAM 7MDgk9po3wpp/hHZAzCLsu+j3axrJJ5nMet9tqX1eH8yk21G626Z8lrkQA== -----END…
This took me awhile to figure out, so I thought I would write it down in the hopes it saves someone else time later.
I have a Golang app that runs on Kubernetes (in my case GKE) that I want to add some basic monitoring to. I was hoping for a solution that roughly meets these requirements:
Searching and reading examples led me down a two routes: OpenTelemetry/OpenCensus and…
Making “many eyes” a reality with automation
Many advocates of open source software claim it is easier to make secure because it has “many eyes” looking at it. It is probably true that in the limit enough eyes can catch all bugs, but there’s no evidence we’ll ever hit that limit. Thankfully, we can help add more eyes to OSS with automation. This post explains how I built a platform to hunt for malicious behavior hiding in plain sight.
The specific type of malware I’m looking in this post embeds itself in open source packages, and exploits the fact that…
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. I’ve only been able to find one other blog post explaining how it works (outside of the man pages).
Software Engineer at Google