Start publishing the cursed token on GitHub Pages

[jku]

Start publishing the token on GitHub Pages (https://sigstore-conformance.github.io/extremely-dangerous-public-oidc-beacon/oidc-token.txt):

• This makes it a lot easier to find, download and use the token
• The old artifact upload is preserved so current scripts (so sigstore-conformance 0.7, 0.8) should keep working

Fixes #5.

Details:

• All known sigstore-conformance users have updated to v0.8 or are using main: I believe this is safe to merge.
• The GitHub Pages source is set to "Actions" in GH settings so this should start working right away. I can't see the environment settings but they should be correct by default (there should be a "github-pages" env and main branch should be allowed to deploy).
• The legacy artifact upload that is currently preserved can be removed once sigstore-conformance uses the new token location and we've seen that it's reliable.
• At that point I think the workflows in this project can be simplified significantly: the reason for the workflow dispatch dance is that published artifacts are not made available until the workflow finishes -- that limitation likely does not apply to Pages publishing (although it remains to be seen if GitHub is ok with publishing to Pages multiple times from the same workflow)

[jku]

This is a draft until sigstore/sigstore-conformance#102 is merged

I suppose we should wait until there's a sigstore-conformance release and until the known users have upgraded as well.

[jku]

note to self: All conformance users have now upgraded (or are using main branch).

[jku]

This bit in sigstore-conformance I'm not sure about:

_OIDC_BEACON_WORKFLOW_ID = 55399612

Does the workflow id stay the same? I expect that it does but I can't be sure.

[woodruffw]

Does the workflow id stay the same? I expect that it does but I can't be sure.

I think it does, but we can confirm/update with https://docs.github.com/en/rest/actions/workflows?apiVersion=2022-11-28#get-a-workflow if it breaks after merging 🙂

[woodruffw]

LGTM! I'd like @tetsuo-cpp or @tnytown to also take a brief look at this if either have time 🙂

[tnytown]

In my experience, GitHub Pages sometimes takes a bit to propagate changes due to caching -- is this a concern w.r.t. the tokens, given their relatively short validity period?

Implementation LGTM!

[woodruffw]

In my experience, GitHub Pages sometimes takes a bit to propagate changes due to caching -- is this a concern w.r.t. the tokens, given their relatively short validity period?

Caching on the HTTP header side, or caching on the deployment side? I wouldn't be surprised if GHP serves HTTP caching headers, but we can always ignore those 🙂

[tnytown]

Caching on the HTTP header side, or caching on the deployment side? I wouldn't be surprised if GHP serves HTTP caching headers, but we can always ignore those 🙂

IIRC the deployment side, it's been a while since I've had to worry about it. I've never experienced a delay of more than 5 minutes, but that may still impact the validity period of the tokens if the behavior is still present :(

[woodruffw]

Gotcha. I think we can go ahead and deploy this as-is; if we run into consistent issues, then we'll look into another publication mechanism or location.

[woodruffw]

Appears to be working: https://sigstore-conformance.github.io/extremely-dangerous-public-oidc-beacon/oidc-token.txt