two package hash breaking enhancements #14511
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This enhances Zig to use multihash for the hash field in package manifests, closing #14284.
Additionally, it adds the executable bit and file paths to package hashes, closing #14308.
Unfortunately, due to the Windows equivalent of executable permissions being a bit tricky, there is follow-up work to be done.
What is done in this commit is the hash modifications. At the fetch layer, executable bits inside packages are ignored. In the hash
computation layer, executable bit is implemented for POSIX but not yet for Windows. This means that the hash will not break again in the future for packages that do not have any executable files, but it will break for packages that do.
Or, perhaps, I could make the decision that zig packages will unconditionally erase the executable bit from all files in a package. This would potentially be useful for packages that want to be distributed via mechanisms that do not contain this metadata. It would also be simpler to implement, since it is already implemented, and there is nothing further to be done.
what the new hash field looks like