Consider deprecating sops audit and replacing with documentation on using external tools

[ajvb]

At Mozilla, we are currently only using sops audit for a very specific use case where it might make more sense to lean on something like the linux auditing framework to provide monitoring on file access to various sops-encrypted files.

There has been one indication that I'm aware of (#405) that sops users are using the audit functionality, so the other option would be to feature-freeze it and add documentation for using external tools as an addition.

[hwine]

There are many levels of audit. My use case for an audit function is:

As a secret-rotator, I want to know if person X decrypted file Y since <some_date>, so that I can rotate the minimal set of secrets when person X has their unlocked laptop swiped at a coffee shop.

I think it's fair to put the calculation of <some_date> onto the secret-rotator, as that would take local knowledge of the secrets in that file.

[josephcsible]

My $0.02: I'm in favor of deprecating and removing audit because it's basically a snake oil feature. Since sops doesn't need to be setuid or anything like that, there's tons of ways that it can be circumvented (e.g., run a sops binary from before auditing was a feature, making a copy of the latest binary and hex editing it to disable auditing, using ptrace or seccomp to make the openat syscall fail, running sops in a different user and mount namespace where /etc/sops/audit.yaml is a different file, etc.). No sense of security is better than a false sense of security.