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.

@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

Please consider that this request is originally for push traceability and not commit traceability.

There are plenty of plugins and hooks that will enforce that the committer name is in the user database.
Putting up ads for them and/or arguing about Git behavior is not the problem that needs to be solved.

The problem that needs to be addressed is that there is no obvious logging or audit trail for pushes, as in other enterprise-level Git management tools:

Git Enterprise does it (https://help.github.com/enterprise/2.1/admin/articles/viewing-push-logs/).
TeamForge has full audit logs.
GerritForge (formerly gitinabox) can do it.

The request is for Stash to do it too.

Commit Policy Plugin helps you to improve the quality of your commits both with Stash and with raw Git (without Stash), using the following checks:

1. Committer must have a valid JIRA account condition: you can enforce your committers to have a valid JIRA account and to be a member in a JIRA group. If your user accounts are shared between Stash and JIRA, then this is the simplest solution.
2. Committer attribute must match a pattern condition: you can check usernames and email addresses against regular expression. This helps to ensure that your developers filled those configuration settings, they don't use their private email addresses, etc.

Merging some else's work would normally violate these. If necessary you can opt out from the commit rules using the bypass pattern.

Please note that there are rules to check the format and content of the commit messages, to verify the changed files, etc.

(We are considering to support signed commits, please vote!)

We recently released a new plugin that handles verifying commits that are pushed - ScriptRunner for Stash.

The docs for this specific feature are here: https://scriptrunner.adaptavist.com/stash/latest/docs/pre_receive_hooks/#enforce-trusted-commit-authors

It has different settings for your security/paranoia requirements. However, even the choice that allows only users to push their own commits will still allow local merges, providing the branch to be merged hasn't been received directly from another user's clone, but from the stash-hosted repo instead.

It doesn't provide push traceability per se, but it is a good safeguard against things like misconfigured git config files, and users inadvertently pushing changes from people with no access. The "only push own commits" may be a bit extreme but without signed commits, gives you a good guarantee you're only accepting changes from users with the right permissions.

One need not explicitly say a word to mean it. Besides, this whole thread feels like its full of Perforce users. I think everyone is trying to solve the wrong problem. Instead of relying on commits to authenticate commits by a person, use HTTP / SSH and enforce your access security outside of GIT functionality.

It's certainly reasonable to expect Stash to create an audit trail for authentication requests. The user that authenticated for access to push to a repository would be logged (not the commit author). It's perfectly reasonable to commit patches from unauthorized users (maybe someone from another team provided a patch). Too many red herrings when you try to look at commit authors. I also used that plugin but only to enforce that the author/email fields contain values (maybe someone had a bad config file). It wasn't to authenticate things.

Commit signing isn't a big pain like you seem to make it out to be. It's very simple & a perfectly valid and reasonable solution to the problem. Can someone under such strict policy afford to be lazy? If you want to solve a problem, and especially if that problem involves policy, you have to be willing to accept a few extra steps. Security always sacrifices convenience.

Who said force? Make it an option as was provided by Enforce Author before it broke recently. Lots of people want this as a feature, and not everyone wants to endure commit signing.

What if someone commits a patch by someone else? That will have an author/email possibly not in the user directory. You're all using Git, you need to accept Git's behavior. This isn't something Atlassian can or should change. Please stop forcing Perforce behavior on Git. Even big enterprises can adjust to Git's philosophies.

If traceability is important then implement policies around commit signing. This is what many open source projects do.

Ishan,

It's not broken; it's working as intended. The date and user information provided by the system is the author, for all commits, all the time. That is unlikely to change.

Best regards,
Bryan Turner
Atlassian Stash

Currently the commit dates that stash shows up are the author date i.e. when author committed that changed and not the committer date. We are on STASH 2.7.

Scenario:

I have branch A and has 4 changes. I have branch B which was branched from A after first two changes.. If commits in B were made before commits 3 and 4 in A, then after rebase and merge into branch A, the dates in branch A would show up as author dates and not commiter dates.. Is this fixed ???

Daniel, you should be able to authenticate every commit by turning on the Enforce Author Hook, https://marketplace.atlassian.com/plugins/com.risingoak.stash.plugins.stash-enforce-author-hook

This will prevent pushes where the author information on every commit being pushed does not match the information of the user doing the push. Since it only allows pushing authenticated commits (as long as the hook is enabled), there's currently no reporting on authenticated vs. non-authenticated commits, but adding this functionality is certainly possible if that is something you are interested in. Feel free to get in touch: support@risingoak.com

I'm evaluating this for the company I'm working for and we have very similar requirements. Ideally, I would like to make sure that the identity of all commits are authenticated.

This seems virtually impossible (well, theoretically it can be done by git GPG signatures with a PKI server etc, but that is way too complicated and virtually unsupportable), so we've been discussing ways of at least authenticating the commits in the push that has the same identity as the user performing the push (using the hashes).

That would give us a status of each commit as authenticated or unauthenticated. I guess that blocking unauthenticated commits and commit removals as configuration options would be quite neat.

This will require some changes to Stash, but Atlassian is aware and I hope they'll get a chance to spend some time on this in not too long.

Cheers,
Daniel Petzen

We just published a hook using the new support in Stash 2.2 to enforce the author email address and optionally the display name as well. It's available for free in the marketplace: Enforce Author Hook for Stash

Something like that would definitely be a big help for us.

Mr. Rosauro's script is also something we would want to look at. (Does Stash expose anything besides the REMOTE_USER for username? Forcing people to set their user.name to their username is actually okay as far as I'm concerned.)

