> Git uses SHA-1 hashes, which have not been considered cryptographically secure since 2005.
That a vast oversimplification. There are still no publicly-known preimage or second-preimage attacks against SHA-1. Even the collision attack in 2005 was limited insofar that it reduced the search from a brute-force 2^80 to 2^69.
Perhaps you're referring to a length extension attack, but I admit I don't know much about those in the context of Git's use of SHA-1.
In terms of C source files, unless the fist C source file being extended is at least 64 petabytes long, a length extension attack is going to embed null bytes in the C source file. I don't know chapter and verse of any of the C standards or GCC/Clang extensions, but I wouldn't be surprised if even string literals and comments including nulls cause problems for both GCC and Clang.
Anyone care to chime in/experiment with ways to embed nulls in C files such that either GCC or Clang will continue compiling code after hitting a null byte in the middle of a file? (I'm not talking about an escaped null in a character or string literal, but actually a 00 showing up in hexdump -C of the source.)
EDIT: I think it's safe to assume people will notice someone trying to sneak a 64-petabyte C source file into the codebase. With apologies to Sweet Brown, aint nobody got time for [downloading] that.
That a vast oversimplification. There are still no publicly-known preimage or second-preimage attacks against SHA-1. Even the collision attack in 2005 was limited insofar that it reduced the search from a brute-force 2^80 to 2^69.
Perhaps you're referring to a length extension attack, but I admit I don't know much about those in the context of Git's use of SHA-1.