Enforce Trusted Commit Authors

Allows you to specify a policy for handling authorship of incoming commits. This function supports three different policies:

• All authors must be Bitbucket users

• All authors must have write access to this repository

• Can only push own commits

Optionally, you can check the following checkboxes:

• Allow commits from forks. This will bypass checking for those commits that have already been pushed to forked repositories of the current one. This allows for a process where you have multiple forks with different access controls, and users need to pull from other forks and push back to "their own" one.

• Commits must match name. This will check the Author name in the pushed commits against the current Bitbucket display name when using Can only push own commits or All authors must be Bitbucket users. Note that by default Bitbucket maps users by email address, so this option is for enforcing the display name matches as well.

This is designed to mitigate against the following real-world issues:

Failure to set up the gitconfig with user and email correctly

This will make it hard to trace commits back to the real user. By default, anyone can commit using git commit -m "some comment" --author "Linus Torvalds <linus@example.com>", and if you have write access to the repository, you can push that.

Commits to the repository from someone who doesn’t have write access

A user who does have write access can take a patch (git format-patch) and apply it (git am), from a user who does not have write access. If you are in a regulated environment you may have to explain how that happened, possibly years after the fact. The same thing can be done with git bundle and various other ways.

Creating malevolent commits on behalf of another user

It’s possible for a disgruntled user to create a "bad" commit with another user as the author and push that.

The first two policies prevent primarily against misconfiguration and inadvertent breaches in policy, but may not prevent someone determined to cause problems.

The third policy is more restrictive but will prevent against even a willful attempt to breach policy. It has a caveat however - although you can still merge other people’s branches and push them, you would not be able to merge from someone else's fork (unless they had already pushed their changes to the Bitbucket repository). You could also not use a shared local repository (which is not a good practice anyway).