Thread

1. 0x00cl · 1790906728 · focus · HN ↗

   I think this change is more to do with politics rather than "security". Those kind of things where companies or gov, need to be certified with those super secure certificates and can't be using software that uses SHA-1. I don't have proof, but I'm not doubting it either.

   This is what I saw in one of the mails. > > There are organizations where SHA-1 is blanket banned across the board - regardless of its use

   And also on git 3.0 breaking changes. > > SHA-1 ... recommended against in FIPS 140-2 and similar certifications

   Since SHA-1 isn't used for security in git, they should've instead moved to a non-cryptographic hash function such as MurmurHash3 and avoid all these problems, instead of moving to SHA-256 until SHA-256 is broken and need to move to the next cryptographic hash that is now incompatible with previous versions of git repositories.

   1. hedora · 1790910208 · focus · HN ↗

      SHA-1 is used for security in git. It's the thing that guarantees a commit SHA is unique. Without that, you open up all sorts of downstream infrastructure to supply chain attacks, where old objects get replaced with malicious ones, and then replicated on each subsequent git pull.

      Linus' old argument was that the substitution would probably be noticed eventually, but that's specific to the way Linux uses git, and what he said probably isn't true in practice -- even if it is, there have been enough supply chain attacks since then to prove that even temporarily serving the wrong stuff to developers or CI is enough to allow lateral movement into other packages, production machines, etc, etc..

      LWN had a good write up on this a while back: <a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;715716&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;715716&#x2F;

      1. 0x00cl · 1790940857 · focus · HN ↗

         &gt; At that time, Torvalds responded that SHA-1 is not the real security mechanism used in Git and, as a result, even a full compromise of the hash function would not necessarily be a problem.

         It seems that the usage of SHA-1 is interpreted as a security mechanism while Linus used it mainly for other reasons, such as look up speed and deduplication of objects.

         You can read the original README file when Linus created git[1]:

         &gt;+TRUST: The notion of &quot;trust&quot; is really outside the scope of &quot;git&quot;, but

         &gt;+it&#x27;s worth noting a few things. First off, since everything is hashed

         &gt;+with SHA1, you _can_ trust that an object is intact and has not been

         &gt;+messed with by external sources. So the name of an object uniquely

         &gt;+identifies a known state - just not a state that you may want to trust.

         &gt; ...

         &gt; +Another way of saying the same thing: &quot;git&quot; itself only handles content

         &gt; +integrity, the trust has to come from outside.

         Yes if SHA-1 is broken, then content integrity can be broken but to me it looks like Linus at the time looked it from the point of view of corruption of files instead of &quot;malicious&quot; files.

         [1]: <a href="https:&#x2F;&#x2F;git.kernel.org&#x2F;pub&#x2F;scm&#x2F;git&#x2F;git.git&#x2F;diff&#x2F;README?id=e83c5163316f89bfbde7d9ab23ca2e25604af290" rel="nofollow">https:&#x2F;&#x2F;git.kernel.org&#x2F;pub&#x2F;scm&#x2F;git&#x2F;git.git&#x2F;diff&#x2F;README?id=e8...

Unofficial Hacker News client; not affiliated with Y Combinator.