warehouse: `invalid-pending-publisher` when using OIDC to upload 2nd version of package

Describe the bug Not sure if this is a bug, but at least it was unexpected, and the OIDC Troubleshooting guide wasn’t very helpful.

In this CI run, I got Token request failed: the server refused the request for the following reasons: invalid-pending-publisher: valid token, but project already exists

So, I went ahead and downloaded the .whl files generated from that CI run, and manually uploaded them from my laptop using twine. That worked. I haven’t tried again using OIDC to see if it will work again now that I did a fresh upload.

Expected behavior Upload to PyPI should work: The project exists, and I have the OIDC configured correctly.

To Reproduce You can see the workflow file used at https://github.com/NickCrews/feco3/actions/runs/5899323313/workflow.

Screenshot of OIDC config: image

Here is the complete security audit log for my project (screenshot taken Aug 17, 2023) image

Was this something to do with enabling 2FA?

Also, this doesn’t show up in the security log, but I thought I remember back in June adding GitHub as a “pending trusted publisher”, and then a very similar thing happening, and I think that is why I uploaded v0.3.0 of the project using Twine back in June. Perhaps this was bugging out because of some stale state where PyPI thought that my OIDC registration was pending, when now I don’t even see an option int the PyPI webUI to to add pending publishers?

About this issue

  • Original URL
  • State: closed
  • Created 10 months ago
  • Comments: 15 (9 by maintainers)

Commits related to this issue

Most upvoted comments

Hi @woodruffw

I searched for “publish on pypi” and found the page https://packaging.python.org/en/latest/tutorials/packaging-projects/

Hi @robertdj, it’s still unfixed. Can you tell us what project you tried to publish so we can verify this is the same issue you’re having? What error messages did you get?

We could probably carve out a subset of cases here: if the package is manually uploaded by the same user who has the pending publisher registered, then it’s probably safe to reify that pending publisher into a normal one.

Yes, I think that’s the fix that we should implement here.

Thanks for the issue! Seems like we have an edge case here where we’re not properly converting “pending” publishers if the project gets created via a regular upload instead.

I think this is the timeline of what happened, does this look right to you?

Time Action
2023-06-06 17:45:27 UTC You created a “pending” publisher for feco3
2023-06-06 18:26:53 UTC You did a manual upload of https://pypi.org/project/feco3/0.3.0/ with maturin
2023-06-09 23:38:14 UTC This workflow run failed with invalid-publisher: valid token, but no corresponding publisher
2023-08-16 06:12:36 UTC This workflow run found the pending publisher, deleted it, and returned the error invalid-pending-publisher: valid token, but project already exists
2023-08-17 23:04:35 UTC This workflow run found no publishers, and returned the error invalid-publisher: valid token, but no corresponding publisher (All lookup strategies exhausted)
2023-08-18 05:36:35 UTC You created a regular publisher for feco3
2023-08-18 06:38:57 UTC You did a manual upload of https://pypi.org/project/feco3/0.5.0/ with twine

I think in the current state future runs of your CI.yml workflow should successfully publish without the need to change anything.

Was this something to do with enabling 2FA?

No, this is unrelated.

Also, this doesn’t show up in the security log, but I thought I remember back in June adding GitHub as a “pending trusted publisher”, and then a very similar thing happening, and I think that is why I uploaded v0.3.0 of the project using Twine back in June. Perhaps this was bugging out because of some stale state where PyPI thought that my OIDC registration was pending, when now I don’t even see an option int the PyPI webUI to to add pending publishers?

As far as I can tell it appears that you uploaded v0.3.0 first, and then had a failing workflow run. I couldn’t find any runs before that, do you have the CI run which would have corresponded to that prior failure?

I am curious why the first workflow run failed, is it possible something changed with the repository/workflow name?