dlor

We've been working with PyPI to help integrate Sigstore, which makes signing (and verification) easier!

sigstore.dev

Sigstore is pretty useful on it's own as a way to sign and verify software, but it can also be used to build higher level applications like this one.

Happy to answer questions!

We used to actually run an RFC3161 timestamp server in addition to the transparency log but recently turned it down because no one was using it. I'd like to bring it back for stuff like this.

https://github.com/sigstore/gitsign/issues/22

I don't disagree. The current state of git signing is pretty bad. I wrote more here: https://link.medium.com/zqy8VVzAJqb

I'm a maintainer on gitsign and think we can fix it though!

We're working on fixes for both of those issues!

We're working on a GitHub App to work around the badge issue - it will also let you specify fine-grained policies instead of just signed or unsigned.

The tty issue on remote VMs is also getting fixed soon!

Disclosure: I work on Sigstore.

A bunch of comments below indicated that this is technically an abuse of the CT logs. Feel free to use Sigstore instead for this, it's basically the same architecture as CT logs except we officially support and endorse this use case.

https://www.sigstore.dev/

You're assuming the pay is cash. Most CEO (and high level executive) compensation is stock, which is taxed much differently from salaries. The tax brackets have very little effect.

We use the generic in-toto Attestation data model which could capture crev style reviews, but there are no other concrete plans that I'm aware of.

To be honest, crev is pretty elegant but I find manual code review like this to be pretty ineffective in stopping attacks.

Sigstore maintainer here. I'll try to answer questions!

Thanks! We moved some code between repos and missed that link. Its fixed now!

This is a timely post! We're actually working on merging Distroless with Alpine for the best of both worlds. You can check out some of the progress in Apko and the new Distroless GitHub org.

https://github.com/chainguard-dev/apko http://github.com/distroless

Blog post: https://blog.chainguard.dev/introducing-apko-bringing-distro...

Disclosure: I helped start the Distroless project years ago and now work at Chainguard.

What's the rest of your stack? Do you need RUN commands, or is it a different package format we could add here?

Thanks! They're both only a month or so old, and still moving fast. Please leave some feedback in the repo if you'd like to see anything else!

Disclosure: I work at Chainguard.

Not sure, there have been a few issues filed but no official reply.

Thanks for the cosign mention! Maintainer here. The link is github.com/sigstore/cosign for anyone reading along!

I would disagree with "Use Docker Content Trust for Docker Hub".

Docker hasn't been signing official images for the last several years, so turning this on means you'll get the last correctly signed images, which happen to be years out of date.

Hey Tyler!

Funny to see you here. Matt and I haven't given up on this, we're giving a lot of that another try at Chainguard.

I've been involved with the OpenSSF since the start and would be happy to answer questions about this initiative or anything else!

I helped start the Scorecards, SLSA, and Sigstore projects, which are all in the OpenSSF.

https://github.com/ossf/scorecard

https://slsa.dev/

https://www.sigstore.dev/

I'm a maintainer on Sigstore, and we published this blog post in support of this effort too!

https://blog.sigstore.dev/sigstore-ruby-ce3591838fe8

Probably not for Go in containers since binaries end up compressed anyway as part of the OCI layers. But Go binaries do get quite large so if you're distributing them other ways, it might be useful.

This is a great resource. I'd love to see more reports like it published. CI/CD pipelines often run with highly elevated permissions (access to source code, artifact repositories, and production environments), but they are traditionally neglected.

Yes yes yes yes!

For some reason people want a formal specification for everything, even when "N/A" is an applicable option here.

CBOR itself is not a draft (that's the fork of msgpack).

I think COSE (which is what the post was actually about) is though: https://datatracker.ietf.org/doc/html/rfc8152

Author here. I have nothing to do with any of those formats and didn't create or design any.

I have no more context than you do either, and was surprised to find that thread on the IETF tracker to begin with.

Oh my god the name just clicked. I knew some of the history but didn't catch he named it after himself.

Author of the original medium post here. I had simply never heard of COSE at the time of writing this. There was no conspiracy to bury the spec.

There are a bunch of vague accusations that I'm trying to profit or rent seek off of one of the specs I did write about. I didn't create and I don't maintain any of those. I also wouldn't trust any crypto designed by myself.

The original context for writing this post was discussions around using JOSE in the context of signing container images [1]. I was against it and preferred something simpler.

https://github.com/notaryproject/notaryproject/pull/93

Nothing really yet. Containers got relatively close with Notary V1, I'm focused on fixing that here in sigstore right now. I think Python, Ruby, and NPM would be great targets to go after next!

Whoa, sigstore maintainer here. I've never seen or heard of Gossamer before. It seems very similar in design!

Attacks here are incredibly common. Fortunately they're usually unsophisticated and are just plain crypto mining to steal CPU cycles.

Worst case is if a CI system has permissions to deploy to production, which is really common too.

Another common one to watch out for is permissions to publish artifacts. It's very common for a CI system to build and test something like a container image, then for another system to promote that image to production. Even when the CI system can't touch production directly, it can still be used to pivot to more sensitive targets.

Great find and write-up from the teleport team.