Trusted publishing: Support for GitHub reusable workflows

[woodruffw]

Our MVP implementation (#10753) assumes that the workflow is in the same repository, which is not necessarily true.

We should support reusable workflows, specifically via the job_workflow_ref claim.

[woodruffw]

Just as a note: this will have to interoperate with #11263.

[GergelyKalmar]

Any chance to expedite this issue? It seems there's many who would be eager to move over to trusted publishing now that it is the recommended approach, but not being able to do the flow from a reusable workflow is a pretty major blocker. This issue also does not seem to be documented anywhere so we only find out about it once we changed everything to use the new approach.

[woodruffw]

Any chance to expedite this issue?

I can't personally promise a timeline here, but it is on my backlog of things to do.

This issue also does not seem to be documented anywhere so we only find out about it once we changed everything to use the new approach.

Thank you for pointing this out; I'll make some changes to the docs to emphasize that reusable workflows are not currently supported.

[woodruffw]

Thank you for pointing this out; I'll make some changes to the docs to emphasize that reusable workflows are not currently supported.

I've opened #13592 for this. Thanks again for bringing it to our attention!

[webknjaz]

@woodruffw I just stumbled upon an example of a reusable workflow actually working with OIDC here jorisroovers/gitlint#486 — could you confirm this is because of secrets: inherit at https://github.com/jorisroovers/gitlint/blob/5247839/.github/workflows/ci.yml#L225 ?

[GergelyKalmar]

That workflow is in the same repository though, I think the issue is with reusable workflows that are in a different repository (e.g. in a separate public repo).

[woodruffw]

Yeah, I think that's because it's in the same repo, not because of secrets: inherit.

In other words: reusable workflows do work with the current implementation, just not reusable workflows that are external to the repository that the trusted publisher was configured with.

[webknjaz]

That workflow is in the same repository though, I think the issue is with reusable workflows that are in a different repository (e.g. in a separate public repo).

Yes, you can't use inherit across orgs. The issue was that the OIDC context has a reusable workflow reference and that's currently not checked IIUC. So my concern is that it might be possible to fool the verification logic in PyPI with this...

[GergelyKalmar]

You can get around the inherit issue between organizations via forking, which is what we would usually do. So same org, different repo would be fine. The point of reusable workflows in this case would be that you store them in a central repository and you can re-use them in other repositories.

[webknjaz]

I also wonder if it's possible to do something like

secrets:
  GITHUB_TOKEN: ${{ github.token }}

to make OIDC in the reusable workflow pretend to be the called workflow...

[thepwagner]

Is there a reason why we cannot match on workflow_ref (the top-level workflow) only?
The scenario we're trying to avoid is having overscoped Trusted Publishers

Could this just be a boolean + warning?

• Allow reusable workflows. ⚠ Only enable this if you're using a dedicated release workflow.

Behind the scenes, the checked box would mean only workflow_ref is verified, per _mhils suggestion.

---

Or a really out there idea: decode workflow_ref and fetch the associated workflow file contents from GitHub.
If you know that contents of workflow_ref only specify a single job, then you've mitigated the concern of overscoping without caring about job_workflow_ref.
OSSF scorecards use that technique to make assertions about the workflow that is publishing - https://github.com/ossf/scorecard-webapp/blob/main/app/server/verify_workflow.go

[woodruffw]

Could this just be a boolean + warning?

The main reason we can't do this is because, long term, we want to allow both states to enable hermetic CI configurations: a user should be able to configure pypi.yml as their "top-level" workflow (i.e. the one in workflow_ref), and then a specific pinned reusable workflow.