Add tests for local containers in CI

[ramonpetgrave64]

Description

The new Action at https://github.com/sigstore/scaffolding/tree/main/actions/setup-sigstore-env can setup containers within a Workflow run, and it can generate a trusted root (currently not signing config v0.02) and signing config to make it easy to use from the CLI.

It tracks mainline of the services Fulcio, Rekor, TSA, the new rekor-tiles, and provides a fakeoidc provider we might find useful.

Since it tracks mainline, we might run tests with this Action on a daily timer, just to make sure new changes will be compatible.

[jku]

Since it tracks mainline, we might run tests with this Action on a daily timer, just to make sure new changes will be compatible.

I'll point out that if the test runs in sigstore-python project it's not about "making sure changes are compatible" -- if you wanted to do that, you should have run the test in the infra projects, before merging the code.

The issue with testing here is that it pushes the responsibility to react to failures to sigstore-python: this project does not have a huge amount of developers willing to monitor tests like this... Maybe this does makes sense, but this is the compromise that would be made. We'll want to carefully evaluate what we want to test against -- some possible examples:

1. staging and prod only (status quo)
2. staging, prod and a local test setup running latest infra releases
3. staging, prod and a local test setup running every infra commit

My hunch is that the last option seems unlikely, but the second one might be interesting?

[ramonpetgrave64]

I was just trying this today and it looks like we need some more work on both the set-sigstore-env Action side and in sigstore-python

• The fakeoidc provider might need to contain more fields in it's .well-known-configuration response:

  • authorization_endpoint and token_endpoint, as expected by sigstore-python

    • sigstore-python/sigstore/oidc.py

      Lines 48 to 57 in d05a629

      	class _OpenIDConfiguration(BaseModel):
      	"""
      	Represents a (subset) of the fields provided by an OpenID Connect provider's
      	`.well-known/openid-configuration` response, as defined by OpenID Connect Discovery.
      	See: <https://openid.net/specs/openid-connect-discovery-1_0.html>
      	"""
      	authorization_endpoint: StrictStr
      	token_endpoint: StrictStr

  • https://github.com/sigstore/scaffolding/blob/c1697866accfa0fbe21caf7e16ab85f236695428/actions/setup-sigstore-env/fakeoidc/main.go#L37-L40

• Not 100% sure about this one: For compatibility with this local provider, I think we'll also need to try to get the token before trying to follow the authorization_endpoint.

My current workaround: invoke with --identity-token curl <host>/token. We can't just remove oidcUrls from the trust config because then the local fulcio won't respect the ambient oidc provider.