theupdateframework / theupdateframework/python-tuf

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

Open
#2,979 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
1.7k
Forks
304
Avg merge
1d 2h
Merged PRs (30d)
17

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:

  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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the v7.0.0 annotated tag, peeled commit, source archive, wheel, and source distribution named in the issue. Check the project's release and packaging process for maintainer signatures, key bindings, hashes, build-tool and dependency versions, and provenance records. Done means documenting or publishing authoritative answers for the six requested provenance and reproducibility questions.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, github, python
Domain
build-system, documentation, release, security
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.