-
-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
invalid-publisher
: valid token, but no corresponding publisher
#173
Comments
Sounds like a warehouse problem... @di @woodruffw could you look into this? |
This wouldn't be related. |
Was this right before the third run? Maybe, you made a typo somewhere and repo or env doesn't match? |
Looks like your publisher is configured with an environment:
but I don't see that environment listed anywhere here: https://github.com/eifinger/pywaze/blob/main/.github/workflows/release.yml I would expect to see something like Unfortunately I can't see how your original publisher was configured, did it have an environment set? |
The third run has 3 attempts. I readded the publisher between the 2nd and 3rd attempt |
I had some issues with GitHub in the last weeks showing different commits on some branches in different sessions. For me the environment is visible on line 13: https://github.com/eifinger/pywaze/blob/main/.github/workflows/release.yml#L13 |
Hmm, I can see the It's possible this was some kind of weird hiccup on GitHub's side, given the inconsistent results that people are seeing for the workflow's contents. Could you try running your release workflow again? |
Ah, sorry, looks like I just can't read 😂 |
Attempt 4 failed as well https://github.com/eifinger/pywaze/actions/runs/5794194719/job/15724456812 |
Thanks! Just for our reference, here's the workflow from that successful publish: This is pretty strange -- I don't see anything salient between that successful publish and the workflow that's failing 😕 |
The only thing that changed is that this was likely converted from a pending publisher to a regular publisher, so something doesn't agree in the publisher queries/verification between the two. I'm working on adding some better error messages here (there are a lot of failure modes that would result in this one error message) which should at least help narrow this down. |
@woodruffw The changes in question are here: pypi/warehouse#14308. @eifinger Sorry you're having trouble here. Could I kindly ask that you don't change anything with your setup here for the time being? We should be able to ship this change shortly after which we can re-run your workflow to get some additional details on why this is failing. |
Doing nothing? Yeah I think I can handle that 😄 |
@eifinger Ok, these changes should be live now, can you attempt to re-run one of these failing workflow attempts and report back? It should still fail, but will have a different error message. Thanks! |
Not alone: https://github.com/elupus/gardena-bluetooth/actions/runs/5811885732/job/15756416437#step:7:92
|
Hmm, I wonder if GitHub went and changed the |
For context, here's our def _check_job_workflow_ref(ground_truth, signed_claim, all_signed_claims):
# We expect a string formatted as follows:
# OWNER/REPO/.github/workflows/WORKFLOW.yml@REF
# where REF is the value of the `ref` claim.
# Defensive: GitHub should never give us an empty job_workflow_ref,
# but we check for one anyways just in case.
if not signed_claim:
return False
ref = all_signed_claims.get("ref")
if not ref:
return False
return f"{ground_truth}@{ref}" == signed_claim |
@woodruffw Just noticed that that check is actually looking at the |
Just to copy state here: this should be fine, since |
NB: I just successfully published one of my own projects using a trusted publisher, so whatever's happening here isn't consistent. As a further debugging step, I'll look into having this workflow decode the OIDC identity and dump some of its claims. |
Failed for me as well with: |
Got it, thanks for confirming. Could you humor me and try it again from a clean run? I don't expect it to change, but just for an additional datapoint 🙂 |
Will try with a new release later today. |
I've also opened #174 with some changes that should assist in debugging here: if you configure your publishing workflow to use that branch rather than the normal release, it should give us some additional context here 🙂 |
We've deployed some new changes with even more error messages, @eifinger can you re-run the workflow and let us know what you see? |
@martibosch I don't see any Trusted Publishers configured for https://pypi.org/p/pylandstats, see https://docs.pypi.org/trusted-publishers/adding-a-publisher/ for details on how to do that. |
Same:
|
Same:
|
Released in v1.8.9 |
https://github.com/eifinger/pywaze/actions/runs/5794194719/job/15797156287 Traceback (most recent call last):
File "/app/oidc-exchange.py", line 206, in <module>
rendered_claims = render_claims(oidc_token)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/app/oidc-exchange.py", line 147, in render_claims
claims = json.loads(base64.urlsafe_b64decode(payload))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/base64.py", line [13](https://github.com/eifinger/pywaze/actions/runs/5794194719/job/15797156287#step:7:14)4, in urlsafe_b64decode
return b64decode(s)
^^^^^^^^^^^^
File "/usr/local/lib/python3.11/base64.py", line 88, in b64decode
return binascii.a2b_base64(s, strict_mode=validate)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
binascii.Error: Incorrect padding |
My bug, sorry. Fixing now. |
Looks like we need to start having pytest-based tests too.. |
Yeah...I can look at adding some in the next few days, if you'd like. |
If you have time, this would be welcome. Meanwhile, I released v1.8.10 with the hotfix. |
Looking more lika a workable error:
|
Yeah, this is confirming the strange behavior we expected: GitHub is creating some OIDC JWTs with a SHA-1 ref in the |
Oops, didn't expect that PR to close an issue over here, reopening... |
This should now be resolved for those experiencing the original issue. Anyone in the future thinking they are experiencing this should ensure they have created and correctly configured a publisher by following these docs: https://docs.pypi.org/trusted-publishers/adding-a-publisher/ @webknjaz I'll let you determine if there's anything left to do here and if this can be closed. |
Thanks, I think it's fine to close this. If anybody hits publishing issues in the future, they'll likely have different causes and would require a new issue. But I invite the reporters to leave a comment confirming that the issue is fixed for them. |
I can confirm that the issue is resolved for me: https://github.com/eifinger/pywaze/actions/runs/5794194719/job/15810516147 |
Confirmed here too! |
it was indeed my mistake as I had not configured the trusted publishing in pypi. In any case, it may be helpful to add the link https://docs.pypi.org/trusted-publishers/adding-a-publisher/ in the "Trusted publishing" section of the README - especially since it is something that is quite new. In any case, thank you @woodruffw and @di for pointing my issue out. |
@martibosch Good point, I've added a link to it here: #179 |
Thanks everyone! The README update with the link merged. |
Hi,
I have a release workflow which suddenly stopped working:
invalid-publisher: valid token, but no corresponding publisher
Aside the version numbers I did not change anything.
I also tried to remove the trusted publisher and add it again and rerun the action but still no success.
What could be the reason that this worked the first time but not since then?
The text was updated successfully, but these errors were encountered: