Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Publish to PyPI via Trusted Publishing with PEP 740 attestations; retire PYPI_API_TOKEN

Đang mở
#1,958 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
Loại issue
Tính năng
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github-actions, python, yaml

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:

  1. 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.
  2. 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: write in an environment: pypi job, 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_TOKEN secret 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 / crossbar release.yml job release-production.
  • Remove TWINE_PASSWORD / secrets.PYPI_API_TOKEN from the workflow.
  • Replace every pip install git+https://github.com/pypa/{twine,packaging}.git in the workflows
    (release.yml release-development, release-nightly, release-stable; also wheels workflows)
    with pinned released versions. None of them may remain in the release-stable job.

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-attestations added to the development tools installed by just install-tools.
  • A just verify-pypi [version] recipe that verifies the provenance of every file of a release
    on PyPI against https://github.com/crossbario/autobahn-python.
  • A "Verifying a release" section in docs/installation.rst showing the user-side command.

Maintainer actions (outside the repository)

  • After the first attested release: revoke the token behind PYPI_API_TOKEN on 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>/provenance returns publisher
    crossbario/autobahn-python, workflow release.yml, environment pypi.
  • 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.1 passes; docs/installation.rst documents the check.
  • The publish job follows the fleet hardening (actions pinned by SHA, id-token: write only 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

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của crossbario/autobahn-python

Tất cả issue của crossbario/autobahn-python

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.