theupdateframework / theupdateframework/python-tuf

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

Abierto
#2,979 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
Python
Estrellas
1.7k
Forks
304
Merge medio
1 d 2 h
PR fusionados (30 d)
17

Descripción

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.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Empieza revisando el annotated tag v7.0.0, el peeled commit, el source archive, la wheel y la source distribution indicados en la issue. Comprueba el proceso de release y packaging del proyecto en busca de firmas de maintainers, vinculaciones de claves, hashes, versiones de las herramientas de build y de las dependencias, y registros de provenance. Se considera terminado cuando se hayan documentado o publicado respuestas autorizadas a las seis preguntas solicitadas sobre provenance y reproducibilidad.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
git, github, python
Área
build-system, documentation, release, security
Tipo de issue
Documentación
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Tranquilo
Claridad
Bastante claro
Aptitud para principiantes
42/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.