[error] * `invalid-publisher`: valid token, but no corresponding publisher

[yozachar]

From validators/actions/runs/4550595346/jobs/8023753623

Run pypa/gh-action-pypi-publish@release/v1
/usr/bin/docker run --name c0442075403f75bc9417ab8fbffed20a2928e_3f477f --label 6c0442 --workdir /github/workspace --rm -e "pythonLocation" -e "PKG_CONFIG_PATH" -e "Python_ROOT_DIR" -e "Python2_ROOT_DIR" -e "Python3_ROOT_DIR" -e "LD_LIBRARY_PATH" -e "VENV" -e "INPUT_PASSWORD" -e "INPUT_USER" -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/validators/validators":"/github/workspace" 6c0442:075403f75bc9417ab8fbffed20a2928e  "__token__" "" "" "" "" "" "false" ""
Notice: Attempting to perform OIDC credential exchange  to retrieve a temporary short-lived API token for authentication  against https://upload.pypi.org/legacy/
Error: OIDC exchange failure: 
Token request failed: the server refused the request for the following reasons:

* `invalid-publisher`: valid token, but no corresponding publisher

What's wrong with validators/.github/workflows/build.yml?

# This workflow will upload a Python Package using Twine when a release is created
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python#publishing-to-package-registries

name: Build for PyPI

on:
  workflow_dispatch:
  release:
    types: [published]

permissions:
  contents: read

jobs:
  build_and_publish:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
    steps:
      # checkout repository
      - uses: actions/checkout@v3
      # setup lowest supported python version
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: "3.8"
      # install & configure poetry
      - name: Install Poetry
        uses: snok/install-poetry@v1
        with:
          version: 1.4.1
          virtualenvs-create: true
          virtualenvs-in-project: true
      # install dependencies
      - name: Install dependencies
        run: poetry install --no-interaction --no-ansi --only docs
      # build package
      - name: Build package
        run: |
          source .venv/bin/activate
          python build.py
      # publish package
      - name: Publish to PyPI
        uses: pypa/gh-action-pypi-publish@release/v1
        with:
          password: ${{ secrets.PYPI_API_TOKEN }}

[webknjaz]

@joe733 you forgot to declare the secret containing a PyPI API token, in you repository settings (global, or environment-scoped). So the action got an empty password input which triggered the new OIDC flow for secretless uploads. This feature is in private beta now so you need to set the secret to disable it.

https://github.com/python-validators/validators/actions/runs/4550595346#summary-12355045595

@woodruffw do you think we should add some title/pointer to the job summary to mention it's OIDC? Also explaining that to turn off the flow, one should pass in a token/password?

[webknjaz]

@joe733 also, what's that build.py you're calling?

[webknjaz]

@joe733 also, I see that you added a id-token: write in a separate commit. Was it in response to a workflow error you saw? What can @woodruffw and I do to make it clear that this feature needs trust to be set up on the PyPI side but is only available to select users in private beta?

Also, @woodruffw — do we need to start pointing to the new public docs?

[webknjaz]

@joe733 if you want to enroll in private beta, here's some pointers: https://docs.pypi.org/trusted-publishers/. Otherwise, follow the instructions for making a project-scoped token.

[yozachar]

@joe733 also, I see that you added a id-token: write in a separate commit. Was it in response to a workflow error you saw?

Hi yes @webknjaz, I didn't know OIDC would be auto triggered if secrets.PYPI_API_TOKEN was empty. Nothing in the readme seems to indicate such a behavior.

Notice: Attempting to perform OIDC credential exchange  to retrieve a temporary short-lived API token for authentication  against https://upload.pypi.org/legacy/
Error: OIDC exchange failure: 
OIDC token retrieval failed: GitHub: missing or insufficient OIDC token permissions, the ACTIONS_ID_TOKEN_REQUEST_TOKEN environment variable was unset

This generally indicates a workflow configuration error, such as insufficient
permissions. Make sure that your workflow has `id-token: write` configured
at the job level, e.g.:

    ```yaml
    permissions:
      id-token: write
    ```

Learn more at https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#adding-permissions-settings.

Before the above notice another message could be given like:

Warning: secrets.PYPI_API_TOKEN is empty or rejected.
...

Or provide another option like:

with:
    oidc: false
    password: ${{ secrets.PYPI_API_TOKEN }} # gets ignored if oidc is true

I think the author @kvesteri currently uses conventional authentication.

rel: python-validators/validators#256 (comment)

[woodruffw]

do you think we should add some title/pointer to the job summary to mention it's OIDC? Also explaining that to turn off the flow, one should pass in a token/password?

Yeah, that makes sense to me. I can do that in a bit.

do we need to start pointing to the new public docs?

Also makes sense to me!

[webknjaz]

@woodruffw thanks for the PR! I was thinking that we could also have a clearer indication of why the OIDC flow got triggered in the first place. Like "Not using token- or password-based authentication because the user-provided password is empty". Other branches show things like "Using a user-provided API token for authentication" but this specific one doesn't, which is the primary cause for confusion, I suppose.

@joe733 suggested the following earlier:

Before the above notice another message could be given like:

Warning: secrets.PYPI_API_TOKEN is empty or rejected.

Or course, we cannot say secrets.PYPI_API_TOKEN in the error message because we have no way of knowing how the user named their secret or if they even provided token via a secret and not a plain text input 🤷‍♂️ but the idea in general is nice.

Or provide another option like:

with:
    oidc: false
    password: ${{ secrets.PYPI_API_TOKEN }} # gets ignored if oidc is true

Nope, the extra input idea was rejected to simplify the process for the end-users. Besides, we already have a clear indication for the OIDC opt-in which is an empty password + the __token__ user. Making the users manage a combination of inputs would increase cognitive load which would be unhelpful.

I think the author @kvesteri currently uses conventional authentication.

rel: python-validators/validators#256 (comment)

Likely, not many folks enrolled and have the feature flag for the private beta enabled.

[woodruffw]

@woodruffw thanks for the PR! I was thinking that we could also have a clearer indication of why the OIDC flow got triggered in the first place. Like "Not using token- or password-based authentication because the user-provided password is empty". Other branches show things like "Using a user-provided API token for authentication" but this specific one doesn't, which is the primary cause for confusion, I suppose.

Makes sense to me, I can do that in a bit!

[woodruffw]

Opened #142 with more exposition.

[tom-andersson]

Hey, unfortunately I'm getting the same error mentioned in the title of this issue when trying to use the trusted publisher feature. I've seen the discussion above from a couple month ago on this being a private feature for beta testers. However, it's now at the top of the README on release/v1 so I assumed that's no longer the case. Here's my YML and the associated logs - would appreciate it if someone could take a look: https://github.com/tom-andersson/deepsensor/actions/runs/5256689812/workflow