Define reproducible archive metadata for release and Nightly packaging

Abierto
  • ¿Algo no está bien?
#1,023 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python, rust
Área
build-system, release

Línea de trabajo

Start with the archive writer at tools/ci/package.py:299 and trace the package_targets serialization path for tar.gz and zip output. Review the existing deterministic stage and gzip-clock fixtures, then identify where timestamps, ownership, entry order, and permissions are set; the issue requires agreeing on an epoch and metadata contract with @LunaStev before implementation. Done means repeated runs with identical source, toolchain, and epoch produce byte-identical archives while permissions, extracted-package smoke behavior, and identity/checksum/manifest binding remain correct.

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

Descripción

ci discussion enhancement help wanted

Current problem after the Rust tooling migration

Keep this issue open for design. PR #1071 retired tools/ci/package.py; the current writer is wave_tools::package::archive in tools/src/package.rs. Moving the implementation to Rust did not select a reproducible archive-metadata contract.

The Rust tar.gz branch calls tar::Builder::append_dir_all on the staging tree and retains file metadata such as mtime, UID/GID and permissions. Entry ordering also needs an explicit contract. The gzip header itself currently uses mtime 0; the earlier Python-specific claim about ambient gzip creation time does not describe this Rust writer.

Reproduction on the merged implementation

On November 2, exercised the actual Rust archive function from the tree merged as e40018fcfa1a6ab99acd24f7d729aaee3d59f5f7. A temporary stage contained one unchanged payload file with fixed bytes. Two calls changed only the payload mtime, from 1600000000 to 1700000000; the same archive root name was used in both runs. No production artifact was published.

// With a temporary stage containing fixed payload bytes:
file.set_times(std::fs::FileTimes::new().set_modified(
    std::time::UNIX_EPOCH + std::time::Duration::from_secs(mtime),
))?;
wave_tools::package::archive(&stage, &output, "wave-probe")?;

Observed SHA-256 values:

tar.gz, first:  8a511063599284b7459dcf5a5b9db6832aadc190fd7d74bccc1500f0460ad9fc
tar.gz, second: 3f8221c5027bd60516c1a142cd4d9f624afa987ecaed4a79e73c90a2da1718f5
zip, both:     5e8a3f8b433350ab7394715ce222a6692a52375bee74374c51f1afe42583ae0b

Inspection confirmed the two tar entries retain their distinct input mtimes while both gzip headers have mtime 0. The ZIP outputs stayed identical in this mtime-only probe; this is not evidence of nondeterministic ZIP timestamps. ZIP permission/order policy still belongs in the design, without assuming the old Python behavior survives.

Scope and design discussion

Choose the epoch, timestamps, ownership, entry order and permission-normalization rules for tar.gz and ZIP. Preserve executable permissions, runtime layout, extracted-package behavior and identity/checksum binding to the exact generated bytes. Do not reintroduce the retired Python writer.

Please mention @LunaStev to discuss the design before starting implementation.

Completion criteria

  • Identical source/toolchain/approved epoch produces byte-identical archives in isolated runs.
  • Tests vary ambient file timestamps and ownership/order inputs where supported.
  • Permissions and extracted-package smoke checks remain correct.
  • Checksums, metadata and manifests identify the exact resulting archive bytes.
Lenguaje dominante
Rust
Estrellas
56
Forks
21
Merge medio
23 h 20 min
PR fusionados (30 d)
45

Preparar el entorno

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.

Más de wavefnd/Wave

Todos los issues de wavefnd/Wave

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.