Trusted publisher broken or misconfigured

[henryiii]

I've not been able to release - see https://github.com/scikit-build/moderncmakedomain/actions/runs/5087974019 for example. I really can't see anything wrong on either end. @webknjaz, any ideas what this might mean?

invalid-publisher: valid token, but no corresponding publisher

[webknjaz]

Looks correct. The only thing I can assume is moving the repository after the trust link creation (which I suppose you didn't do) or malformed values during copying or typing in. Like having zero-width whitespaces, trailing/leading spaces or characters that look like ASCII but are from other unicode ranges 'ï' != 'ї', 'c' != 'с' etc.
If it's none of these things, I'd assume a bug in PyPI.

@woodruffw — would it be possible to attach the data PyPI received to error messages it returns?

[woodruffw]

Thanks for the ping 🙂

The only other thing that stands out is that you're using an environment with name: and url: subkeys, but that shouldn't cause an issue.

would it be possible to attach the data PyPI received to error messages it returns?

That would be the OIDC JWT, so I'm not sure that's advisable -- attaching it would mean potentially leaking a still valid short-lived token from GitHub or another provider.

CC @di as well -- I doubt it, but maybe related to the temporary form regression last night?

[webknjaz]

you're using an environment with name: and url: subkeys, but that shouldn't cause an issue

I'm using this syntax everywhere and it works well for me.

[webknjaz]

That would be the OIDC JWT, so I'm not sure that's advisable -- attaching it would mean potentially leaking a still valid short-lived token from GitHub or another provider.

But it contains some non-secret payload, right? It'd be nice to expose what's safe...

[webknjaz]

@henryiii if this was a temporary regression on PyPI, this can be verified by restarting the job to see if it succeeds.

[woodruffw]

But it contains some non-secret payload, right? It'd be nice to expose what's safe...

In principle yes, although the claims can also contain sensitive values (the JWT as a whole is meant to be treated as a secret; nothing prevents GitHub from adding secret materials to the claim set).

We could probably carve out the specific values that PyPI ends up using, but IMO that would be better suited to the client side anyways -- doing it on PyPI necessarily means parsing the JWT before verifying its signature, and that quickly leads to doom 🙂

if this was a temporary regression on PyPI, this can be verified by restarting the job to see if it succeeds.

As part of this, it might be worth trying to delete and re-add the trusted publisher's configuration. I doubt that this was a form issue, but just to eliminate another variable!

[jcfr]

To provide some additional context, back in 2021¹ we transferred the project to the scikit-build organization.

t might be worth trying to delete and re-add the trusted publisher's configuration

I doubt that this was a form issue, but just to eliminate another variable!

@henryiii I will let you take care of this.

Footnotes

1. https://github.com/scikit-build/scikit-build/pull/574#issuecomment-893603529 ↩

[jcfr]

this can be verified by restarting the job to see if it succeeds.

CD workflow just got restarted. Still failing:

Run pypa/gh-action-pypi-publish@release/v1
/usr/bin/docker run --name ed866ef38f024c6298434daee107a4c1759eb4_f5989a --label ed866e --workdir /github/workspace --rm -e "INPUT_USER" -e "INPUT_PASSWORD" -e "INPUT_REPOSITORY-URL" -e "INPUT_REPOSITORY_URL" -e "INPUT_PACKAGES-DIR" -e "INPUT_PACKAGES_DIR" -e "INPUT_VERIFY-METADATA" -e "INPUT_VERIFY_METADATA" -e "INPUT_SKIP-EXISTING" -e "INPUT_SKIP_EXISTING" -e "INPUT_VERBOSE" -e "INPUT_PRINT-HASH" -e "INPUT_PRINT_HASH" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e "ACTIONS_ID_TOKEN_REQUEST_URL" -e "ACTIONS_ID_TOKEN_REQUEST_TOKEN" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/moderncmakedomain/moderncmakedomain":"/github/workspace" ed866e:f38f024c6298434daee107a4c1759eb4  "__token__" "" "" "" "" "" "false" ""
Notice: Attempting to perform trusted publishing exchange to retrieve a temporary short-lived API token for authentication against https://upload.pypi.org/legacy/ due to __token__ username with no supplied password field
Error: Trusted publishing exchange failure: 
Token request failed: the server refused the request for the following reasons:
* `invalid-publisher`: valid token, but no corresponding publisher

[henryiii]

Deleting and filling out the form (with the same values AFAICT) did the trick!

[henryiii]

[woodruffw]

Deleting and filling out the form (with the same values AFAICT) did the trick!

Thank you for confirming, and I'm very sorry for the hiccup there! The form refactor that might have caused the problem was reverted, and we'll take a closer look at it to try and root cause.

[jcfr]

Thanks y'all for the help.

~8hrs after observing issue it is fixed. This is 👌💯

[di]

When was the form originally submitted prior to publishing failing?

[jcfr]

It was added around the time of this comment. See #28 (comment)

[di]

Ah, yeah, you probably fell into a narrow window of an outage here, sorry for the trouble!

[jcfr]

No worry and glad we were able to understand the "root" cause 👌

Thanks for taking the time to follow-up 🙏

[jcfr]

Overall the Trusted Publisher feature has been straightforward to use and really helped streamlined the whole workflow.

So thanks for working on it.

[henryiii]

3.27.0 was fine. :)