Use SHA256 for archive.org fallback if SHA1 absent #4216
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.
Motivation
Currently we always calculate both the SHA1 and the SHA256 for all mods. This is redundant and wastes CPU time.
#4135 began the process of making the SHA1 optional; the client now ignores
download_hash.sha1
for purposes of validating downloads ifdownload_hash.sha256
is set (which is always). However, it still uses the SHA1 in the archive.org fallback URLs.Changes
Now if
download_hash.sha1
is not set, then the client usesdownload_hash.sha256
for archive.org fallback URLs instead, as in KSP-CKAN/NetKAN-Infra#344.This should be the last piece required to make it possible to drop SHA1 from the metadata completely, but note that it will still be calculated for any module with
spec_version
less thanv1.35
. We will need to make additional changes later for Netkan to actually stop generating it, and that should wait until most users have updated to clients that can handle it.