-
Suggestion
-
Resolution: Answered
-
None
Currently Smart Commits parses every commit message and executes any actions as the author of that commit. This means a malicious person given access to your codebase can act as another user for Smart Commit actions, and instances that don't have this level of trust in the people writing their code can't use Smart Commits.
This suggestion is to introduce an option that will only execute actions on commits where the author's email address matches the email address of the Bitbucket Server user doing the push.
This means a pusher can't maliciously attribute actions to others, but also means that if a pusher is the first person to push someone else's commits to Bitbucket Server, those commits will never have their actions run.
Workaround
Bitbucket Server 5.0 includes the "Verify committer" repository hook that ensures all new commits are authored by the person pushing them. If you enable this hook, the pusher will not be able to perform actions on behalf of other users by faking commit data.
- is related to
-
- Closed
- relates to
-
- Closed
- mentioned in
-
![[Extranet] Page](/images/icons/generic_link_16.png "[Extranet] Page")
Page
Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[BSERV-8875] Smart Commits - only run actions from commits authored by the pusher
njoneill that seems like a reasonable suggestion.
Just to manage expectations, it's worth noting that given our current implementation, it's not as trivial a change as it sounds (we don't have access to the pusher's identity in the right places).
Thanks for the suggestion!
A user has to authenticate to Bitbucket in order to perform a push, so Bitbucket has a confirmed identity for the user in this case. Could we have a mode in Bitbucket where this confirmed identity is used to provide the email address for commits, and the unconfirmed information coming from the git client is ignored? It seems that this would be a fix for this current issue and BSERV-2717 as well.
This is a known and mostly unavoidable case due to Git's lack of real authentication of commits (unless you enforce signed commits). We'll be updating our docs shortly to mention this problem and give a better forewarning about the implications if you can't trust your committers.
Watch and vote on BSERV-2717 for support for signed commit enforcement, which might be helpful for cases like this.
Cheers,
Adam
Given the currently available workaround, it's unlikely we'd also make changes to only apply smart commits when authored by the same person that's pushing.
Please comment here if there are significant issues arising despite the workaround and we'll reconsider.