Using the Atlassian provided sysinfo plugin as a starting point, we wrote a custom plugin that's notified when a commit is performed (on ANY repository), and the details (including authenticated userid) is pushed into a custom table on the back-end database. A new "Audit" tab is then present in Stash for every repository that you can click on and view auditing details. This is enough to meet our auditing requirements for now, but we would love to see something baked-in to Stash...

The only thing we haven't figured out: the audit plugin records everything, except we are unable to determine who created a branch. You can obviously tell who made the first commit to a branch, but if someone just creates an empty branch (as a placeholder for other users to begin do work), then there doesn't seem to be a way to determine who actually created a branch. Not really a big deal since merely creating a branch is not a meaningful change, but it's a feature project leads have asked for...

(I would love to share the plugin code whenever we get the chance to "sanitize" and clean-up the code a bit...)

I have worked around this "problem" with the attached pre-receive hook script.

This makes it mandatory for the username of the commits to match the stash username, except for pre-existing commits (merges).

It may be useful for someone else...

Summarizing my general wishlist as far as push auditing:

• Option (not controlled by project admins) to enforce use of details of account used to perform push
• Logging of pushes (and all other repository operations including permission changes), with export capability
• UI to view all pushes, sortable (and possibly a way to export that info)

Correct; Git Enterprise, and Github Enterprise both do this, with exhaustive auditing, security, and permissions capabilities. gitinabox (the downloadable version of Git Enterprise) should also do it.

