Support for pre receive hooks
Problem Statement Talisman is acting as a commit hook and it blocks the commits with secrets. Sometimes, we work with other vendors as well, where we cannot enforce them to install talisman and also when people using newer machines they may forget to install. These can be solved with adding more onboarding process.
Solution We can utilise the pre receive hook feature of Source Control tools and block the commits at the server side if it contains secrets.
Alternatives Other alternatives were adding more manual onboarding process. People tent to miss it.
Reference https://docs.github.com/en/[email protected]/admin/policies/enforcing-policy-with-pre-receive-hooks/creating-a-pre-receive-hook-script https://confluence.atlassian.com/bitbucketserver/using-repository-hooks-776639836.html https://confluence.atlassian.com/bitbucketserverkb/how-to-create-a-simple-hook-in-bitbucket-server-779171711.html
@svishwanath-tw @harinee
@rmkanda : This is a great idea IMO. In fact I would prefer this over the scanner mode of talisman. The biggest problem i see with this is that the talisman pre-receive hook script can become an attack vector on the SCM. IMO this is probably why none of the public git hosting services allow setting up a pre-receive hook.