Request: independently verifiable source signing and reproducible-build details for v7.0.0

[manjucode-s]

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:

1. Is there an official non-GitHub location that binds the v7.0.0 tag or commit to a maintainer-controlled signing-key fingerprint?
2. Is a detached signature or signed release statement available for the tag, commit, or source archive?
3. What is the canonical SHA-256 digest of the source archive used to build the published v7.0.0 artifacts?
4. What exact build-tool and dependency versions were used for the release?
5. 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?
6. 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.

[jku]

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_release

I'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.

What exact build-tool and dependency versions were used for the release?

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)