Hi all,

I'm excited to share that in Bitbucket Server 7.1 we shipped Push log feature that allows admins to see the history of all push events in a repository.

You can find more information in the Bitbucket Server 7.1 release notes and Push log docs.

Please, don't hesitate to leave feedback on the feature in the comments. This will help us to priorities further development.

Also, please note that the use case I mentioned is a perfect example of why push traceability is a separate concern from commit author verification. It may be perfectly valid to merge in a bunch of commits from a forked repository and it's nice to know who authored all those commits. You still want to know who merged in that fork and pushed it, though.

@Bryan - Is there any better documentation on the committer verification hook beyond the brief description in the release notes? We are currently using the Adaptavist ScriptRunner hook for committer verification, which allows us to specify (among many other things) whether or not commits from forked repositories should be allowed. It's unclear to me whether the Atlassian hook would allow someone to merge code from a forked repository and push the results to BitBucket when this hook is in place. If it doesn't allow this, what's the solution? Are people just supposed to disable the hook temporarily whenever this kind of thing needs to happen?

Thanks.

ashok.shivani1335625297,

I'm not a PM, so I can't provide any insight into where this falls on the product's roadmap. However, I can note that Bitbucket Server 5.0 included a new hook which verifies that the committer for each new new commit being pushed matches the credentials of the person doing the push, which means in order for a malicious employee-A to push their spoofed code change they'd need employee-B's credentials. (For those running earlier versions of Bitbucket Server, I'll note that there are third-party add-ons that provide similar verification.) Building on that, starting in Bitbucket Server 5.1, we added the ability to require GPG-signed commits in order to push (see BSERV-2717). When that validation is enabled, each new commit or tag must be GPG-signed with a valid key, and that key must be associated with an active user account on the server. Otherwise the push is rejected. Between those two additional validations, while it's still possible for anyone to commit using anyone else's identity, it's no longer readily possible to push those malicious commits to repositories with these checks enabled.

Note that I am not saying these improvements obviate or remove the need for some level of push traceability from an auditing/compliance perspective. As I said, I'm not a PM and can't comment on the roadmap. But these improvements do help solve the ingestion problem, pending further traceability enhancements. If employee-A can't push their commits, employee-B has a lot less to worry about.

Best regards,
Bryan Turner
Atlassian Bitbucket

Without such push traceability, audit trails can not be conducted on spoofed commits. Ability to have an audit trail is the requirement for some of compliance regimes i.e PCI.

Just a quick illustration of how serious this can get: employee-A commits a malicious code change spoofing as employee-B. Employee-B denies making that code change, however employee-B can not prove that s/he has not committed that code change and most frustrating part for employee-B and Infosec (Information Security group of an enterprise) is that Bitbucket system owners/administrator can't help identify culprit.

I request Product Management of Bitbucket Server/Data-center to update this request if this is going to be addressed and if so what is timeline.

An update from the BBS development team would be helpful to understand where we are with built-in push auditing functionality.

With the support for "Smart Commits" in Jira 7.1.x this security hole has now been extended to Jira. The same technique described above to spoof commits in Bitbucket can (if Smart Commits are enabled) be use to spoof comments and workflow transitions in Jira.

It's actually a bit more dangerous than the situation with Bitbucket commits, where at least you had to be an authorized user of the repo to get the misleading commit email address in there. With Smart Commits you can spoof Jira issues for projects that you don't have any permissions for.

(Note this is about the new Jira/Bitbucket "Smart Commits" feature and not the third party Bitbucket plugin of the same name.)

There is an example implementation of a post-receive hook that records the pusher details for each commit in ScriptRunner for Stash 4.1 - https://jamieechlin.atlassian.net/wiki/display/SR4S/ScriptRunner+for+Stash+4.1

Undoubtedly, I imagine this will be in Stash natively at some point, but if you are not able to upgrade when it is released, you could try this alternative solution. It will also let you have full control over what information on the pusher you record.

> There are plenty of plugins and hooks that will enforce that the committer name is in the user database

Agreed, both of the plugins mentioned previously enforce that some policy (the policies vary between the plugins) applies to the author of each commit. This solution I'm mentioning now is to allow pushing others' commits, but recording that persistently. So forgive the advertising, I hope someone finds it useful.

I too would like some push traceability. I would like to see "These 5 commits was pushed by XXX on YYY" it is useful if you need to revert, Ideally it would also be possible to see which commits a pull request introduced on a branch but not sure if this is in scope for this request