Dogfood verification

[jku]

I'm not a complete beginner and I still have trouble understanding what exactly I can actually verify with sigstore-python at the moment... It would be helpful if there was an example in the documentation of verifying e.g. that a sigstore-python release was actually built by the github action of the project.

The status at the moment seems to be:

• certificate and signature could easily be published along the artifacts (since sign --output-* options were just added) but currently they are not published
• There is a somewhat undocumented verify --cert-email option that seems to be what I want, just slightly badly named: it looks like it would allow me to check that SAN contains URI:https://github.com/sigstore/sigstore-python/.github/workflows/release.yml@refs/tags/$VERSION
• I imagine in addition to SAN I should verify that the signing key is a github key? Is there a process for this or should the verifying script just hardcode the keyid? Should there be an option in verify for this?

I'd really like to use sigstore-python for this exact purpose so I'm willing to do some work here but I think I need a bit of guidance at least: Is my understanding of how to verify that build artifacts were built by a specific github action correct? Am I missing anything with regards to my last bullet point: how do I verify that the cert actually comes from GitHub?

[woodruffw]

It would be helpful if there was an example in the documentation of verifying e.g. that a sigstore-python release was actually built by the github action of the project.

Agreed! We can prioritize this.

• certificate and signature could easily be published along the artifacts (since sign --output-* options were just added) but currently they are not published

Yep, this should be easy to include in our release workflow.

• There is a somewhat undocumented verify --cert-email option that seems to be what I want, just slightly badly named: it looks like it would allow me to check that SAN contains URI:https://github.com/sigstore/sigstore-python/.github/workflows/release.yml@refs/tags/$VERSION

Yeah, this name isn't great...I believe we cribbed it from cosign, but it should really be --cert-san or --cert-identity or something like that, to clarify that it can be any OIDC identity.

• I imagine in addition to SAN I should verify that the signing key is a github key? Is there a process for this or should the verifying script just hardcode the keyid? Should there be an option in verify for this?

I might be misunderstanding what you mean, but in this case the signing key should be ephemeral and not directly verifiable. The bootstrap process is:

• Generate an ephemeral signing key (SK)
• Bind SK to the OIDC token (OT) by signing for it
• Send a Certificate Signing Request to Fulcio with the public component of SK, OT, and the binding proof
• Fulcio responds with a cert and SCTs, which we verify
• We sign the artifacts with SK, and commit their signatures, hashes, and the signing cert to Rekor

So in this case, verifying the artifact can take a few forms:

• If you just want a proof that some fixed identity signed for the artifact, you can query Rekor for both the identity and artifact and cross-check the hashes.
• If you want to verify that an exact signature and certificate exist for the artifact, you can use sigstore verify with the signature and certificate as inputs; that'll verify the signature locally (using the certificate) and perform all of the Rekor queries/inclusion proofs to assert that the log contains a record of the signing and that the record is consistent/timely.

So, TL;DR, you shouldn't need to hardcore or otherwise specify any inputs other than the ones sigstore verify already takes, at least if I understand correctly 🙂

[di]

I imagine in addition to SAN I should verify that the signing key is a github key?

I think what @jku means here is that he wants to verify that the issuer is GitHub, this should be possible by adding a flag like cosign's --cert-oidc-issuer, which should be part of #27.

(Also just want to point out that this library is currently broken due to #105)

[jku]

If you just want a proof that some fixed identity signed for the artifact...

I would like proof that the artifact was built by a GitHub build host using the sigstore-python workflow (and was not e.g. built locally by a malicious maintainer who modified the artifact). I now know how to verify that someone claims that the sigstore-python workflow was used... but I'm not sure that information is useful for me?

Maybe your comment about querying Rekor for the identity is the piece that I'm missing (but i can't find more info on that). Or maybe this is just not something these signatures are good for?

[di]

Also linking https://github.com/sigstore/cosign/issues/1313 and https://github.com/sigstore/cosign/issues/1947 here, which are related.

[jku]

I think what @jku means here is that he wants to verify that the issuer is GitHub, this should be possible by adding a flag like cosign's --cert-oidc-issuer

Yes this looks like it!

[woodruffw]

Okay, that makes sense! Yes, we should definitely add a flag that supports that. I can look into it today (although, like @di said, we're currently broken due to changes to the production sigstore instance).

[woodruffw]

We just cut 0.5.0, so I'll work on a patch release that dogfoods verification as part of the release CI.

[jku]

Closing this could be a little premature considering that the only thing that is currently verifiable is that some sort of build was done ins some project on a GitHub builder (aka checking oidc provider) -- the used project, sources or workflow aren't verifiable. But there's obviously momentum here so I'm not really complaining :)

[di]

I agree.

[jku]

One more thought on this, seeing how there's some hesitation in sigstore/cosign on how and if to expose the X509 extensions or even the SAN to CLI (and knowing that those extensions are essential to usefully verifying build integrity -- at least without using much heavier solutions like https://github.com/slsa-framework/slsa-github-generator).

It's entirely possible that a generic verifying tool like python -m sigstore verify maybe shouldn't expose those extensions in its command line interface (at least not before cosign has a design for this). Instead, the project could provide a sigstore-github-verify tool or just a separate command python -m sigstore github-verify that can assert things about those extensions and can even provide a better CLI because it's not generic (obviously this tool could also be external if sigstore-python had an API).

Thoughts?

[woodruffw]

I'd be in favor of something like that.

I'd personally prefer a "mode-switching" flag under the sigstore verify command, something like sigstore verify --github, which in turn would expose/enable a bunch of other options. My rationale: adding a new subcommand duplicates a lot of "common" functionality that hasn't been fully stabilized yet (= more refactor work for us later), and doing it with a "mode" flag gives us the opportunity to lead by example (and hopefully push cosign in the right direction).

But I think @di has the final say 🙂

[di]

I'm kind of interested in exploring a single-file format that encapsulates all these options first, see https://github.com/sigstore/sigstore-python/issues/124

[di]

This should be possible now that #157 is resolved.

[woodruffw]

@jku is there other functionality/testing you'd like to see for a closeout of this issue? I think the CLI and API themselves now cover everything you mentioned, but I didn't want to close this out unilaterally 🙂

[jku]

Yeah, looks good to me. If there are further things to improve, new issues would be more useful. Closing