#7667 closed task (blessed) (fixed)
core release process: Verify ZIP recreation is intended
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Component: | Version Control | Keywords: | |
Cc: |
Description
Sometimes a core release ZIP is recreated, which can result in the zip hash changing.
We should verify that the releaser intended on overwriting an existing file, to avoid situations where they inadvertently overwrite a released archive.
Note: It is expected that during releases, a file may need to be rebuilt.
As the ZIP creation task is not currently designed to be reproducible, the ZIP hash will change, even if the file contents is the same.
This can cause problems for some 3rd party tools that expect that the sha1 hash never changes post-release: https://github.com/roots/wordpress-no-content/issues/7
It may also be pertinent to ensure that the ZIP is reproducible, if the only difference is timestamps.
Change History (5)
#3
in reply to:
↑ 2
@
8 months ago
Replying to bradshawtm:
It is expected that during releases, a file may need to be rebuilt.
Is there an example as to why this might need to happen (without a maintenance release)? Has this happened previously? Is there a running changelog or somewhere that we can see when a zip is newly released and why?
"During the release process" meant before the final "release time", ie. during the testing of the release before general availability of that release.
Part of our testing process is to have the ZIP created, and then run real-life testing, and then mark it as "released".
This can cause problems for some 3rd party tools that expect that the sha1 hash never changes post-release
Given this is the purpose of the checksum, I think it's a reasonable expectation. If we can't trust a checksum hash of a given release to be stable, we have no way of knowing should the supply chain be compromised.
Supply chain attacks are a completely different thing, and WordPress.org doesn't currently provide signature verification to combat that. File hashes are not infallible, and can be falsified. The checksum provided is intended on being used to verify the ZIP contents, but it needs to be fetched at the same time as the ZIP.
#4
@
2 months ago
- Resolution set to fixed
- Status changed from new to closed
This should be resolved as of the next core releases, which is likely 6.7.2
.
In addition to improvements to the Packaging UI, the ZIP and tar.gz files should be deterministic if built from the same source-files now for future built releases.
The changes have also been applied to the nightlies, to check for regressions.
These changes had already been applied to Plugin & Theme ZIP generation.
#5
@
2 months ago
Syncing a comment from me on https://github.com/roots/wordpress-no-content/issues/7#issuecomment-2526852529 over here:
If the ZIPs were regenerated with the exact same content inside, why is the hash different?
For some history on this; neither ZIP nor TAR are deterministic compression formats. Although they can be forced to be.
- SVN export sets the file timestamps to the last-commit date, but directories are created with the current timestamp.
- ZIPs store modification dates, including of directories (see above).
- ZIPs store additional metadata about the file, which are not needed and could be excluded.
- TARs
gnu
format can change between versions of TAR, although usually doesn't.- TARs include additional Metadata about the files, such as the UserID / GroupID / UserName / GroupName of the creator, and Access+Creation in addition to Modification timestamps.
- TARs when compressed with gzip via
-z
include the Tar ProcessID and current timestamp in the GZIP Checksums.Changes to the packaging UI should reduce any potential accidental rebuilds, and I've applied some changes to the packaging scripts to force the
.zip
and.tar.gz
's to be more expected as above.
Is there an example as to why this might need to happen (without a maintenance release)? Has this happened previously? Is there a running changelog or somewhere that we can see when a zip is newly released and why?
Given this is the purpose of the checksum, I think it's a reasonable expectation. If we can't trust a checksum hash of a given release to be stable, we have no way of knowing should the supply chain be compromised.