core release process: Verify ZIP recreation is intended

[dd32]

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.

[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?

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.

[dd32]

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.