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 har

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@genre.crustytoothpaste.net/ 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 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.