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. KSP-CKAN/CKAN#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).The infra uses
download_hash.sha1
in two places:(The client also does this and will need to be updated in a subsequent pull request)
Changes
download_hash.sha1
is absent, we usedownload_hash.sha256
for the 8-character archive.org file prefix instead. This will not cause collisions because the file prefix comes after the identifier+version bucket string, so the exact same mod version would have to have an SHA1 and SHA256 starting with the same 8 characters. And even if that happened, it's perfectly fine for both to point to the same file!download_hash.sha1
is absent, the Mirrorer calculates the SHA1 from the downloaded/cached file to check whether it matches one already on archive.orgThis will move us another step closer to the point of being able to drop SHA1 from the metadata completely.