3 ms·
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 forg
by dharmab 7y ago
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...
- daveFNbuck 7y agoI'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.
- dharmab 7y agoOur 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.
- daveFNbuck 7y agoEither way, it's important to validate the checks on existing code before making them a blocker.
- dharmab 7y agoYes, 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.
- zdragnar 7y agoMaybe 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?
- Spivak 7y agoThe idea is that a string being high entropy is a good signal that it's a password, API key, cert, etc..
- otakucode 7y agoI 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?