4 ms·
> The use of SHA-1 in Git is not for security purposes, it's for accidental data corruption and uniqueness purposes In Git itself maybe, but many tools and dev
by n2d4 4y ago
> The use of SHA-1 in Git is not for security purposes, it's for accidental data corruption and uniqueness purposes
In Git itself maybe, but many tools and developers rely on or automatically assume that commit hashes are collision resistant. For example from the GitHub Actions docs:
> Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions https://docs.github.com/en/actions/security-guides/security-...
- mlindner 4y agoThis would be a security vulnerability at GitHub, not one of Git.
- n2d4 4y agoGit is a tool and a tool should be useful. This tool would be much more useful, and also more intuitive to use, if it actually provided cryptographic hashes of its commits and didn't just pretend to. You can shift some of the blame to the user if something goes terribly wrong, but at least partly it's also the tool's fault. Git's security is a footgun that is hardly productive. Believe me, if Git were fundamentally broken, the issue would've been fixed already. It's in that "uncanny valley" of security issues, where it's bad enough to cause damage, but not bad enough to get people to stop what they're doing and fix it.
- rob74 4y agoWell, as the article says, Git already fixed the issue, SHA-256 is already supported. Now it's up to GitHub, GitLab and the innumerable other platform/tool providers to update their solutions, until then Git can't in good conscience make SHA-256 the default, because that would condemn a repository to a life in eternal isolation...
- n2d4 4y agoPer the article, the biggest problem isn't third party integration but that there is no interop with old repos. The feature is in an experimental state right now (and labeled as such), so you can't and shouldn't expect GitHub/GitLab/anyone to start using it in production
- tinus_hn 4y agoIndeed if you specify all users are trusted there are no security vulnerabilities. Unfortunately in the real world not all users are trustworthy.
- zephyr9 4y ago> many tools and developers rely on or automatically assume that commit hashes are collision resistant. Solution seems to be don't. Use the tool as the tool was intended.
- still_grokking 4y agoThis assumes that people actually know what they're doing when writing code. But this assumption was proven wrong infinite many times already. Shouting RTFM didn't help, even after decades of doing so. Actually it's getting worse. Copy'n'paste form Stackoverflow without understanding anything was likely only a warmup. Now we're going to get AI generated code.
- Dylan16807 4y ago> Use the tool as the tool was intended. Make tools better and safer when there are good opportunities.
- roenxi 4y agoThat is a good plan on first consideration, but on close inspection appears to require that the tool author was omniscient and anticipated every possible use of their tool. Traditionally a lot of the usefulness from tools comes from people doing things that were not intended. The modern web springs to mind, it was a terrible hack in the grand old IE days. It is better for tools to have obvious failure modes.