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

  • Amber Van Hecke staff

    All, I know it's frustrating to see this ticket continue to be labeled as 'open'. (this is an issue that I too see value in) I wish I had a better update for you, but unfortunately, I do not. This issue is still in our backlog and you will have to continue to use terminal over the UI to check signatures. I know this isn't the update you hoped to read, but please note that we are working hard and we do care about your feedback (even though it may not seem like it when viewing a 7 year old, open ticket).

Comments (134)

  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. Cruz Bishop

    Please at least hide GPG information from commit messages as a temporary solution.

    It makes it very hard to read the changelog and/or commit tree,

  3. Ramnique Singh

    Can you guys please give an estimate on this? The GPG information in the commit history is causing it to be unreadable.

  4. Mariusz Gronczewski

    Could this at least be patched so it doesn't show sigs in commit messages ? It makes repos using GPG unusable on bitbucket

  5. Charmander

    Ignoring the signature in the one-line summary, if not when viewing all commit information, would be helpful.

  6. 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.

  7. 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. :(

  8. David Mays

    Just spotted this feature hit and I've already started using it. Would be nice to see BitBucket follow the example.

  9. 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.

  10. 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.

  11. 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.

  12. 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. :)

  13. 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.

  14. 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.

  15. 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.


  16. 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.

  17. Martyn Chamberlin

    I tend to agree with Karl, although let's not forget that Github didn't offer this feature until spring 2016.

  18. 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!

  19. Alexander Ovchinnikov


    P.S. Atlassian bought Trello, why did you do that if you have no time for your current projects?.. HipChat (no updates for long time), Bitbucket... Goodbye, old friend Trello...

  20. whoami

    Guys, do unlogin from main site and look at this, it looks like they no longer want to work with mercurial :(

  21. Ryan Moore

    😐 @Marcus Bertrand any progress, or word of where this feature is in priority? If it's been in the backlog for ~6 years without implementation is anyone at BitBucket ever going to do it?

  22. 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.

  23. 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?

  24. Eivind Brandth Smedseng

    +1 Have the need to see signed commits in the UI, and require signed commits and tags.

  25. 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.

  26. Former user Account Deleted

    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.

  27. Paweł Święcki

    Yes, Gitlab > Bitbucket. When the gap is big enough there won't be any excuses migrating not to migrate. Sorry Bitbucket, it was fun, while it lasted :(

  28. 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.

  29. Ben Wolf

    It would be great to have this feature in bitbucket. Might be a reason for me to switch to gitlab or GitHub..

  30. Дмитрий Unknown

    Over 6 years of no activity. Support managers are hidden (Marcus Bertrand) from the eyes (Alastair Wilkes) and thinks that pull requests (which are already existed for a while), code search (git log -p?) and "general user experience" (c) (UX?) is more important than security issue(s). Bitbucket, is it correct? If you think so, please read this again.

    I can imagine that the vast majority of members are developers like me or users that know Git more or less, and they know how to use it locally on some GUI or even on command-line level. Well, in the bunch of cases (please correct me if i'm wrong) it is not a critical if we won't have the extra code search feature.

    Even crucial security services can have critical vulnerabilities which can lead to high reducing trust. Even Atlassian's projects (and Bitbucket is Atlassian's project, as I can see in SSL certificate, isn't it?) can become an attacker's victim.

    Let's imagine if I upload my code via HTTPS with using git push. Git pushes its commits by the same way like patches. If your HTTPS has some vulnerability or server-side injection then there can be successfully run this and git commit --amend after that. Then you can apply modified patch successfully and correctly. I does not have a goal to provide you a real attack flow but you should see the point. This attack chances will be reduced hardly if I sign that commit by using own private key which can be hacked only if attacker steals the key and hacks the passphrase: for AES-256 there are 2^256 different variants. Final system (Git, when I or co-worker will try to download changes via git pull) just show that signature is invalid or data was corrupted. You know that it is impossible? Then please read this.

    It is important for projects with high security requirements: payment systems, medical sphere, things that are grant access to some high-priority point by some restricted authentication algorithm.

    I am a BitBucket user for a several years. But if it is asleep for a long time, even with support team which was posted here only 2 (two) messages for a 6 (six) years of asking and discussions, then maybe I should need to move to another (alive) system... Github, Gitlab - they looks more compliant and specifically this security feature has been realized there for a while, even with subkeys support.

  31. Unknown user ad31e

    @Atlassian: Any updates on this?

    We are using mercurial and we must sign our commits (Company Rule).

    It works really nice, some developers use OpenPGP smartcards and it works very nice for daily use. hg verifysig 99 99:9c33e87a787a: good gnupg signature from xxx xxxxxx

    But we cannot use GitLab or GitHub: On E-Mail Request to GitHub (03.11.2016): "...Thanks! I checked with the team and confirmed that we currently only support commit signature verification in Git. I can definitely pass along a feature request to support Mercurial as well, though!.." Till now, nothing has happend.

    Our idea to run BitBucket on our server-infrastructure won't work. Mercurial is only supported on the Cloud:

    It seems so, that trusted code on cloud has not that high priority ala Cloud First, Trust Last. Might be we are here to paranoia in Germany/Europe about trust/security.

    Our last hope is now and waiting for a response... If this fails, this might be a small business opportunity for a small, but fine new Mercurial Server for maintaining trusted/verified code in the cloud ... ;-)


  32. Levent Yalcin

    I'm a member of Enterprise grade org and someone committed and pushed some code with my name. So, f* yes +1

  33. Amber Van Hecke staff

    Hi everyone, I know many of you have been watching this ticket for a long time. Sadly, I don’t have good news for you yet. I know this isn’t what you want to hear but as previously stated, we are currently working towards improving core areas of the product such as pull requests, pipelines, code search, and performance.

    Unfortunately, signed commits isn’t on the list right now, but it is in our backlog of work and is something we greatly want to pursue. I ackowledge this would be a valuable security feature (I too would much prefer to check signatures via the UI instead of terminal).

    Your comments are something I take very seriously, please continue to add feedback describing any use-cases that are important to your team. I will continue to give you status updates monthly.

  34. Roman Gorodeckij

    That's why I've moved to gitlab. I mean what's the point of this service when it can't do even basic features like grouping of repo's and signed commits. Useless. Sorry Amber, but your CTO or CPO doesn't understand IT market at all. You currently loosing even more than Github. Gitlab is taking it all.

  35. Tom Forbes

    This is ridiculous. What a joke. You've been improving the rest of the site for years and years now, and it's still downright terrible in so many ways.

  36. Deniz

    @Stephen Reay Hmm, under these circumstances, I have to withdraw the wording "locked away". Wouldn't it be easier for Atlassian to retire the BitBucket Cloud software and replace it by one or more instances of BitBucket Server?

    An update by Amber Van Hecke would be nice anyways regarding the development status of this crucial (in the opinion of the community & in my opinion) feature.

  37. Stephen Reay

    @Deniz Then we'd lose the "cloud" only features, notably, support for Mercurial repos.

    I want GPG sigs as much as any of you, but giving up Mercurial support for it, is a deal breaker.

  38. Frederick Zhang

    Why would we lose Mercurial support if GPG is implemented? I personally don't use Mercurial so sorry if it's a dumb question.

    And honestly I was quite surprised to find out that BitBucket does not support GPG yet while almost all other major players have implemented this functionality.

  39. Stephen Reay

    @Frederick Zhang the suggestion from @Deniz Ilhan was for Atlassian to abandon the current implementation of "Bitbucket Cloud" software and replace it with the "Bitbucket Server" (so that Bitbucket Cloud is essentially just a hosted copy of Bitbucket Server) because that would bring with it, GPG signed commits.

    The problem with that scenario is, Bitbucket Server doesn't support Mercurial, at all.

  40. Amber Van Hecke staff

    All, I know it's frustrating to see this ticket continue to be labeled as 'open'. (this is an issue that I too see value in) I wish I had a better update for you, but unfortunately, I do not. This issue is still in our backlog and you will have to continue to use terminal over the UI to check signatures. I know this isn't the update you hoped to read, but please note that we are working hard and we do care about your feedback (even though it may not seem like it when viewing a 7 year old, open ticket).

  41. Yonatan Miller

    It would be easier to have empathy, if we knew what Bitbucket was ACTUALLY working on. I know everyone values their feature requests, but I still do not understand what Bitbucket is busy with.

  42. Magnus Alstad

    I would like this feature to be implemented so we don’t have to go looking for other service providers providing this functionality out of the box.

  43. Tom Forbes

    Of course. The point I was trying to make is don’t expect this issue to ever be closed, based on the general state of the product.

  44. Levent Yalcin

    Sorry to bother everyone in this thread but there is a slight chance this issue could be stuck because of human factor other than decision or process. I’ve pinged Atlassian and Bitbucket on Twitter whether they’re aware of the users' frustration or not. It would be nice if you could do the same and see what happens. Again, sorry to create such noise.

  45. Log in to comment