[crypt1d]

Thats why password managers that do support audit logs (normally) do not provide this kind of mechanism of manually decrypting the file. The only way of accessing passwords would be through whatever interface they came up with.

[jbg_]

The password manager of course does not "provide" such a mechanism (I imagine providing a "bypass audit logs" button would not be a popular feature). But if you know the key (the master password, or some derivative of it) and you have the ciphertext then you will be able to get the plaintext.

The only way this kind of auditing could be trusted is if all the secrets are stored on the server that implements the auditing, which is exactly the model I believe that most users of `pass` are trying to avoid.

[crypt1d]

The whole point of the discussion was to highlight a feature that I was missing here - ability to audit who accessed what.

There will always be a person with admin (or master password) access who can edit logs or bypass them entirely, but this is suppose to be a person who has the final responsibility in the team's 'chain of command'. The audit log exists so that this very admin can monitor the logs for suspicious behavior and clean up the passwords after a team member leaves. Hence, having the ability to decrypt the db with a master password is irrelevant as the master password should only be accessible to the admin.