Not only deletion but more like immutability, and that is the problem for me of using github as the source of your dependency
Conversation
In Cargo you can add `rev=hash` to git dependencies (and it's in Cargo.lock even if you don't)
2
2
It's worth keeping in mind that Git hashes and signed commits / tags entirely depend on sha1 though. It's increasingly a bad idea to depend on any of it for security. Unfortunately, Git doesn't offer a solution and sources really need to be distributed in signed archive files.
2
2
Replying to
There's no pre-image attack against SHA-1, not even close, not even theoretically close. Collisions are much more limited, and it's easy to detect files trying to use the only known weakness: github.blog/2017-03-20-sha
1
Replying to
That's why I said it's an increasingly bad idea to depend on it. It doesn't make sense to be building infrastructure today that depends on sha1 and has no real migration plan away from it. Creating a dependency on Git revisions or signed commits / tags today isn't a good plan.
1
Something being known also doesn't imply that it's public. The reasoning that you're using is flawed. Publicly disclosed vulnerabilities or attacks aren't the full picture. It's known to have serious weaknesses and an accelerating pace of the disclosed attacks being improved.
2
Replying to
This is irrational. If you assume everything is secretly crackable, then whatever alternative you propose — also is.
In reality, public progress gives a ballpark idea of what is approaching possibility, and pre-image attacks are barely scratching MD4.
1
Replying to
It's not irrational. It's how cryptography and security are approached in general. Public progress does give a good idea of what's becoming practical for attackers with far more motivation and resources, which is why sha1 isn't considered secure and is considered a vulnerability.
2
Replying to
The whole crypto fetish is useless when the practical attack scenario is someone putting malware straight into the source, and releasing it, because everyone just downloads the code (very well signed!) without reviewing it.
1
Replying to
I would not call avoiding depending on everyone having a strong password to be a crypto fetish. Taking an irresponsible and negligent approach is your prerogative and demonstrates the problem with trusting a bunch of developers, many of them treating security as an annoyance.
1
1
3
Security nihilists don't have a place in design discussions around security. Go do your trolling somewhere else and leave the discussions to people that are actually trying to make things better rather than excusing one thing based on another and claiming everything is hopeless.
The biggest blocker to improving software supply chain security are security nihilists fighting against making improvements including excusing insecurity and negligence based on separate kinds of issues. Software security as a whole is garbage precisely because of this attitude.
1
2
1
The status quo is bad. There are too many dependencies, too many people trusted, barely any proper code review at any level, lack of secure software distribution, lack of reproducible builds and build transparency, etc. It shouldn't be so easy to compromise a software ecosystem.
2
1
2
Show replies
Replying to
You're going on about SHA-1, then GPG, and now passwords? BTW, Cargo registries don't use any of these.
You've presented an attack scenario that requires the victim to pin and trust a hash of code they haven't reviewed. In such self-own case there's no need to break any crypto.
1
Replying to
I'm more than familiar with Cargo. Your misrepresentation of what I've been talking about and the security issues involved isn't accurate. Refer back to what I've already said. It's clearly not how you are portraying it and your strawman argument doesn't fit what I said at all.