Support signed commits for Git and Mercurial (BB-319)

Issue #3166 open
Andreas Sewe
created an issue

Check for and display a 'verified' icon or something as well.

Official response

  • Alastair Wilkes staff

    We agree that this would be useful and want to add it at some stage. However, we are currently focused on improving other areas of Bitbucket (including pull requests, pipelines, code search, and the general user experience), so this feature request remains in the backlog at this time.

Comments (106)

  1. Dylan Etkin

    Hi Andreas,

    The idea of supporting signed commits has certainly been bumping around our team for a while.

    Its not high on our radar right now but its in the backlog.



  2. Ramnique Singh

    I feel this is a very fundamental requirement, which should be given a higher priority. Many git users are now signing their commits. It's impossible to view the commit log on BB and is a major decisive factor when choosing between BB or github (and i want to favor BB). Hopefully, this will be resolved soon.

  3. Cruz Bishop

    Could somebody please give us an update on the status of this issue? It's a cosmetic issue that has not been resolved or even worked around for almost two years. :(

  4. Ryan Winchester

    @darioml everything he is saying is that you should sign tags not individual commits.

    You can do none of these things sanely if you put the signatures into the commits themselves.

    So don't do it.

    And in his grand finale, in true Linus style...

    Btw, there's a final reason, and probably the really real one. Signing each commit is totally stupid.

  5. Dawson Toth

    @Ryan Winchester I believe Linus meaning with that statement is considering the goal of verifying the integrity of the entire project. I believe a very legitimate use case for signing individual commits is verifying the authorship of a single commit. For example, if I merge in a PR from a co-worker, and tag, then my stamp of approval is on the state up to that tag. But what if my co-worker (or someone with access to their machine) maliciously made a commit with my name and email, and I don't see it? Well I've placed my stamp of approval on the whole darn thing. You can say, "Well, be more careful next time!" Or, if each of my commits are automatically signed while on my machine, and I maintain reasonable security of my machine, then I can at least say "either someone else is impersonating me, or I intentionally didn't sign that commit to trick you all". So... not totally stupid, in my humble opinion.

  6. Stephen Sykes

    We sign individual commits - it ensures the we know how each piece of code got into the stream - a specific known individual put it there. Unless you tag each commit (clearly absurd) you can have code in the stream which isn't vouched for. Now, certainly if I sign a tag you can argue I am vouching for the full history of the stream (including all child commits) up to the tag. But this isn't realistic - there's no way a single individual is going to fully review a huge code base and every commit leading to it. For us this provides a level of security that we know the code stream hasn't been hacked. provides nice bedtime reading that I find more convincing than Linus' posts.

  7. Nestor Mata Cuthbert

    Right, that is the greatness of open source. The system can became better that the creator would make it. Git is being used in many ways that Linus would not use it, probably like teams. In the flow of work that him uses is probably unnecessary and idiotic to use signed commits, but in the flow of many of us is indeed necessary.

    One example is that developers get angry at work, they may want to get back at some coworker or their chief or a client and they may try to undermine the code and not leave a trail. The simple case that Git does allow you to impersonate someone else when doing a commit it is a huge security risk, but it is like that because is a non centralized system (probably Linus also thinks Github or Bitbucket are unnecessary). In that context being able to secure a way to know the commit was indeed made by the person it says it did it, its a required feature in my opinion.

    I love Bitbucket and I use it every day, but I think it would make it a lot stronger to support signed commits. :)

  8. Edward Dumser

    @Nestor Mata Cuthbert I will assume that Linus does not think Github to be useless: though of course services like Github are not necessary for Git to work properly.

    @ topic In open source, every single commit has to be in-depth checked for legitimacy, correctness and style anyway, and then they can be collected into a tag and signed by the responsible. So Linus saying that commits need not be signed is perfectly understandable. However nobody is going to pay a software development company to do that. (if its not for high-risk software like say aerospace, banking, etc.)

    But it does make sense to establish the origin of a commit in a company, so you can quickly wave a red flag if the committer and the signature do not match, or simply reject any commits where something like this happens (and notify ops).

    This easily catches cases where a developer just copies the config file from another and commits code with their name, or where they use their private config or config from another company, etc. It's not hot when you ship the repository to a customer and something like "" committed half the code.

  9. Walter Dolce

    The idea of supporting signed commits has certainly been bumping around our team for a while.

    I hope the feature it's in your radar by now. There are plenty of large enterprises out there who require engineers to digitally sign the commits they perform on the work they do. Having a visual reference here (and for those who integrate with Jira, there as well) would save some time to those required to verify a commit has been signed during code reviews, etc.

  10. Martin Trneny

    Hi all, I don't want to make a raw complaint to Atlassian about this "minor" enhancement. Rather I'll post there a real scenario where we really miss this security feature (today I think we could't call it feature because many competitors already have it so it should be a core function) and it complicates are lives.

    We are moving our business to cloud and had decided to purchase Atlassian tool set. As the security is essential for us we created a security architecture based on Atlassian tools (may be mistake now:)) and AWS where necessary. In short scenario looks like: 1. Developers have to sign each commit (they sign commit at local PC) 2. After a Pull request all commits are validated against trusted keys (we check code integrity) 3. and further....

    In step 2 we supposed that all interaction will be in Bitbucket UI (review, approval, merging) - ouha - there is a "Merge" (merge commit) and because of this Issue #3166 we are unable to sign this merge commit so we cannot perform merging from Bitbucket UI. You can think OK just do a merge commit from your local PC but why? In our GIT flow a Pull request must contain only commits which couldn't cause a conflict during a merging so then reviewer is really a QA guy who performs review and then click Merge (advantage - reviewer doesn't have to have code at his/her PC, reviewer uses just Bitbucket UI wherever he is).

    So what is a conclusion: Atlassian you have there a real scenario (business case) where this Issue #3166 makes your tool useless.


  11. Karl Hepworth

    +1 - This is a serious problem in business, and the open source community in general.

    You want people to create big projects and have no serious way of verifying the identity of those who commit to a project, it will never happen to those who take a serious investment.

    It might also contribute to why all the big projects never seem to touch bitbucket, not out of choice but because there's no logic in the decision.

  12. Benjamin Hirsch

    After 5 years since request, it's still not implemented - ridiculous. :-( Atlassian - hello, wake up, your major competitor has this feature already implemented, it's time to close up!

  13. Alastair Wilkes staff

    We agree that this would be useful and want to add it at some stage. However, we are currently focused on improving other areas of Bitbucket (including pull requests, pipelines, code search, and the general user experience), so this feature request remains in the backlog at this time.

  14. Stephen Sykes

    So we don't have any of these new features, nor do we intend to use them. But we do use signed commits as do a variety of others, and lack of support makes it more painful to manage.

    How about doing the basics well, and then adding bells and whistles?

  15. kinoshitajona

    This is kind of ridiculous that such a simple security feature still is not available...

    I make sure to pull and check logs for signatures, but it would be nice to have it in the GUI.

  16. Anonymous

    Signing source code commits in order to prevent 3rd party injection of malicious code is required by may of our customers and required by most of the company certification processes (ISO 27001/2, BSI IT Grundschutz, etc..). So you basically prevent your customers (us) from using your products (Bitbucket) in companies which have to follow such certification guidelines.

    @Alastair Wilkes: So this is definite not a nice to have. This is a mandatory must have.

  17. Frank Schmid

    I see this feature much higher than any UX changes because it would show the validity of signed commits and makes sure that commits are really from the person mentioned in the log. A strong argument for it is, that you just can set and in your git config and commit - whoops, you changed your identity. GitHub does it now for a long time - that is a big pro for them when comparing... UX does not really matter. We are dev people not PMs.

  18. Log in to comment