Deprecating SHA1

[kestewart]

This is likely a condition for projects going for CII badging so good thing to do, given public compromises noted. Other notes from earlier discussion on google doc

• PVC to use something
• Uday interested in putting this proposal, Brad, Yev +1
• SPDX 3.0 - is going to be needed. General ok from all on call.

[goneall]

Since we are using sha1 as a verification and not as a security authentication mechanism, it may not be considered a security issue. That being said, it would be good to strengthen the verification algorithm. This is somewhat analogous to the debate on using sha1 in git (see https://news.ycombinator.com/item?id=13719368 as a reference).

[ghost]

@goneall you're right. SHA1 is never a security mechanism but a cryptographic algorithm for integrity-check. Idea is to avoid SHA-1 collision i.e. no two fields should have same hash from the algorithm used.

[wking]

On Tue, Aug 01, 2017 at 10:16:04AM -0700, Sai Uday Shankar Korlimarla wrote: Idea is to avoid SHA-1 collision i.e. no two fields should have same hash from the algorithm used.

I think the risk of *accidental* SHA-1 collisions is negligable. @goneall's point [1] is that SHA-1 (and even MD5) is fine as long as you aren't worried about a malicious man in the middle (MITM). So these less-secure hashes still satisfy current intents like [2]: Here, by providing a unique identifier of each file, confusion over which version/modification of a specific file should be eliminated. What they don't cover as robustly is [3]: This identifier enables a recipient to determine if any file in the original package (that the analysis was done on) has been changed and permits inclusion of an SPDX file as part of a package. when there could have been a MITM of package delivery. But is that really a use-case we need to cover? It seems that consumers would be interested in MITM protection in general, not just in the “does this SPDX file apply” context. I'm certainly more worried about MITM viruses than about “haha! That's not actually GPL-3.0+!”. I'm fine punting MITM protection to higher layers (e.g. my package manager), and letting folks use MD5 and/or SHA-1 if they like here. Folks who do want to handle MITM protection from SPDX can always use SHA-256 or other algorithm (although they'd still need a MITM-proof way to distribute the SPDX file itself, and the package-verification-code algorithm [3] is vulnerable to decompression bombs [4] if you get the package as a zip/tar/… from a MITM attacker). [1]: #11 (comment) [2]: https://github.com/spdx/spdx-spec/blob/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/4-file-information.md#4.4 [3]: https://github.com/spdx/spdx-spec/blob/cfa1b9d08903befdf03e669da6472707b7b60cb9/chapters/3-package-information.md#3.9 [4]: https://en.wikipedia.org/wiki/Zip_bomb

[goneall]

This is now optional and the user can specify a stronger file hash.

I don't think this issue is applicable to SPDX 3.0.

Closing the issue.

@kestewart if you disagree, feel free to reopen