build(deps): bump pypa/gh-action-pypi-publish from 1.14.0 to 1.14.2

[dependabot]

Bumps pypa/gh-action-pypi-publish from 1.14.0 to 1.14.2.

Release notes

Sourced from pypa/gh-action-pypi-publish's releases.

v1.14.2

🛠️ Urgh… Another release!? Again? Explain yourself!

Looking at the diff, you'll only witness updates across the dependency tree. That's it! It's not a security fix or anything like that even, no. But you'll want this update.

[!tip] So what most people will find useful is @​takluyver💰's update of Twine to v7 that we use internally (#416). This version will let them upload their sdists and wheels containing core packaging metadata v2.5 to (Test)PyPI.

🧐 Tell me why..

TL;DR non-pure-python projects with C-extensions tend to have dozens (sometimes hundreds) wheels to upload to PyPI per release. They are often quite big and take time to transfer over the network. People started noticing problems and coming up with DIY sharding workarounds like aio-libs/aiohttp#13226 around July 23. On this date, projects with a good amount of bytes to publish would start getting timeouts 5 minutes after the PyPI publishing job begun. The same job that worked just fine before.

I had to start pinging upstream library and ecosystem people, on GitHub and privately, to start making sense of what was happening. Eventually, we collectively concluded that GitHub must've shortened the lifetime of their OIDC identity — it seems to have used to be 10 minutes long (at some point in the past) and is now 5 minutes, apparently. It's not documented clearly, and we have not been able to get any clarity by attempting to contact GitHub through private channels, using personal connections.

Over the course of investigation, @​facutuesca💰 found and fixed a related underlying cache invalidation bug in sigstore/sigstore-python#1838, which he then coordinated propagation through the dependency chain updates in sigstore-python, pypi-attestations, gh-action-pypi-publish and gh-action-sigstore-python.

Mike's also discovered that Sigstore's Rekor slowdown seems to have become the main contributing cause of the last week's incident. He's collected some data to support this claim: https://publishing-five-minute-timeout.tiiny.site.

🫶 New Contributors

• @​davidbrochart made their first contribution in #415
• @​takluyver made their first contribution in #416

🪞 Full Diff: pypa/gh-action-pypi-publish@v1.14.1...v1.14.2

🧔‍♂️ Release Manager: @​webknjaz 🇺🇦

🙏 Special Thanks to @​davidbrochart💰 and @​Dreamsorcerer💰 for turning my attention (in #415 and in private) to the newly surfaced corner case in GitHub's behavior that only affected a narrow category of projects while many others remained blissfully unaware. @​bdraco💰 came up with a DIY sharding workaround for aiohttp that served as a demo for other projects. @​miketheman💰 confirmed the Warehouse-side details. Also, @​jku💰 and @​woodruffw💰 helped work through, review and release the Sigstore ecosystem upstream libs.

💬 Discuss on Bluesky 🦋, on Mastodon 🐘 and [on GitHub][release discussion].

[![GH Sponsors badge]][GH Sponsors URL]

... (truncated)

Commits

• dc37677 Merge pull request #417 from trail-of-forks/ft/bump-deps
• 8b2f234 Bump pypi-attestations and sigstore
• 78b72db Merge pull request #416 from takluyver/twine-v7
• 92f4d2a Update twine to v7
• ba38be9 Merge pull request #408 from adisivaprasad/bump-setup-python-v6
• a6c5088 Bump actions/setup-python from v5.6.0 to v6.2.0
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[semgrep-app-olist]

Semgrep identified an issue in your code:

pypa/[email protected] is a mutable tag, so a moved tag could make this release job run attacker-controlled code with PyPI publish access.

More details about this

Publish package runs pypa/[email protected], which is a tag, not a full 40-character commit SHA. If the v1.14.2 tag is ever moved to different code, this release workflow would automatically run that new code with this job’s id-token: write permission when a GitHub release is published.

A plausible attack looks like this:

1. An attacker compromises the pypa/gh-action-pypi-publish repository or the maintainer account that controls the v1.14.2 tag.
2. They repoint v1.14.2 to a malicious commit that still looks like the real publish action.
3. When someone publishes a release, the deploy job reaches uses: pypa/[email protected] and pulls the attacker’s code instead of the code you previously reviewed.
4. That malicious action runs inside your workflow after Build package and can read the built distribution files, the repository checkout from actions/checkout, and the job’s OIDC token access from permissions: id-token: write.
5. The attacker could then use that access to publish a tampered package to PyPI under your project name, for example a backdoored olist-loafer release that downstream users would install.

Because the reference is mutable, the code executed during release can change without any change in this repository.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: pypa/[email protected]
	uses: pypa/gh-action-pypi-publish@8ade135a41bc03ea155e62e844d188df1ea18608 # v1.14.2

View step-by-step instructions

1. Replace the mutable action tag with a full 40-character commit SHA in the uses line for the publish step.
   Change uses: pypa/[email protected] to uses: pypa/gh-action-pypi-publish@<full-40-character-commit-sha>.

2. Get the SHA from the pypa/gh-action-pypi-publish repository release or tag that you intend to trust, and make sure it is the exact commit behind v1.14.2.
   The final value should look like uses: pypa/gh-action-pypi-publish@8ade135a41bc03ea155e62e844d188df1ea18608.

3. Keep the version in a comment next to the SHA if you want the workflow to stay readable.
   For example, use uses: pypa/gh-action-pypi-publish@<full-40-character-commit-sha> # v1.14.2. Pinning to a commit prevents the action owner from silently moving the tag to different code later.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

_{You can view more details about this finding in the Semgrep AppSec Platform.}