The current design doesn't require verification from GPG for commits or merge commit done from the web interface.

Use Case Scenario

Let us describe how we want to use git:

All developers should sign their commits. This is enforced by having the Bitbucket server reject pushes that are not signed. The local git config at the developer's machine is set up to always sign. All good so far.

Signing is however not as useful if the signatures are not verified by the developers pulling from the server.

Therefore, the developers have set up their local git config to verify signatures (for instance by git config --global merge.verifySignatures true). Any commits made by someone not trusted on their local GPG chain are rejected.

The problem is that if Bitbucket merges a pull request and does not sign the resulting commit, the developers will have to ignore the signing.

Since it is annoying to get an error each time one merges the master branch from the server, it is easy to just turn off local verification.

A better option is if the commits are signed with a server key instead.

This means one can use a sane default (verify signatures) locally and not having to be annoyed at each merge.