1c505570e116 would be amazing if you could implement a fix for this as well - BCLOUD-23511

Thank you 1c505570e116 and all of the team that completed this functionality including SSH key support ❤️

1c505570e116  Quick question about the March 6th update to include SSH keys (thank you!!) - the edited deleted the text "and system signed".

I am interested in system signed commits - by "system signed" i'm imaging that the repo can use it's pipelines ssh keys to sign commits that it makes? Is this the current state of this:

1. It already just works - any git commit made by pipelines with the system keys configured for push will sign commits using these keys. This would be :amaze: :magic: (but i think its hard because my setup has a few more layers that i suspect need special treatment).
2. As already supported as it needs to be, because a build running in pipelines has access to the keys, and i just need to configue my git to sign using these keys (which is is already using to other repos for example). I can probably figure this out if so, but a pointer to documentation specific to Bitbucket (i know how to configure git to sign commits) might be handy if it exists.
3. Planned to get additional support so that something just works out of the box when using bitbuckets documented support for pushing back to the host repository - i.e. SSH Key pair managed by Bitbucket Pipelines section of https://support.atlassian.com/bitbucket-cloud/docs/push-back-to-your-repository/ (yes i know the signing happens at commit not push, but it feels like you want the push because you made the commit, so maybe there's some "works out of the box" here). I.e. this is "we want (1) but its not done yet".
4. Split into another issue (since i gather that it's not part of this issue any more based on this deletion and the fact this issue is closed),  
   in which case can you link the issue for supporting system signed commits
5. Not supported, and no work currently planned / moved to gathering interest (in which latter case i'd like an issue so it can gather my interest )
6. Not supported and planned to be not implemented (in which case i can roll my own completely i guess, but i'd also be interested in the reasoning here).

My guess is (2) - but i thought i'd check before diving in - if so, a quick ack of this would be appreciated.

Launch support for signing commits with both SSH and GPG keys.

Is there any news on Signed Commits Using SSH Keys? I'm a bit afraid this items is going to get closed without taking this into account. I do want to remind that in the past, signing commits with SSH keys was a thing that was supported.

Above link ( https://www.atlassian.com/blog/bitbucket/strengthen-code-security-with-signed-commits ) is a 404.

Is there a timeline for verification against ssh keys? This should be the first choice because the most devs should have them in place.

I'm having the same issue as 811c97c268d7. Prior GPG signed commits with the same pub key are still showing as "unverified" but new commits (with no other change except adding the public key to my account) are showing up as verified. Since of course we're no longer allowed to create tickets anymore, can someone at Atlassian track this for us and let us know here, please? Thanks.

Edit: miwalker added this for me here: https://jira.atlassian.com/browse/BCLOUD-23508

Existing signed commits don't show up as being signed (let alone verified), will the signing status of these commits be refreshed at some point?

If signing commits with SSH won't be supported soon, the unverified label should not be shown if the commit is signed with SSH, as it is misleading.

47054ed56f17 : It doesn't seem to include signed commits with SSH keys as of this moment. I've encountered this myself today and asked a question in the community forum which directed me to this feature request.

Hopefully this can be part of this feature request <3

Does this include support for Sign commits and tags with SSH keys?

... release planned for December 2024

Can we get a status update on the release plan 1c505570e116? Are we still on target for next month? I wanted to ask since we're near the end of November 2024 and this feature is becoming a major issue for our InfoSec team, potentially impacting our ability to be allowed to continue using your service. Thanks!

[...] release planned for December 2024

Aw, snap! So that means we'll still have the chance of celebrating our 13th year of waiting (the date is coming up in a bit over a month).

I appreciate your patience with this feature! Thank you.

Our pleasure. I was willing to wait another 13 years!

.. now if we only could get some proper Markdown on the JIRA comments here, as opposed to Yet Another Proprietary Markup...

When implementing this feature, please keep in mind that GPG isn't the only way for signing. Please also support alternatives like Sigstores Gitsign (https://docs.sigstore.dev/cosign/signing/gitsign/).

Bitbucket Cloud product manager here - engineering work for signed commits is well underway, with release planned for December 2024. Keep an eye out for more details. I appreciate your patience with this feature! Thank you.

c1943c562d73 your comment makes me sad. I think it reveals the priority thinking of Atlassian. I know GPG is still on the roadmap - but it was bumped from 2023 to 2024, and your comment makes me believe it will be bumped again.

It's okay though - I'm moving on.  I won't be sad for long.

CHEERs to all the others who are watching this issue.

Hi All, Now Bitbucket Cloud has been enabled with Forge capabilities. You can build custom Forge apps to have a merge check in place for your production branches to validate the commit author email domain, ensuring it belongs to an authorized domain.

For example, if a user's official email domain is "test.com" registered with Bitbucket Cloud, but they have set a different email domain "abc.com" using git config, they will still authenticate to Bitbucket Cloud using "test.com" and push commits. However, the commit author isn't recognized in the Bitbucket Cloud UI since "user@abc.com" doesn't exist as a valid Bitbucket Cloud user. Such merges to production branches can be blocked.

Here is a sample Forge app that performs this validation: Forge App Commit Email Author Validator. For example, it blocks any email domain other than "test.com". This is not a replacement for signed commits but can be implemented as a check since signed commits are not yet implemented.

I missed the 12th anniversary too, but at least I can wish all the commenters Happy Holidays!

And onwards towards another New Year Without Signed Submits (since this issue has been postponed from Q3 2022 to Q3 2023 and now to Q4 2024 and, again, it has been assigned to another inactive worker)!

One notices a pattern here — after 12 years, it becomes obvious that Atlassian is anything but interested in implementing this on the free version of Bitbucket Cloud.

@Gavin Gration suggested:

I can't say for certain (as BB is closed source), but given that this feature is already available in the server version of Bitbucket, I'd estimate it'd take only a few days max to implement/enable in the Cloud version. 

Aye, I would consider that to be a very reasonable assumption, too

There is an ancient saying that goes, "Don't assume maliciousness with incompetence" (or words to the effect). In other words, it's always more likely that people are incompetent than actually evil. But, as Sherlock Holmes would say, "When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth." i.e., assuming that nobody working at Atlassian could be that incompetent (or why would they be hired?), then one has to admit that the real reason for this 12-year-plus "delay" is simply because Atlassian is well aware of the issue, and has a solution, but couldn't care less about its free users (therefore, Atlassian is Evil. QED).

(I know, the above paragraph also has at least three logical fallacies )

@Andrew Murdoch, by contrast, seems to be pretty much the king of logic fallacies (maybe he secretly works for Atlassian?). Here are some random thoughts:

there's no reason you can't grab the keyring, and do a local side validation with your DevOps / DevSecOps team

I'm not quite sure how Bitbucket does this, but AFAIK, the additional bits containing the PGP signature get stripped out of the commits in the process of pushing it to the Bitbucket servers, which is, indeed, what would be expected, since it's a "not supported" feature...

GIT is, and always has been, a command line tool, so adding on GUI's and WUI's is really just sprinkles on the icing, on the cake.

While one can unambiguously argue that, when Linus Torvalds invented Git in the early 2000s, he used it mostly as a command-line tool — and I dare any of you to claim you never used it as a command-tool to fix a particular complex issue of some sort!! — it's worth mentioning that most programmers these days do not use command-line vi or emacs to do their regular work any more (and, even if they did, both tools support quasi-flawless integration with Git signing). GUIs and WUIs is what people use in the 2020s on a daily basis, so that is what's expected to be at the core of a developer's arsenal of tools.

Otherwise, why use Bitbucket/GitHub/GitLab/Gogs/Gitea at all? You can simply use a command-line Git repository, spinning off a tiny cloud-based VM (for redundancy and resilience) and just installing a minimal OS with just git on it. Like Subversion before it, current versions of Git even provide a very simple Web-like interface — no bells, no whistles, nothing but a bare-bones UI, but it works. You don't "need" anything more than that. A shell prompt, git, vi/emacs, and a remote server somewhere — that's all it takes.

Nevertheless, that's not how the vast majority of developers work today, except for some system administrators (/me points to self) who sometimes are completely GUI-less and still have to fix some broken code in an emergency. But even us die-hard CLI fans do use the "extra tools" provided by these automated Git-compatible repositories — integration with other tools, for instance; webhooks; code automation; etc. and so forth. You can even use some of those from a pure CLI environment, too!

But signing commits is not a "feature" of the giant repositories. It's a feature of Git itself. Now, naturally enough, the huge repositories (most notably the Big Three, but the same applies to all others) provide "Git compatibility" to whatever degree they wish, going as deep as they want, often automating the most complex of the procedures, hiding what goes beneath the hood; and many (I have no idea how many) even use the popular libgit2 library (or any of its ports/integrations/derivative work/rewriting in other programming language) instead of calling the command-line git directly, and are thus "limited" to whatever their flavour of libgit2 provides, and may (or not) add additional features on top of it.

Still, it's to be expected that libgit2, given enough time, will converge with whatever set of features the current version of git supports. Code signing has been supported for eons (although, to be fair, it wasn't there from the very start). And I'm also blindingly assuming that Atlassian does implement Bitbucket on top of libgit2 — this is purely a conjecture, they might use something completely different and developed in-house (as we don't have access to the source code, we'll never know).

The point here is simply that, on one side, you have whatever features the big repositories have implemented on their system. But on the other hand, you have the features that are native to the Git command-line tool. One expects a "path of convergence" between both, but, when in doubt, we should assume that, whatever features Git natively supports on its CLI, are features that we expect to be implemented on any third-party repository we might use. On top of those, we expect more than the "core" set of features already provided by Git (aye, that includes a much fancier web UI). If not — well, what would the point be, then? Linus did give us everything in Git to make it self-sufficient, without relying on any third-party tools; if we use those, it means we need some additional features that Git, by default, does not have (or implements in a very complex and awkward way that can be hidden from the end user).

It's not a case of cherry-picking what Git features should be supported, and which should be left out. GitLab, GitHub, even Gitea, among others, believe in convergence with the full set of features provided by Git — among these, code signing. Atlassian does not. They work under the deluded assumption that developers are "okay" with a crippled version of Git, so long as they add some extra bells and whistles (such as Jira integration, for example).

That assumption, of course, is just an illusion.

But after that, our friend Andrew engages in plain and simple strawmen arguments:

How many of the people complaining about this lacking feature, to which I've been one, sign or encrypt their email?  Does your email signature have the public key fingerprint included? 

(Note: I can truthfully answer yes to both questions )

Why is any of that relevant to the discussion? Bitbucket is not meant to be an email replacement. Also, corporate environments may already provide the required encryption and digital signing embedded in whatever internal system they use — but cannot "extend" such features to Git itself, which means that Git support needs to have its own source of digital signing.

Your question regarding "how many developers sign their emails", while interesting in itself (it's a question I'd love to see answered, statistically speaking), and worthy of a deep discussion elsewhere, is, however, not germane to this question. Bitbucket is not in the business of digitally encrypting or signing user's emails. They're not a "mailbox provider", in the sense that Gmail, Hotmail, Yahoo, Yandex, Mail.com <insert your favourite mailbox provider here>, are (note: most of these providers will also not offer digital encryption/signing by default, but the reasons are totally different, and, as said, totally irrelevant for the discussion here)

Have you also complained that Windows doesn't have native GPG / PGP support baked in?

Again — this is another strawman, and totally irrelevant. You can always add GPG/PGP support to whatever operating system you wish. Having it natively is irrelevant (what does "natively" mean, anyway? You can certainly install a Windows-compiled OpenPGP CLI on your PowerShell very easily).

You could also ask the same about the lack of native Git support in Windows — what does that actually mean?

My point here is that the argument is not only irrelevant, but, in this case, it's not even clear what is meant by having "native support baked in". There is nothing preventing anyone to use a natively-compiled version of GPG/PGP to run — at least, as a CLI — on any contemporary operating system; and most will even go as far as providing — via third parties, naturally — some sort of GUI integration with existing OS tools as well.

What about the lacking GPG / PGP support in Office or Outlook?  [...] do you also refuse to use MS Office because of the lacking GPG / PGP signature support?

Now, for the sake of the argument, let me just add that I do agree with Andrew's issue with Office/Outlook; or, if you wish, Gmail & Google Workspaces; or Apple's Work suite, and so forth; or, for all I know, things like Adobe Photoshop or AutoCAD; none of this tools provide direct GPG/PGP support, AFAIK, although some might be able to use third-party tools.

Another concern is more popularly demonstrated on Adobe Acrobat, which supports X.509 encryption and signing, adds its own system as well, but does not directly support PGP/GPG. Why? Well, there is an ancient reason for that, dating as far back as the days of S/MIME (with central authorities emitting keys) and PGP (relying on the web-of-trust model). Since Microsoft, in the earliest days of Outlook, went with the corporate-friendly S/MIME solution, they sort of "killed" PGP/GPG on email. But the truth is that neither solution caught on — because, with Gmail, encryption would defeat Google's ability to profile a user's email with their number-crunching and AI tools (something that naturally Microsoft also adopted). Apple, who is usually security-conscious, and does not operate its own ad-supported search engine, could, in theory, have much better support for digital signing/encryption, but they seem to ignore it. I do use PGP on Apple's Mail, but not thanks to Apple — I rely on a third party for that.

But, again...

While I totally agree that there is a serious lack of support for digital signing/encryption on the most popular apps and tools that are regularly used by a substantial part of the entire user base (measured in billions of users, that is, as opposed to the millions of developers and programmers), and that this should have long ago been settled (in one way or the other), or, at the least, there ought to have been public pressure from the user base to get PGP (or, well, even S/MIME...) support on all those tools, by default, not as something delegated to third-party tools, which have a considerably small reach and a tiny user base.

Alas, this never happened.

But, again... that's totally irrelevant to the discussion here. In other words, just because MS Office does not support PGP signing by default, it does not mean that Bitbucket should leave automatic commit signing in Git out of its set of features!

There is no formal, logical connection between both. Bitbucket is not a Microsoft Word/Excel alternative. They're not in the same market; they do not supply even remotely similar applications. Whatever happens in the market for "office suites" does not affect the market for "Git-compatible third-party repositories", and vice-versa. It's not even comparing apples to oranges; it's comparing apples (a vegetable) to grains of sand (a mineral). The only thing that is common to both is that "they run on computers" — and that's the only common feature, and I'd even argue that it would still be irrelevant.

You can compare Bitbucket with GitLab or GitHub, though — because these products compete in the same market, with the same audience, with tools that provide similar functionality (beyond acting merely as a versioning system repository), and so forth. They're also interchangeable in a way (in the sense that "all speak Git" so you can clone a repository from one source and push it to a completely different one). As such, it's plausible to talk about things such as "industry standards" or at least "community expectations" (where "community" here means "the community of end-users of Git repositories"). Because these companies compete essentially for the same scare resource — end-users who are developers! — it's fair to admit that such end-users have certain requirements, and that they expect the companies in this market to fulfill such requirements.

While in reality we all know very well that it's the board of directors that makes the decision in Big Corp — and whatever is really provided is hardly discussed with those who will be using those tools — that doesn't mean that Atlassian is free to cut on essential features — and here who defines what is essential or not are the end-users who use those features — just, well, "because they can" and "because the CEOs of the Big Corps who are our customers don't have the slightest idea about what we're actually offering".

At least this has been the case for the past 12+ years with Atlassian. Their competitors, of course, have a different approach. No wonder, therefore, that the user base of Bitbucket has shrunken drastically — and the only reason why it still exists is due to corporate tie-in into other Atlassian products (such as Jira).

It certainly isn't because Bitbucket has been keeping up with what the competition already offers!

To conclude: Andrew, while many of your points are real issues of serious concern, which require a much wider discussion around those essential points you raised, none are valid arguments — "valid" in the logical sense of the discussion — to present here against the inclusion of PGP code signing on Git commits.

They are just strawmen arguments — very valid on their own, but totally irrelevant for this discussion.

I sincerely hope to see further discussion on the arguments you raised, though — they need to be addressed after all, and at the very least, such basic questions as "why do over a billion users trust Google to search through all their business documents and emails?" are well worth a much wider discussion.

Just, please — not here.

Missed the 12th birthday! Whoops. Happy belated 12th birthday, BCLOUD-3166

This is a mandatory feature, without question, but there's no reason you can't grab the keyring, and do a local side validation with your DevOps / DevSecOps team. 

GIT is, and always has been, a command line tool, so adding on GUI's and WUI's is really just sprinkles on the icing, on the cake.   I personally care more that the keyring and keys are up-to-date, then having GPG / PGP support baked into the web interface for the GIT Server.

Any semi-competent developer is going to validate the commits or tags before they start work, and if they're not signed, they'll get that rectified before they start.  It's more important people understand how to use GPG / PGP, then for tool to automate the use of it.

How many of the people complaining about this lacking feature, to which I've been one, sign or encrypt their email?  Does your email signature have the public key fingerprint included?  Have you also complained that Windows doesn't have native GPG / PGP support baked in?

What about the lacking GPG / PGP support in Office or Outlook?  Yes, GPG / PGP is absolutely essential in GIT, but it's also extremely significant in other tools that lack it.   If you're bothered by the lack of GPG / PGP in Bitbucket Cloud, do you also refuse to use MS Office because of the lacking GPG / PGP signature support?

Personally, I care about documents and emails being signed, more than I care about the commits or tags being signed.  You can argue all you want about GPG / PGP for GIT and Bitbucket, but you need to hold a number of other tools accountable, because you either care or it's a game.

With reference to the above comment ^, some industries do require email and document signing along with code signing. Many professional organisations forbid the use of insecure tooling such as MS Office and Windows OS or isolate its use. Just because some vendors and organisations don't take security seriously, doesn't mean we shouldn't. Many developers perform local code and commit signing checks, but if there's a means to make this easier, especially for large or dynamic teams, then it's worth having. 

Looks like this has been added to the roadmap for Q4 2024, I guess there are other priorities (such as "AI-assisted code review") that trump security improvements... 

I can't say for certain (as BB is closed source), but given that this feature is already available in the server version of Bitbucket, I'd estimate it'd take only a few days max to implement/enable in the Cloud version. 

I suspect that competing for investments and limelight with other companies is deemed more important, so we'll get gimmicky features first and have to wait for the more useful/important stuff.

Thanks, Bitbucket.

I'm not quite sure what the new label "migrated" means, but as of today (August 11, 2023) this issue, considered to be a mere "feature", has been moved to the "future" on the Roadmap for the year 2024 (nothing more precise than the year; it could mean "by the end of 2024", of course).

Unlike others, I am going to remain around and get the occasional email from this topic. It always makes me smile to see the status of a 12-year-old issue that remains unresolved; will it make the 20th anniversary? Watch this space!

gitlab.com > User Settings - GPG Keys (GPG keys allow you to verify signed commits.)

gitlab.com > New project  > Import project > Bitbucket import

Sadly, I have to say that due to this issue taking so long to resolve, I have set sail with my team to GitHub.

So long and thanks for all the fish 🐟🐠🎣

Star Citizen is going to be released before this feature gets completed.

This feature is absolutely essential for any serious business. If you're not serious about your product, then get out of the market segment.

Can this please be put in? This ticket has been open for ages and it is essential this is in place for any enterprise.

After spending an unreasonable amount of time attempting to replicate some of the basic functionality missing from BB cloud, we have opted to spend our time moving to Gitlab instead. Good luck everyone else

There's been a rash of new comments from people dropping out completely. I can't blame anyone who would give up, but I've only been watching this since 2021 - I haven't had my spirit crushed yet. Current status says Q3 2023, I can stick with it that long... 

COME ON ATLASSIAN - GIT'R DONE!

DIAMOND GPG SIGNING TO THE MOON!

If you fail, I'm gonna go all Superbacker and spam this issue every day for YEARS!!!

(hopefully I've injected enough internet/pop culture to lighten your day...)

Cheers!

> Give us fair advance and a migration path.

@Gwyneth the migration path exists, it is pretty straight forward. Just make a bare clone of your repos (just fetch the git branches and diff tree, without checking out the files to the filesystem). Then update the origin using the --mirror flag and push to your favorite SCM,

The whole process is described here, and yes it also works with BitBucket, since it is git based:

-> https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository

Personally, I think that Atlassian needs a new project/product line marketeer for Bitbucket. One who has some knowledge about what priorities mean for real customers — not the kind of priorities set by developers who can only imagine what customers want. Not all are like that, of course (no generalisation here!), but it looks like at least the dev managers for Bitbucket are of that type!

This thread has been on for, what, 12 or 13 years? There are hardly any software companies out there — at least not serious ones — who ignore an essential, missing feature for so long and are still in business. I'm not fan of a world with no serious competitors to GitHub/GitLab; those two are constantly releasing new features all the time because, well, they know they have real competitors.

It's not a coincidence that Microsoft bought GitHub.

It's not a coincidence that Google dropped their own repository (Google Code) and essentially moved everything stored there to GitHub. Most of Google's public and open-source projects are still on GitHub (and possibly a few private ones — who knows?), despite GitHub being 'the competition'. And we're talking Google here. Not a startup with no managing skills. There are good reasons why they abandoned the plans of hosting their own repository, and I would dare to guess that the most important one was 'not really part of their business core or focus'. It was better to let it go, without hard feelings. And so — they did. But they also provided a clear, easy-to-understand migration path (to GitHub) for everybody hosting their repositories on their services. For the vast majority of former Google Code users, it was just a question of point-and-click, and Google — to this day — still redirects old projects to the new GitHub addresses.

It's hardly likely that Atlassian will do the same. One day, Bitbucket will be here; the next, it won't, and all Jira tickets related to Bitbucket will be wiped clean. That's the kind of thing we can only expect from the likes of Atlassian. I even dare them to prove me wrong — assuming that they are allowed to read the threads on Jira, which I seriously suspect that they did, a decade ago, but times change, and so does the company; my best guess is that, these days, this doesn't really bother them much.

You see, there is always an evil way of spinning information regarding a product they wish to abandon but are afraid to do so. First, they mismanage the project, without telling anything to their stakeholders (or perhaps even the upper echelons of their corporate hierarchy). Users start to complain. They get summarily ignored. Users complain even louder. Orders are given by the middle-management for remaining silent on the issue. Now users start to abandon the product and go to the competition. The number of users shrinks, and, as a consequence, they will — for a while — get less complaints. They report to the upper management that, while the product is not so appreciated as before (there are less users), at least those that are around are still happy (they complain less in absolute numbers).

The upper management thus decides to curb development further: if there are less users to support, the teams assigned to that project can be rotated to work for some other project that needs attention.

The product thus suffers from pure neglect. Middle-managers direct their workforce to stop working on 'feature requests' or even 'minor issues' ('minor' as viewed by the middle-managers, of course; the upper management cannot tell the difference anyway). The focus remains on supporting the dwindling userbase with the remaining resources.

Needless to say, this only leads to more users getting upset, and, even though their number is shrinking, the number of their complaints is not. After all, it's reasonable to assume that whoever has committed to the Atlassian ecosystem will know how to file tickets on Jira, right?

So, the cycle continues: the product gets less and less users, and the dev team does less and less to maintain it, which means that the team gets less and less resources to support the product, which, in turn, leads to a loss of users... and the cycle repeats ad nauseam. Well, not quite: it comes to a point where there are so few users left — no matter if they are still Big Corp customers, strongly attached to the Atlassian ecosystem — that the upper management gets pressured to give up on the product. All they need is a simple pretext — like the need to get lots of developers working on 'the new shiny project', and, instead of hiring more people, it's far better just to move the existing teams out of a 'dying product', shut it down, and get those precious devs into 'the new shiny project'.

That way, everybody is happy. Middle-managers have successfully killed off a 'product which users didn't use any more' and was thus a burden to the whole company — financially and otherwise. Devs are happy, since they get to work on 'the new shiny project' instead of dealing with a ancient, legacy software, which was impossible to maintain with the shrinking resources they got — and they were often blamed for not doing their work properly. Now, as part of 'the new shiny project', they will not be the company pariahs any longer (those that work on a product that only has complaints from suers). The upper management is happy, because they dumped an old, unwieldy, expensive product which was 'only maintained for the sake of a handful of faithful corporate users', and will look great at the next stakeholder meeting when they present 'the new shiny project' and explain how it won't cost the company that much money, since they have already dumped 'several products that weren't financially interesting' and 'reassigned their workforce to the more lucrative areas of the business'. Finally, stakeholders are happy, because the upper management seems to be handling very well the company, bringing costs down and profits up, making (possibly) unpopular decisions for some, sure, but, in the end, what matters is what the quarterly reports say, and how the upper management had no fear to face 'issues' and 'deal with them appropriately'.

I know, a long story. It might not even be true in the case of Bitbucket. But it has been true in lots of companies, and obviously not only in the tech industry. It's an extremely effective way of dumping a product (for whatever reason — often, they're very petty, irrational ones) and 'making everybody happy', without the need to 'shift the blame' to anyone inside the company (from the very top to the bottom), and presenting a positive image to the public-at-large (especially, of course, those who are buying shares on the stock market).

What is utterly ridiculous is that there are plenty of self-hosted open-source Git repositories out there (Gogs and its even more successful fork, Gitea, come to mind — but there are plenty of others). Atlassian could just grab one of them and wrap their corporate logos around it. I mean, they could make the switch overnight, and nobody would even notice (Git is git, right?) — except perhaps for some users who were checking the replies from the remote servers on the wire and noticed a difference there. Some users might even commend Atlassian for 'the incredible update they made, fixing a lot of open issues'. Indeed, a lot of issues posted here on Bitbucket's Jira have been dealt with even by open-source projects — not just GitHub and GitLab! — perhaps a decade ago.

That is the kind of choice that, unfortunately, companies very, very rarely make.

But there are exceptions. IBM (aye, the giant IBM) did that, 20+ years ago, when they clearly saw that it was pointless to compete in the market segment of operating systems for servers with Intel/AMD CPUs. They were just losing money to their competitors — who would be offering Linux for free, which was so much better than anything that IBM could offer at that time (and certainly not for that price!). So, IBM became a Linux company. They didn't regret it for a second.

Apple was also losing the operating system battle on the desktop (and on the early laptops). It's true that they weren't to be fully blamed — Motorola simply couldn't deliver the kind of chips that Apple wished — but, ultimately, they had to give up on their operating system and pick up a variant of BSD Unix that Steve Jobs had been tinkering with on his NeXT workstations. Today, one billion devices are running a variant of BSD Unix — on their owners' pockets! — while further two billion run a variant of Linux. I'm pretty sure that neither Apple, nor Google (or Samsung, Huawei, Xiaomi...) have regretted that choice.

I'm even quite interested to see what Larry Ellison is going to do with MySQL. At some point in the past, before MySQL was acquired by Oracle, there was a market segment which used to be 100% Oracle a few decades earlier ('Oracle, the relational database server that would run under 27 different platforms and operating systems'), but which MySQL (and, to a degree, PostgreSQL) had completely taken over, with no chance for Oracle's very pricey 'low level edition'. SQLite even went further, bringing the notion of 'embedded databases' to software developers (today, thanks to mobile phones, SQLite is the most used relational database ever — MySQL comes in second place — while Oracle probably doesn't even appear on any such list). It became clear, even for Larry's ego, that there was a better product directly competing with them, which they could never overthrow. So they bought it. Simple solution. We all expected that Oracle did to MySQL what they usually do with their acquisitions, which is to destroy them forever, lest they interfere with Oracle's own solutions. That did not happen. And even Oracle seems to be reconsidering their usual all-problems-are-nails-and-we-have-a-hammer stance: when they bought DynDNS — the guys who invented dynamic DNS — some years ago, they were quick to state that the product would be 'phased out'. That would be completely consistent with the hack'n'slash approach that Oracle used. However, there was a huge number of complaints about decade-old customers of DynDNS, and, strangely enough, Oracle listened to them, and suspended their decision of shutting the service down (even the free one!). I'm still using it every day with my so-called VIP account — granted as a lifetime account for those who, in the very early days of DynDNS, became their supporters and first customers.

And Microsoft? Not only did they fully commit to keep GitHub alive, and getting improvements and features all the time, but we all know what Bill Gates thought about Linux when he was CEO — and see how successfully Microsoft has embraced not only Linux (their fantastic compiler generates rather good native code — and in a fraction of time, too — which ought to make Gates proud, since he started his business by writing compilers, back when personal computers with 64K were a luxury), but a lot of other services and products (think Xamarin!), especially on those areas where they had weaker products, or no real offerings at all.

So... even the industry giants with their massive legacy and astronomical user base have learned the lessons, at least to a degree. Why doesn't Atlassian do the same? They stand — literally — on the shoulders of giants. Giants who were humble enough to admit that they were wrong here and there, and do a 180º turn on their previous dominant corporate stance. The result was happier users, new users (many who would never think of writing a single positive word about those megacorps!), and with that, rising prices on the shares, more profits, more margin to deal with long-standing issues and offering more solutions.

Unless, of course, they were planning to sell Bitbucket to Microsoft some years ago... which surely must have been greeted with an explosion of laughter from Microsoft's CEOs, who turned their backs and went on to buy GitHub instead.

Well, Atlassian, don't expect anybody else to come around and buy you guys. Especially not Bitbucket; nobody wants to buy an inferior product with an angry customer base, with lots of unfixed issues that have been neglected for over a decade. Either fight back and revamp Bitbucket — you know you can do it! — or replace Bitbucket by an open-source solution (while keeping the interface and the integration with Atlassian's ecosystem) and move on as a serious contender in the Git repo business, or...

... or, well, simply shut Bitbucket down. Give us fair advance and a migration path. That would be perfectly legitimate and acceptable, even for those die-hard Atlassian fans out there, imposing your ecosystem above everything else in their own companies.

Which would, at the very least, give your end-users some relief of their anxiety. Do something good for a change. You'll see that, at the end, you will benefit as well.

Well, now, I'm 3 jobs later and the current one fortunately uses GitHub Enterprise, and Jira Server.

There's a big brew-haha right now, because this corp was forced onto Jira Cloud (due to Jira Server, and all server products, being EOL'd). They wanted to move us off of GHE self-hosted to Bitbucket Cloud.

Oh my goodness! The reactions of the dev teams were swift and furious, including from me. Many of us unofficially threatened to quit if moved from GHE to Bitbucket Cloud. The decision came down less than 2 hours after the BB Cloud annoucement: We're moving to GitHub.com.

Everyone rejoiced! Now we won't need a VPN to connect to GitHub and our daily work will show up in the GitHub.com stats page

I've personally decided to unfollow this topic and wait for Atlassian to shrink even further.

No one uses Bitbucket unless they have to. 

Same on this end. Not just this feature here that is missing, but continuous disinterest in the user/customer-base is the reason we will switch to something else...

Same here. I've followed it for at least 2 years, we're in the middle of a GH migration and I'm unfollowing this issue. 👋

Un-following this issue:

• I started following 3 years ago
• The company I worked at that used BB has now migrated to GH end of last year
• I no longer work there anyways.

Honestly, this feels a lot like HipChat....just sell your user base to GL/GH and get out of this market segment that Atlassian clearly doesn't want to be in.

+1

+1 to @Greg Markey comment. We migrated to GitLab several years ago.

When Atlassian adds git commit signing, then please don't forget https://jira.atlassian.com/browse/BCLOUD-11404 and add release notes and artifacts to git tags as well. Another feature already present at GitHub for ages.

+1 to @Matheus Amazonas comment.

Did the same and don't look back. The last legacy Bitbucket projects will be moved soon.

GitHub integration is good enough and works quite well. At least this way you get a state of the art Git with tons of integration and tools. Tried Sourcetree yesterday. Deinstalled it 5 minutes later for not being able to show my repository list on Github. Not sure what Atlassian is thinking. ¯_(ツ)_/¯

As someone who has been following this issue for over a year now, my team officially gave up and we're switching to GitHub. To our use case, GH is as expensive as BB and it's heaps ahead, feature-wise.

BitBucket is a budget GIT platform that lacks any decent usability, features, or compelling use case.  5 years ago after Microsoft Team Foundation corrupted our project, we moved to Bitbucket simply because we were Atlassian customers, and if that's the ONLY reason we still use BitBucket. 

BitBucket's only appeal, is that it's a product under the Atlassian umbrella, and if you use Jira or Confluence it might be easier to use it than picking up GitLab, or rolling your own.  The other reality is that the vast majority of developers and “technically” minded people don't know anything about GIT other than you can do a “commit”, “push” or “pull”.   Which equates to them thinking all GIT platforms are the same, and those other platforms such as GitLab are just overpriced voodoo.

Essentially, Atlassian has capitalized on stupidity, incompetence, and laziness.

+1 to @Greg Markey comments.

Is Bitbucket a hobby for Atlassian, or a product? For git related tech out there, Bitbucket is the furthest behind the curve when compared to competitors. What you gain in discounts and overall affordability, you lose in time due to lacking basic features.

This is honestly pathetic and I get a real sense of "do as we say, not as we do" from this company in every single product.

Has anyone figured out a workaround for preventing Bitbucket from stripping the signature on PR merge?

Given this affects security and not just "nice to have" functionality, this might finally be the impetus I need to lift & shift the rest of our stuff to Gitlab.

I doubt it, and I'd personally be -1 on that.  Sigstore seems to use a third-party root of trust (i.e. a model of implicit trust, like a browser), which means you're just punting your security decisions onto a third-party.  

Perhaps I'm wrong about the model, but it seems like more security theatre. 

Will this also support https://www.sigstore.dev/ as well as the standard GPG signing?

Adding some fuel

Github now supports commits verification with SSH 

https://github.blog/changelog/2022-08-23-ssh-commit-verification-now-supported/

1c505570e116 is the hero

facing the death for us... thx

In theory the commit validation is pretty easy:

1. First you need gpg on the git server and the public key of each git user.
2. When a new commit arrives, pick up the commit ID -> git log --max-count 1
3. Then run the validation: git verify-commit <commit-id>

See also: https://git-scm.com/docs/git-verify-commit

IMO the bigger effort is to update the Bitbucket UI with:

• User account setting: allow upload the public gpg key
• Repo settings: set up requirements for commit signing (reject push, reject merge, etc)

But this is no rocket science.

That's great news, but based on this issue's history, I'm skeptical. I'll believe it when I see it. 😛

Wow! It's in progress and with actual timeline when it would be ready!

Seems like the 10th year is slightly overdue by 262 days.

Just three more months for the Atlassian developers to win my $2,000 Ethereum challange!

Per my comment on 30 August 2021:

$2,000 in Ethereum (as valued at the time) will be donated to The World Reader Foundation if Atlassian's Bitbucket developers implement GPG commit signing before the 10 year anniversary of this feature request: 11 October 2021.

That's 97 days, bois...

Just started using the Cloud Edition and that surprises me a LOT!!!

And looks like there is not even an ETA or something....

Sad, but true!

I just create my account and a few minutes later I stuck here. I'm very surprised about this.

Looks the stuff is on the road map as "Future, 2022", but no exact release date is available.

-> https://www.atlassian.com/roadmap/cloud?selectedProduct=bitbucket