Making WordPress.org

Opened 5 weeks ago

Last modified 5 weeks ago

#7667 new task (blessed)

core release process: Verify ZIP recreation is intended

Reported by: dd32's profile dd32 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 (3)

#1 @dd32
5 weeks ago

  • Type changed from enhancement to task (blessed)

#2 follow-up: @bradshawtm
5 weeks ago

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.

#3 in reply to: ↑ 2 @dd32
5 weeks 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.

Note: See TracTickets for help on using tickets.