Add *hashed* file version to .gitallowed? So future changes get caught containing secrets again

[vergenzt]

Would you be open to adding / accepting a PR for some way to record git-secrets exceptions to a repo (a la .gitallowed), except rather than just matching by filename and line contents, it can be whitelisted by hash? (i.e. the output of git hash-object)

We find ourselves wanting to remove some exceptions that have been made in the past to some IPython notebooks (which are ultimately JSON blobs with newlines). These contain lines that match some custom secrets regexes we've defined (9-digit numbers which could be SSNs 🙂), but we know they're not actually SSNs.

Up to this point we've just listed these files by name in .gitallowed per https://github.com/awslabs/git-secrets#ignoring-false-positives, but we've developed an interest in reducing the risk that somebody will modify those files and accidentally introduce secrets later on (which will not be flagged as containing secret data because it's whitelisted by filename, so they might not think to double check). We'd prefer that somebody have to manually re-whitelist a file that's flagged as potentially containing a secret any time they're committing changes to it.

Any thoughts?

---

I don't see a way to do this backwards compatibly within the .gitallowed file itself, so the first approach that comes to mind is checking for another file called .gitallowed-hashes or something like that... and if a tree or blob SHA appears on a line in that file then it gets ignored by git-secrets. We could then (maybe) add a command to git-secrets to add a directory/blob to the list based on its current contents, with the path to the directory/blob listed after the hash in a comment string.

So e.g. what I envision:

$ git secrets --add "[0-9]{9}"

$ echo 123456789 > my-scary-file

$ git secrets --scan
# comes up with error

$ echo "$(git hash-object my-scary-file) # my-scary-file" >> .gitallowed-hashes

$ git secrets --scan
# comes up clean

$ echo "new evil secret for real this time 089291203" >> my-scary-file

$ git secrets --scan
# comes up with error

[peterklein2024]

It sounds like a reasonable enhancement to git-secrets to provide a more granular and secure way of handling exceptions using hash-based whitelisting. This could be particularly useful in situations like yours where the content of the files may change, but you want to ensure that the specific versions you've approved are the ones being tracked.

Before proceeding with a pull request (PR), I would recommend discussing the idea with the maintainers of the git-secrets project. They may have valuable insights and feedback on the proposed feature, and it's always a good practice to get their buy-in before investing time in the development.

You can open an issue on the git-secrets repository to initiate a discussion about this potential enhancement. Clearly outline the problem you're trying to solve, propose the solution with hash-based whitelisting, and explain how it could benefit the community. If the maintainers are receptive to the idea, they may guide you on the best way to implement it or even invite you to submit a PR.

Remember to check the project's contribution guidelines and coding standards before submitting a PR, and make sure to test your changes thoroughly to ensure they integrate well with the existing functionality.