I guess this is not really the git issue, if other based on git services solved it somehow: (https://gitent-scm.com/gitent/doc/GitEnterprise/Auditing.html , https://support.enterprise.github.com/entries/22260573-audit-logging)

Agreeing with the previous comments from Mr. Feldhacker and Mr. Kraportov.
We are trying Stash now, and it is absolutely necessary that we can have some option to toggle whether we 'respect' the user.name and user.email fields from the committer's git configuration. It is not okay to rely on the user to provide the appropriate email or name--leaving aside the ability of using SSH keys (it is not possible in many implementations), what is the point in having people authenticate with usernames and passwords if those usernames aren't actually being used in the repository's commit history? Or using directory services (such as Crowd) that have administrator-set usernames and contact emails?

The priority on this should be a lot higher than it is; it is a blocker for strictly controlled enterprises that rely on accounts and not keys.

Implementation-wise:

• Administrators need to be able to FORCE username/full names/emails from the authenticating directory at the global (not project) level upon push.
  o This does not mean you have to reject pushes that contain code from other repositories.
  o It does mean that when someone pushes to a Stash repository, you must be able to know exactly which user account did the push.

• Administrators need to be able to require signatures for a project if necessary.

–

EDIT: The enterprise need being expressed here is not that we want to force all commits for all time to have proper names.

Obviously when you do basic things like import from other repositories, the author names and emails aren't necessarily going to match up. And if you do a push which is a roll-up of other changes in a remote team's repo, you just can't enforce valid usernames and emails on those individual commits. It's how git works, good or bad.

However: When pushing to Stash, an authenticated user is doing the push to enterprise resources, and we need to know exactly who is responsible for each push that occurs.

Example: If I look at the list of commits for one of my repositories, I see a long list of commits that are git-svn messages, with the usernames for the commits being 'olduser1', 'olduser2', so on. But that's not okay. Some user is providing a valid username and password to do those pushes, and I want to know who it is. In the current UI I just don't seem to have a way to see who is
responsible for putting things into the managed repository. This is quite separate from issues of permissions and goes to change accounting.

Is this possible? Possibly. We have access to REMOTE_USER in hook scripts, we have the capability to use git notes, and if repositories can have their configuration properties set within the Stash UI, I think that things like core.logAllRefUpdates are going to progress us towards filling this logging deficiency. Gitolite is capable of providing this type of logging information, and I'm sure that Stash is capable of providing the same info, more nicely.

Gitolite legacy docs for manual implementation: http://sitaramc.github.com/the-list-and-irc/real-blame.html
Gitoloite 'current' better-logging docs: http://sitaramc.github.com/gitolite/g2/tipssec_.html#tips_notes_better_logging_

This issue looks like a show stopper for us. As a SOX-regulated firm, we absolutely need to know who is responsible for a change which goes to production.

It would definitely be a useful feature to have a record of what was contained within push to the server. Currently, when I look in Stash I can see the commits that were pushed up to the server and their 'author', but I would like to see the record of who performed the push and also the commit hashes that were included in that push. It may not get down to the detail level of who actually made the coding change, but it would at least be a step toward providing the higher level of traceability that we require.

I think to prohibit pushing commits that are not authored by the pusher would be easier said than done. Commit author is recorded using the user-asserted display name and email address; but when authenticating to Stash I use my sAMAccountName. Even if you look up full account details from the identity directory, there could be differences in the names, preferred names, alternate email addresses, etc. that would all add to the "matching" complexity. And there still could be legitimate reasons for a user to push changes that they did not necessarily author – albeit much more rare in an enterprise setting, but it could still exist.

From an enterprise perspective, I think there two "levels" of traceability possible:
1) At a bare minimum, it needs to be possible to determine who made what changes to a repository on the server. When a logic bomb or penny-stealing bug is discovered in the application source code, it needs to be possible to determine who introduced the change with a high degree of certainty. With most non-DVCS solutions, this can be accomplished by viewing the change history and relying on the information recorded there. Not so with Git. Data in the author field for a given commit is unreliable. However, if Stash provided an audit trail of the authenticated user that pushed a given commit to a repository on the server, this would go a long way to accomplishing the traceability goal fairly easily. (The audit trail would show that Alice pushed commit ID XYZ to the repository on the server. Yes, Alice could claim Bob actually made the change, but Alice was ultimately responsible for pushing the change to the server.) This is akin to an ISP being able to provide the IP address from which certain traffic originated, but it does not necessarily mean the name on the ISP account was directly responsible for the traffic. Such audit trails are still valuable even if they can't establish complete certainty.

2) A step above the bare minimum server push audit trail would be attempting to achieve a high degree of certainty regarding which user was actually responsible for each commit. This would be accomplished using commit signing tags. Stash should provide an option to require signing tags for a particular repository, and reject commits that lack such signatures. Only signatures that are valid and were generated by a certificate issued by a specific CA (or CAs) should be accepted. This would go beyond just knowning who pushed a change; it would be known who actually committed the change.

And what if users were forced to sign all commits with PGP? Could Stash verify all commits, even merged ones?

I imagine there are some enterprises that would see this as a security risk instead.

Hm, I think it's working against not with the tool. If you merge a branch you have a number of changes that you will push that you haven't authored or commited. With fast-forward merges there isn't even an explicit merge commit. Prohibiting pushes not authored/commited by the person pushing the changes not only breaks the functionality of the SCM but all the Stash features built on top of merges.

This is DVCS. This is a feature! The person pushing changes to Stash could be pushing a number of changes and not necessarily changes he/she authored.

I imagine there are some enterprises that would see this as a security risk instead.

We could add a per-repo option to prohibit pushing commits that are not authored by the pusher - this would be a simple option for those not wishing to dive into signing and it's complexities.

It would need to be able to be toggled to let the initial push of repositories go through and thereafter be strict.

I think this is conflating two concerns.

Traceability of a push means having a record of who pushed what. This is a valid use case and a good feature to have.

Verifying the identity of the author of the commit on the other hand is a different thing and could be solved by signing the commit (brittle) or signing tags (thus confirming that the commits reachable by the signed tag have been vetted) using keys that are known/can be linked to the users in question.

when performing a push, stash doesn't ensure that the user performing the push is the same user as the GIT comitter

This is DVCS. This is a feature! The person pushing changes to Stash could be pushing a number of changes and not necessarily changes he/she authored.
Merging branches, cherry-picking single commits or accepting changes via patches are all means that bring in changesets authored and/or commited by other people.
If I then push the changes I haven't authored all of them and Stash MUST not reject them.