Add PyPI publish attestations during publish workflow

[shaanmajid]

First Check

• I added a very descriptive title here.
• I used the GitHub search to find a similar question and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

N/A

Description

Hi! I noticed a lot of supply-chain hardening PRs across several FastAPI org projects lately, in wake of the many attacks in the open-source ecosystem lately. On behalf of the Python community, I'd like to thank you for taking the time and effort to make your already wonderful tools more secure :)

While reviewing these, I noticed that the org's Python packages already publish to PyPI using OIDC/Trusted Publishing via GitHub Actions, but most current releases do not yet have PyPI publish attestations. From the docs:

(Digital attestations) bind each release distribution (such as an individual sdist or wheel) to a strong cryptographic digest of its contents, allowing both PyPI and downstream users to verify that a particular package was attested to by a particular identity (such as a GitHub Actions workflow)"

Because these workflows already build with uv build and have Trusted Publishing configured, this looks like it can be enabled with a very small change: replace the final publish command with pypa/gh-action-pypi-publish, which uses the existing Trusted Publishing/OIDC setup and generates PyPI publish attestations by default.

The diff would be roughly:

-        run: uv publish
+        uses: pypa/gh-action-pypi-publish@cef221092ed1bacb1cc03d23a2d87d1d172e277b # v1.14.0

This applies to most of the FastAPI organization Python packages: fastapi, typer, asyncer, fastapi-cli, fastapi-new, sqlmodel, and annotated-doc. (annotated-doc actually had attestations uploaded at its last release, 0.0.4, when it was using the pypa/gh-action-pypi-publish to publish, but has since been transitioned to uv publish; a potential future release would currently revert to not publishing attestations.)

(Alternatively, astral-sh/attest-action would also work here while preserving the existing uv publish step. uv cannot produce attestations itself, but it does upload any already available attestations during uv publish; the action generates attestations in Python for the uv publish step to use. However, it's advertised as early-dev/unstable, so I would recommend using the official PyPA action)

Would you be open to PRs for this across the package repos?

Operating System

Other

Operating System Details

N/A

FastAPI Version

N/A

Pydantic Version

N/A

Python Version

N/A

Additional Context

No response

[abdurrahman310303]

The swap does what you're describing, and it's clean here because the workflow
already builds separately (uv build then uv publish), with id-token: write
set for Trusted Publishing. gh-action-pypi-publish uploads from dist/, so only
the publish step changes and the build step stays as-is. Attestation
generation is on by default in recent versions, so the swap alone gets you PEP
740 attestations with no extra config.

Worth spelling out why this is the route today: uv publish can't generate
attestations yet. It can only upload ones that already exist in dist/ (added
in uv 0.9.12). Generating them in uv is still open (astral-sh/uv#15618
(astral-sh/uv#15618)). So until that lands,
gh-action-pypi-publish is the only way to get attestations produced
automatically from the OIDC token you're already issuing. If uv gains
generation later, the workflow could move back to a pure-uv flow.

Two small things if a PR goes in:

• Keep the uv build step. The action only uploads dist/, it doesn't build.
• Pinning to a commit SHA (as you did) is the right move; just wire up
  Dependabot to bump it since you give up the floating tag.

Low-risk, mostly mechanical, and the Trusted Publishing setup that makes it
work is already in place across the repos.

[shaanmajid]

Hey all, just wanted to check in on this. Do the maintainers have any opinion here? Happy to answer any questions or provide clarification on anything, but if this is not desired I can just go ahead and close :) Thanks!