Publish to PyPI via Trusted Publishing with PEP 740 attestations; retire PYPI_API_TOKEN
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 52/100
Hướng nghiên cứu
Start by comparing .github/workflows/release.yml with the release-production jobs in the referenced zlmdb and crossbar workflows. Inspect all release and wheels workflows for the listed git-based installs, then review just install-tools, the verify-pypi recipe, and docs/installation.rst. Done means the workflows use pinned releases and SHA-pinned Trusted Publishing with attestations, verification is documented, and the acceptance checks pass.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Problem
autobahn is the only WAMP Python package on PyPI without provenance. Its sibling packages
(txaio, zlmdb, cfxdb, xbr, crossbar) all upload through PyPI Trusted Publishing (OIDC) with
attestations: true, and PyPI serves a signed PEP 740 publish attestation for each of their files:
GET https://pypi.org/integrity/zlmdb/26.7.1/zlmdb-26.7.1.tar.gz/provenance
-> publisher: GitHub crossbario/zlmdb, workflow release.yml, environment pypi
GET https://pypi.org/integrity/autobahn/26.7.1/autobahn-26.7.1-pp311-pypy311_pp73-win_amd64.whl/provenance
-> 404 Not Found
For comparison, cryptography 50.0.1 carries an attestation on every file (in-toto statement,
Sigstore certificate, Rekor log entry, source commit and workflow run).
The Trusted Publisher is already registered on PyPI for autobahn
(crossbario/autobahn-python, release.yml, environment pypi), and the release-stable job
already has id-token: write and environment: pypi. But the upload step does not use either:
# .github/workflows/release.yml, job release-stable, "Publish to PyPI using bleeding-edge twine"
env:
TWINE_USERNAME: __token__
TWINE_PASSWORD: ${{ secrets.PYPI_API_TOKEN }}
run: |
python3 -m pip install --break-system-packages git+https://github.com/pypa/packaging.git
python3 -m pip install --break-system-packages git+https://github.com/pypa/twine.git
twine upload ...
Two consequences:
- No provenance. Files are uploaded with a long-lived token, so PyPI cannot attest who
published them. Attestations cannot be added to files after upload: every release until this is
fixed stays unattested. - Credential exposure. The job installs the current tip of two third-party repositories
(pypa/twine,pypa/packaging) and runs them with the PyPI token in the environment (and with
id-token: writein anenvironment: pypijob, so it could also mint a Trusted Publishing
token). A malicious or compromised commit upstream would be enough to steal the credential or
tamper with the upload. No autobahn project-scoped API token is listed on PyPI, so the
PYPI_API_TOKENsecret is probably a user-scoped (account-wide) token that can upload to
every project of that account.
The git-master installs were a workaround for PEP 639 (Core Metadata 2.4) support; released
versions of twine and packaging support it now (to be confirmed with the pinned versions).
Proposed change
- Replace the twine upload step with
pypa/gh-action-pypi-publish(pinned to a commit SHA), with
attestations: true, exactly as in zlmdb / crossbarrelease.ymljobrelease-production. - Remove
TWINE_PASSWORD/secrets.PYPI_API_TOKENfrom the workflow. - Replace every
pip install git+https://github.com/pypa/{twine,packaging}.gitin the workflows
(release.ymlrelease-development,release-nightly,release-stable; also wheels workflows)
with pinned released versions. None of them may remain in therelease-stablejob.
Note: nothing has to be run to "produce" https://docs.pypi.org/attestations/publish/v1. That URL
is the in-toto predicate type of the attestation that gh-action-pypi-publish creates and uploads
itself when it runs under Trusted Publishing with attestations: true.
Provenance verification, the same in every WAMP Python project (shared script and recipe pattern
from wamp-proto/wamp-cicd, issue "verify-pypi"):
pypi-attestationsadded to the development tools installed byjust install-tools.- A
just verify-pypi [version]recipe that verifies the provenance of every file of a release
on PyPI againsthttps://github.com/crossbario/autobahn-python. - A "Verifying a release" section in
docs/installation.rstshowing the user-side command.
Maintainer actions (outside the repository)
- After the first attested release: revoke the token behind
PYPI_API_TOKENon PyPI
(Account settings, API tokens; check whether it is account-wide) and delete the secret from
the repository (and the organisation, if it is also defined there).
Acceptance
- The next autobahn release (26.9.1) serves a provenance document for every file:
https://pypi.org/integrity/autobahn/<version>/<file>/provenancereturns publisher
crossbario/autobahn-python, workflowrelease.yml, environmentpypi. -
pypi-attestations verify pypi --repository https://github.com/crossbario/autobahn-python pypi:<file>
succeeds for a wheel and the sdist. - The PyPI file page shows "Uploaded using Trusted Publishing? Yes".
-
grep -rn 'PYPI_API_TOKEN\|git+https://github.com/pypa' .github/workflows/finds nothing. -
just verify-pypi 26.9.1passes;docs/installation.rstdocuments the check. - The publish job follows the fleet hardening (actions pinned by SHA,
id-token: writeonly on
that job).
Blocks: the 26.9.1 release (it must be the first attested autobahn release).
Related: wamp-proto/wamp-cicd issues "Harden the PyPI publish jobs fleet-wide" and "verify-pypi";
SLSA build provenance: #1842; .cicd/SLSA.md item 2.
Note: This issue was drafted with AI assistance (Claude Code).
- Ngôn ngữ chính
- Python
- Star
- 2.5k
- Fork
- 769
- Merge trung bình
- 1 ngày 11 giờ
- Pull request đã merge (30 ngày)
- 16
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của crossbario/autobahn-python
-
CI-CD enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
crossbario/autobahn-python#1945 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug CI-CD
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
crossbario/autobahn-python#1932 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
CI-CD enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
crossbario/autobahn-python#1829 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 22/100
crossbario/autobahn-python#1985 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
crossbario/autobahn-python#1963 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của crossbario/autobahn-python
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
noontide-co/mainbranch#1211 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[1.x Bug] run-operation --sql reports success but rolls back writes on transaction-capable adaptersĐang mởtriage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 64/100
dbt-labs/dbt#16784 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug settings ui
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
DewaldOosthuizen/py-tray-command-launcher#162 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
run_all sleeps after the final job despite documenting delays between jobsCó thể đã có người làm @Gambit-Checkmate đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100