Add support for OIDC instead of token

[MicaelJarniac]

PyPI recently did this:

• https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/
• https://docs.pypi.org/trusted-publishers/

So now, for publishing a package on PyPI, the author no longer needs to store a PyPI token in the repo's secrets, nor provide it on the GitHub Actions workflow. All they need is to set permissions.id-token: write and go to PyPI to authorize this repository and action.

permissions:
  id-token: write
steps:
  - uses: pypa/gh-action-pypi-publish@release/v1

My suggestion is to support the same for Codecov, where a user no longer needs to worry about tokens, all they need to do is authorize the repository and action on Codecov, and all the authentication is handled automatically with OIDC. An example workflow could look like this:

permissions:
  id-token: write
steps:
  - uses: actions/checkout@master
  - run: # Calculate coverage here...
  - uses: codecov/codecov-action@v3

[A5rocks]

I investigated this a bit ago cause tokenless was suffering to GitHub ratelimits, but tl;dr you cannot get OIDC perms from forks... which you probably want to accept contributions from?

You can see a larger writeup at the PR description for https://github.com/python-trio/trio/pull/2672 :D

---

Though now that I reread what I wrote and the links I provided, it does seem like you might be able to do something funky with pull_request_target instead of pull_request (though GitHub very strongly discourages running tests under that).

[webknjaz]

That's correct. I was involved in implementing this in my action that you referenced above. Forks are no-go, which is fine because Codecov specifically allows PR uploads from forks to be tokenless. And for the in-repo PRs, there's some OIDC support implemented in the underlying Codecov CLIs, I saw some PRs but haven't checked what state it's in.

However, I do have another concern — OIDC can be an attack surface, which is why in my PyPUG guide (https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/) specifically showcases separate jobs for building the dists and publishing them. Otherwise, the build process can become a target of a privilege escalation attack performed through build dep poisoning. And that's why I insisted that William mentions the dangers in those PyPI docs you linked.

It might not be obvious why, though. You see, OIDC is pretty generic. Intercepting it won't affect just one service (PyPI / Codecov / etc.) but any others too. Imagine, it's compromised, because of some dep in your tests. And the attacker is dormant. Then, over time you configure trust to your same repo in AWS. Now, having access to OIDC, it's also possible to break into AWS, not just upload a malicious coverage report to Codecov.

I suppose, this would have to be paired with the approach outlined @ https://hynek.me/articles/ditch-codecov-python/ where many coverage reports are merged into one in a single job and then, uploaded in one go, in the scoped job.

[thomasrockhu-codecov]

@MicaelJarniac this is now done. If you are using the action, you can specify use_oidc: true as an argument.

[webknjaz]

@thomasrockhu-codecov it'd be nice to add the ability to upload coverage reports from a dedicated CI job to address the security implications of giving the OIDC privilege to test/build jobs running who knows what in their big dependency trees… Is something like that being considered?

[thomasrockhu-codecov]

@webknjaz I'm not exactly sure what you are asking for here, do you mind giving me some more details as to what you are expecting? I would recommend opening a new issue about this as this one is already completed.