Bad Request for url: https://fulcio.sigstore.dev/api/v2/signingCert

[gaborbernat]

https://github.com/tox-dev/filelock/actions/runs/16941242974/job/48012593889

Retrieving signed certificate...
Traceback (most recent call last):
  File "/root/.local/lib/python3.12/site-packages/sigstore/_internal/fulcio/client.py", line 237, in post
    resp.raise_for_status()
  File "/root/.local/lib/python3.12/site-packages/requests/models.py", line 1024, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://fulcio.sigstore.dev/api/v2/signingCert

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/app/attestations.py", line 149, in <module>
    main()
  File "/app/attestations.py", line 142, in main
    with SigningContext.production().signer(identity, cache=True) as signer:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/contextlib.py", line 137, in __enter__
    return next(self.gen)
           ^^^^^^^^^^^^^^
  File "/root/.local/lib/python3.12/site-packages/sigstore/sign.py", line 364, in signer
    yield Signer(identity_token, self, cache)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/.local/lib/python3.12/site-packages/sigstore/sign.py", line 105, in __init__
    self.__cached_signing_certificate = self._signing_cert()
                                        ^^^^^^^^^^^^^^^^^^^^
  File "/root/.local/lib/python3.12/site-packages/sigstore/sign.py", line 159, in _signing_cert
    certificate_response = self._signing_ctx._fulcio.signing_cert.post(
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/root/.local/lib/python3.12/site-packages/sigstore/_internal/fulcio/client.py", line 244, in post
    raise FulcioClientError from http_error
sigstore._internal.fulcio.client.FulcioClientError

This stops the publish entirely 🤔

[webknjaz]

This is probably #364.

cc @woodruffw @haydentherapper

[bobcallaway]

this error shows up server-side as a failure to parse the CSR sent to Fulcio: asn1: syntax error: IA5String contains invalid character

[webknjaz]

@bobcallaway can it be due to that emoji in the GitHub Environment name? Are you able to extract the offending content to make sure?

[webknjaz]

Looks like GitHub itself isn't happy about it either: https://github.com/tox-dev/filelock/deployments/🚀%20Release%20to%20PyPI

@gaborbernat if I were to guess, dropping 🚀 might fix this. I bet it breaks both Sigstore and GitHub. I've seen emojis breaking GH in so many subtle ways in weird places over time so I wouldn't be surprised.

[woodruffw]

@bobcallaway and I spent some time looking at this, and I think we can confirm @webknjaz's theory!

Here's where sigstore-python produces the CSR:

https://github.com/sigstore/sigstore-python/blob/f8b4c5aa252ea89beef5ed5e372ebdf527fd9f95/sigstore/sign.py#L137-L154

The only user input that flows into the CSR is the "email" subject, which we get from the OIDC token's identity. That in turn flows from a claim depending on the kind of provider:

https://github.com/sigstore/sigstore-python/blob/f8b4c5aa252ea89beef5ed5e372ebdf527fd9f95/sigstore/oidc.py#L124

...and in GitHub's case, that claim is sub:

https://github.com/sigstore/sigstore-python/blob/f8b4c5aa252ea89beef5ed5e372ebdf527fd9f95/sigstore/oidc.py#L42

...and sub does contain the environment name by default:

https://docs.github.com/en/actions/reference/security/oidc#filtering-for-a-specific-environment

TL;DR: We have a mismatch between what the CSR expects (IA5String, i.e. ASCII) and what we actually send it (UTF-8). The temporary fix is to not put emojis in your environment names; the actual fix requires me to look at how we can construct a CSR in sigstore-python that preserves UTF-8. Maybe we just need a different subject "type" than email, since email is subtly wrong anyways.

[woodruffw]

NB: This is also unrelated to the other issues that were opened, which stem from Rekor timeouts. I think those are tied to larger GCP infrastructure problems at the moment, whereas this is a bug on sigstore-python's end.