
Ask HN: How will Git get around the discovery of SHA-1 collissions? - verandaguy
With the recent (practical) discovery of SHA-1 collisions, Git is particularly affected, as this hash is part of its core functionality.<p>Practically, how can a VCS as widely-deployed as Git get around this kind of issue?
======
wahern
It won't. Linus shot down that idea in 2006, long after the basic concept for
this attack was originally published. According to Linus, people shouldn't
depend on Git's hashing algorithm for cryptographic authenticity. If they want
authenticity they should sign commits with GnuPG and, presumably, rebuild the
tree occasionally from the authenticated commits to expose any malicious
modifications.

kerneltrap.org is unresponsive at the moment but I believe the relevant e-mail
threads are here:

    
    
      http://kerneltrap.org/mailarchive/git/2006/8/27/211001
      http://kerneltrap.org/mailarchive/git/2006/8/28/211065

------
brudgers
My engineering intuition is that from a practical standpoint, this isn't an
issue for Git. It's much more likely that the network will go down or all the
copies of the repository become deleted or a developer will use Git tooling
maliciously than for an unintended collision to occur.

Could a malicious actor construct a collision and use it to subvert some code
base? Sure. And it has probably already happened. Crytography is considered a
munition in the US and there are US government agencies which have been
devoted to cryptography continuously since the Second World War and there are
similar agencies in other countries and every last one of them employs many
highly motivated highly educated and highly skilled cryptographic experts and
the latest money is not an object compute hardware to find exactly this type
of vulnerability, create capabilities based on that discovery, and to deploy
them into the wild for national and political and economic interests.

To put it a different way, by the time something like this hits Hacker News,
the odds are that organizations with the capability and funding to do things
like _inventing_ computers have already figured it out. Just as there is a
discontinuity between what Google and SpaceX can do that looks like the future
and the average engineer with a laptop or a garage can do that looks like the
future, there is a similar gap between the future that Space X and Google can
build and what a government institution can build. Space X hauls payloads to
an existing station in LEO and Google runs on an internet that existed before
it did.

The horses are long gone before anyone realizes the barn door is open.

------
anilgulecha
It will not be an issue for existing commits, at least not yet.

Practically possible are collision attacks, which means someone with google-
level hardware can craft 2 commits (one malicious) and keep the later for
later.

Technically, the fix is for git to move to SHA256 or higher, and I'm sure
there'll be discussions around this shortly in the git community.

------
gus_massa
The main idea behind the collision is that you can put a lot of garbage inside
a pdf in a zone that the pdf reader will ignore. This is very common for most
file formats, like jpg, doc, ... so the same idea applies to most of them.

But it will be very difficult to disguise that in a PR. If you send a PR that
says

\- printf("Helo");

\+ printf("Hello");

\+ //
UIHIUEDN7heuiheuih7h00eduhuihoiu[...]hiouHIGo77OUIHIUHJ&g6(&(HHHIUHIIOJIOJK8jjoijoijdnYIHIHI

the maintainer will be very suspicious. (And if you do this in a business,
they will fire you.)

~~~
wapz
Can you explain how git uses the sha-1 hash? If the maintainer still has to
merge PRs I don't see how it's affected.

