[Mountain_Skies]

During a code review we found recently written Go code using SHA1, which has been functionally obsolete since 2005. It's a bit baffling why Google even included it in Go or at the very least didn't make it throw up a bunch of warnings to only use it for very special edge cases related to backward compatibility.

The developer didn't know what algorithm to pick so he just went with one at random, assuming it was ok since it was in the library. How many other security vulnerabilities are out there due to similar circumstances? It's a bit troubling.

[userbinator]

Git still uses SHA1, as does a bunch of other not-really-security-critical things (mostly as a much stronger checksum against corruption rather than malice.)

If the purpose of the hash in that code was security-critical and compromised by malicious collisions, it would definitely be a problem. Otherwise it shouldn't be --- and jumping at things without understanding the nuance is precisely one of the problems with the "security industry" today.

[dcow]

Exactly. At a former employer, we had the VA once symbol dump a library we were using and try to knock us since it included a symbol for a sha1 function. The hash was used for a non-security-critical component of web-sockets as a simple collision resistant session identifier. Good luck explaining this to the same people that tried to knock us for using a function that is deprecated in the windows libc implementation for not length-checking its parameters but has always worked correctly on Linux and macOS, citing the windows developer portal as documentation for why our mobile Android and iOS apps were cause for worry.