Reminds me of the time our security team tried to add a hook preventing any high-entropy strings from being pushed to git. It lasted half a day, since they forgot about public keys, UUIDs, hex codes...
I've added a few hooks to try to improve code quality over the years. I can't imagine doing that without first running it over the whole repo to make sure it wasn't flagging good code and cleaning up any legitimate bad code that was caught.
Our code quality checks run as a CI make target instead of a hook. We then have our repo set up to disallow direct push- everything has to go through a PR and therefore CI.
Either way, it's important to validate the checks on existing code before making them a blocker.
Yes, which is why I like the make target method. You can make the target apply to new files exclusively at first, then incrementally add old files as they are touched in the course of normal work.
I could see that working if it wasn't done naively. Prompting for confirmation and then whitelisting that high-entropy string if it is deemed safe would probably only be annoying very occasionally and catch slipups. Did they ever revisit it with a more nuanced strategy?
Maybe it's because it's late and I'm tired, but I'm really struggling to come up with a plausible security reason to prevent high-entropy strings from going into version control. Do you recall what the rationale was?
The idea is that a string being high entropy is a good signal that it's a password, API key, cert, etc..