Conversation

When the left-pad debacle happened, I feared that people would conclude “dependencies are bad”. (Instead of the logical conclusion, which is “don’t allow dependencies to be deleted from package registries.”) That prediction turned out to be true. :(

Replying to

Not only deletion but more like immutability, and that is the problem for me of using github as the source of your dependency

kornel@mastodon.social

Replying to

and

In Cargo you can add `rev=hash` to git dependencies (and it's in Cargo.lock even if you don't)

Replying to

and

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.

kornel@mastodon.social

@kornelski

Jul 29, 2019

Replying to

@DanielMicay

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

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.

Replying to

and

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.

6:24 PM · Jul 29, 2019Twitter Web App

Replying to

and

As I mentioned, it's also very bad practice to be exposing so much attack surface before verification rather than after verification. For example, it isn't considered appropriate for a binary package manager to extract files from an archive before verifying yet it's way simpler.

Replying to

and

So if we're talking about security, exposing a massive amount of attack surface from Git doesn't seem like a good move. It's not designed or implemented in a way that's secure. It's a bunch of non-battle-hardened C code not following security best practices + also using sha1.

Show replies

kornel@mastodon.social

@kornelski

Jul 29, 2019

Replying to

@DanielMicay

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.

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.

Show replies