Security and DVCS Connection/SmartCommits features

[Antoine Millet]

Hello,

When I configure DVCS connection on my Jira instance and my Bitbucket account, Jira will configure a link for each repository hosted by the Bitbucket account. The link configured look like this:

From: Custom ((?<!\w)(()-\d+)(?!\w))
To: https://example.atlassian.net/browse/\1

Each time I push a commit with a new issue key, the link is automatically edited with the new project key. For example:

From: Custom ((?<!\w)((TEST|DEMO)-\d+)(?!\w))
To: https://example.atlassian.net/browse/\1

I can see a security problem with this, and the SmartCommits feature: if user-1 has a write access to a project-1, and a user-2 has only the read access on project-1, but has a write access on the repository-1 on bitbucket, forge a commit with user-1 as author, he can act on the project-1 issues behind the user-1 account.

Is there a way to force DVCS connection to only link a given Bitbucket repository to a given Jira project?

Thanks,
Antoine.

[aMarcus]

Hi Antoine,

This is not how the integration functions. The issue links on your Bitbucket repository are only to 'dress up' the issue keys when presented on the Bitbucket website. The DVCS connector in JIRA connects commits to issues by reading the issue key on the actual commit message. The smart commit transitions will trigger if the email address associated with the commit match the user's email address in JIRA.

To be fair, there is always the possibility that your end-users could set a different username/email address to be stored on their commits. This is part of the intentional design of Git and Mercurial and outside of the control of Bitbucket or JIRA.

Cheers,

Marcus Bertrand - Bitbucket Support

[Antoine Millet]

I agree with you for the weekness introduced by DVCS for this kind of feature, but a simple way to reduce the scope of the problem is to establish a strong link between a Jira project and a Bitbucket repository, and disallow a commit pushed in the repository A to trigger an action in project B. Maybe I missed this feature in Jira/Bitbucket, can you confirm that it doesn't exist?

[aMarcus]

You control this by not including the user in project B. The JIRA DVCS connector is connected by the user associated with a commit's email address. If that user doesn't have permissions (in JIRA), they won't be able to action issues they don't have permissions to.

[Antoine Millet]

Yes, but as you said, the user email address can be changed in commits...

[aMarcus]

By design of Git and Mercurial, there isn't really any way for JIRA or Bitbucket to control this. They both imply a level of trust on the users who have permissions to push into your repositories.

[Antoine Millet]

So there is not way isolate project and repository per team? My use case is for a compagnie with several teams which are working on different projects (each project is a Jira project associated with a Bitbucket repository). If a team has write access to a set of project, I don't want it can act on another team's project.

On a different scale, where the compagny is a big group, and the teams spreaded in different subsidiaries, it becomes difficult to base security on trust.

[aMarcus]

Beyond the previously mentioned JIRA permissions, you could also use Git/Hg signed commits. At present, no Git/Hg hosting service that I'm aware of supports the verification of signed commits, but, you can still use them and manually verify as needed that the commit in question belongs to the user you expect.

For this to be enforced as a requirement, the Bitbucket service would need to verify all incoming commits from pushes against your key(s). We have an open issue for this, but at present it isn't on the radar to be implimented in the next year. If there is significant enough interest for this as a feature, this could change of course.

If none of these options satisfy your needs at this time, Git/Hg may not be right for you. We still offer Fisheye as an option for behind the firewall. It can host subversion repositories and secure them as you need.