Define reproducible archive metadata for release and Nightly packaging

Đang mở
  • Có gì không ổn?
#1,023 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
38/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python, rust
Lĩnh vực
build-system, release

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
Rust
Star
56
Fork
21
Merge trung bình
23 giờ 20 phút
Pull request đã merge (30 ngày)
45

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của wavefnd/Wave

Tất cả issue của wavefnd/Wave

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.