Repository navigation
Request: independently verifiable source signing and reproducible-build details for v7.0.0 #2979
Description
Hello maintainers,
I am reviewing python-tuf v7.0.0 for use in a security-sensitive, offline-verification workflow.
I could verify the following GitHub objects:
- Annotated tag object:
fed65f73486314242cc738fc7c5c891f5d7fc369 - Peeled commit:
353bdb767db56fd4667c9bcf56b710d50fdc2ac0
GitHub shows the tag as verified through GitHub's web-flow signing key. However, I have not found an independently published maintainer signature or key binding that can authenticate these source objects without initially trusting GitHub as the identity authority.
Could you please clarify:
- Is there an official non-GitHub location that binds the v7.0.0 tag or commit to a maintainer-controlled signing-key fingerprint?
- Is a detached signature or signed release statement available for the tag, commit, or source archive?
- What is the canonical SHA-256 digest of the source archive used to build the published v7.0.0 artifacts?
- What exact build-tool and dependency versions were used for the release?
- Are the wheel and source distribution intended to be byte-for-byte reproducible from the tagged source? If not, which content-level comparison is considered authoritative?
- Are there plans to publish provenance or attestations that bind the source commit to the PyPI artifacts?
This is a supply-chain provenance question, not a vulnerability report. No private repository information or credentials are involved.
Thank you.
Activity
jku commentedon Aug 7, 2026
python-tuf releases happen with the ecosystem best practice: PyPI Trusted Publishing. This produces attestations -- see the docs for how to verify the source repository, commit and build workflow that was used for the release with https://github.com/pypi/pypi-attestations.
We expect the releases to be byte-for-byte reproducible, there is a script in the sources to verify that this is true for pypi & github releases:
git checkout v7.0.0 && ./verify_releaseI'm personally a bit hesitant to add any release signing processes to this project that are not standard for the Python ecosystem, but I'm open to proposals.
Please checkout the relevant git commit and see for yourself: every depency, including build deps, are pinned (although true hash pinning is still waiting for a transition to uv.lock from a bunch of requirements.txt files)