My takeaway from all that - the git project is internally taking steps to mitigate vulnerabilities from this particular attack (making it harder to insert the arbitrary binary data necessary into git metadata), but a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizon and they should speed up their hash-replacement efforts.

This latter leads into the problems with Linus' positions in particular. In that thread, does not take seriously the threats that this poses to the broader git userbase, because he only seems to care about the kernel use-case: trusted hosting infrastructure at kernel.org (itself an iffy assumption, given previous hacks and the use of mirrors), and the exclusive storage of human-readable text in the repo which makes binary garbage harder to sneak in. These do not apply to most users of git. His rather extreme public position (paraphrased, "our security doesn't depend on SHA1") is even more troubling - it absolutely does depend on SHA1, this just isn't (yet) a strong enough attack to absolutely screw over the kernel. A stronger collision attack (eg a chosen-prefix as opposed to identical-prefix, or godforbid a pre-image attack) would absolutely invalidate the whole git security model.

> a) is just throwing up their hands at the problem of projects that store binary blobs like image data in their repos, and b) is not taking this as a signal that more serious sha-1 attacks are on the horizon and they should speed up their hash-replacement efforts.

As @tytso points out, there is ongoing work to replace the use of SHA-1. Also, yes, SHAttered raises serious concerns about the safety of SHA-1, but that doesn't mean everyone has to immediately work on the switch (and honestly, it's questionable how much it would help - throwing more developers at a problem doesn't necessarily help). Should Stefan Baller drop the work he's doing on submodules because SHA-1 is more imminent now?

It's also worth noting Linus isn't really a core Git dev any more, he just submits patches occasionally. Junio Hamano is the primary maintainer.

SHA1 is only used for uniqueness. You still need to have write access to repo to perform attack. If you already have write access you do not need to make collision...

Exactly. Why waste the time to fabricate a collision when all you have to do is "accidentally" commit exploitable code? At least then you got plausible deniability.

For this particular attack - what if you do not have write access, but have sufficient social capital to get a pull request merged with a benign-seeming file?

If we're just talking about this particular attack, the two files don't even resolve to the same SHA-1 in Git:

    $ sha1sum shattered*
    38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-1.pdf
    38762cf7f55934b34d179ae6a4c80cadccbb7f0a  shattered-2.pdf

    $ git hash-object shattered*
    ba9aaa145ccd24ef760cf31c74d8f7ca1a2e47b0
    b621eeccd5c7edac9b7dcba35a8d5afd075e24f2

As soon as somebody invests a few $100k there are going to be such files. Now it's known how much it takes. That much.

Luckily, there is also a known solution to detect that kind of files.

That's not all "the git project" is doing. Work to allow git to support an alternate crypto checksums is on-going. One of the key steps is to replace the hard-coded use of char[40] with a "struct object_id" object, and it is about 40% done[1].

[1] http://public-inbox.org/git/20170217214513.giua5ksuiqqs2laj@...

Like many volunteer projects, the work would go faster if more people helped. What "the git project" considers important works the same way as "how much is bitcoin worth", or "how much is gold worth". People who think it's important can show the value by putting their effort where they think it is most important. Or, of course, people can snipe from the side-lines, and make themselves feel all self-important.

There has actually been a lot of thought about how to do a graceful transition period, but to also on how switch from a soft cutover to a hard cutover (breaking backwards compatibility and requiring people to upgrade their clients) to allow time for developers to upgrade at a reasonable rate, where reasonable can be defined on a per-git repository basis. So if you want to force a flag day as soon as the code is available, and not wait for stability testing, etc., those people who value security uber ales, and who don't want to rely on trusting kernel.org, etc., can do so.

I will note, though, that most people are doing blind pulls, or worse, blind merges, from developers outside of their immediate circle of trust _all_ _the_ _time_. Heck, people will cut and paste command lines from web pages of the form "curl http://alfred.e.numman/what/me/worry | bash" into root shells all the time! So if you are not auditing every line of code before a git pull, the fact that git is using SHA-1 is the least of your worries.

Personally, if I were a nation state planning on trying to insert the equivalent of a DUAL-EC backdoor into open source software, I'd do that by spending a person year or ten getting a collection of developers to be trusted contributors to some key open source project, like Docker, or Python, or even yes, the Linux kernel or git, and then "accidentally on purpose" introducing a buffer-overrun or some other zero day into said OSS code base. Or heck, just simply invest in finding more zero days that people have inserted into their code just because they're not careful!

So, sure, "we" should upgrade git to be able to support multiple crypto hash algorithms, and there is work going into doing this. But at the same time, it's important to keep a sense of perspective on all of this --- unless, of course, your goal is to make yourself seem important by exuding a sense of self-righteousness.

> people will cut and paste command lines from web pages [...] into root shells all the time!

Do they? I've never encountered anyone using a root shell to go about their business unless they had to do some exclusive operation that could only be done as root, and even then they would rather just sudo that specific operation. Hell, even if they do do that, they have bigger problems than just git, given that cut and paste is inherently broken[1].

[1]: https://news.ycombinator.com/item?id=10554679

Do you know anyone who uses calibre, the e-book reader? You want to give it a try? Just cut and paste this:

sudo -v && wget -nv -O- https://download.calibre-ebook.com/linux-installer.py | sudo python -c "import sys; main=lambda:sys.stderr.write('Download failed\n'); exec(sys.stdin.read()); main()"

Or you can trust my docker image, where I've done this for you:

https://hub.docker.com/r/tytso/calibre/

(Hint: blindly using my docker image is only slightly better from a security perspective. What you _should_ do is download the dockerfile, audit it carefully, and then create your own docker image. And then you're _still_ trusting the Calibre folks to have access to your X server....)

I actually don't know anyone who uses it. Any Linux users I know would just use the book reader from their distro's repository (in my case, FBReader).

EDIT: Also, holy s@@@ e-calibre, your advice (with a mild warning) if people get certificate errors is to pass in --no-check-certificate.

That docker file downloads Calibre over HTTP. Awesome!

>Do they? I've never encountered anyone using a root shell to go about their business unless they had to do some exclusive operation that could only be done as root, and even then they would rather just sudo that specific operation.

Maybe you should encounter more devs?

I'm a developer, who works alongside other developers, on a floor full of developers. Not only does this apply to my work, but also at hack[spaces|athons] and jams I've been to (With ages ranging from ~8 - >30). I've literally never encountered anyone using su for a command that doesn't need it. Even when they need root, they just use sudo for that command.

Well, you'd be surprised.