Upcoming security uplift for all Server and Data Center products

Hi developer community,

At Atlassian we’ve always taken the security of our Server and Data Center products seriously. Our vulnerability management program uses an array of approaches for finding and fixing security issues, including a top tier bug bounty program. While we have invested in security and keeping third party code up to date, we are doubling down in this space as security attacks become more common and more sophisticated.

With improved tools and processes in place, we are increasing our coverage to meet the security demands that are critical to our customers. The focus of this effort is to identify and fix vulnerabilities in third party code bundled with our products. This includes fixing vulnerabilities in unreachable third party code.

To best address this, we will be identifying and upgrading our products core components and libraries to the newest versions. We will not break our official APIs, however, certain libraries, transitive dependencies, internal implementation, and behaviours might change. We want to inform you regarding these plans because there might be some impact on your apps and customers that we are not able to anticipate.

In the coming months we will be informing you of these changes via the existing release processes for Atlassian’s self-managed products:

  • For Jira Server and Data Center: we will posting the necessary information in the EAPs we publish with each release. Please look for Upgraded dependencies and libraries section for detailed list of changes.
  • For Confluence Server and Data Center: the information will be listed in the EAPs documentation as well.
  • For Crowd, Bitbucket, Bamboo and other self-managed products: the information will be shared at a later date.

If you have any questions or feedback for us, please leave us a comment under this post.

Thank you.
Grażyna Kaszkur
Product Manager, Server and Data Center

15 Likes

I am personally super-happy that libraries be upgraded. It may mean we might split bugfixes/improvements, and only publish improvements for the recent versions of Confluence, which isn’t as nice for customers (who already struggle upgrading Confluence to enterprise releases every 2 years). But this is better for the security.

Thank you for the heads up!

Does Atlassian have plans to extend mandatory bug bounties (BugCrowd) for Data Center apps?

1 Like

It’s something we are exploring at the moment. We ran a small pilot with a few DC vendors last year to understand how this could work. We have not settled on an approach yet.

Feel free to ping me if you have any specific thoughts on this topic. Would love your perspective.

2 Likes

That was one of the reasons because we released a new framework able to isolate apps from many Atlassian’s changes in the platform and bring more stability to Data Center and the apps.

I.e: our framework makes plugins independent of the the Atlassian’s third party libraries because the system bundle is replaced and Atlassian’s third party libraries are not brought into vendors’ plugins

It was rejected for DC by the approval team due its endless capabilities. Fortunately, it has got a second chance and its under review again. But I’m afraid this is the last shoot.

Someone at Atlassian should SERIOULSY care about this and avoid that fearful software engineers prejudicing customers and vendors with misunderstanding decisions.

Your announcement is one more argument to approve it.

Sharing libs is caring.

It depends on the size. A plugin of 4MB is easy to approve, but we constantly have problems with Apache POI at 15MB, for example uploads get cut on any sane NGINX or Apache. Also, adding libraries upon libraries and having Tomcat run 500MB to 1GB of code feels insane to me.

Embedding the entire library system repeatedly in each plugin will probably slow down the customer experience and participate to the image that the products are slow. I hope Atlassian safegates the performance, indeed, especially if they don’t forget to make it easy enough for us to build different .jars for different product versions with different OSGi imports.

Talking about shared libraries, should core products expose Apache POI’s APIs to build Excel/Word files? It’s a big lib, would be nicer if it were shared.

2 Likes

Hey there,

In the coming months we will be informing you of these changes via the existing release processes for Atlassian’s self-managed products

is there a more precise roadmap for these changes? In case of Confluence: will this be part of the next release (7.12) or the upcoming LTS / the last Server version (probably 7.13)?

Cheers paul

Thank you @pablo your comment. As I am not taking part directly in the DC apps certification process and don’t have the detailed knowledge about the app you are referring to, therefore please ping @bmagro for details.
I can only assure you, that by such announcements like this one we are trying to stay open and inform you upfront of the changes coming and the reasoning behind them. If you have any suggestions how we could improve this process, please let us know.

1 Like

is there a more precise roadmap for these changes? In case of Confluence: will this be part of the next release (7.12) or the upcoming LTS / the last Server version (probably 7.13)?

@ppasler thank you for your question, I’ll check with the Confluence team and will get back to you with more details.

First, to clarify some confusion here: there is no “last Server version”. Customers will be free to upgrade to newer releases while their license allows for it, so they will be able to upgrade to all Confluence 7.x and 8.x versions until their maintenance license runs out.

As for when the security uplift upgrades will land, they will ship as they’re ready, in 7.12.0, 7.12.x bugfix releases, 7.13.0, 7.13.x bugfix releases, 7.14.0 and 7.15.0. Given that 7.13.x will be LTS, we’ll regularly be backporting important library upgrades to that branch as well, just as we’re already backporting certain upgrades for 6.13 LTS and 7.4 LTS. We’ll ensure that we provide information of the “Preparing for Confluence x.x” pages for 7.13+ around which libraries are upgraded, when that might cause any compatibility issues, and we’ll refresh the information for 7.12 so that you’re not in the dark about what changed for that release too. For any changes that might require any extra effort on your part, we’ll ensure that’s highlighted in a specific item on the preparing pages.

We’re much more cautious about the upgrades that land in bugfix releases, and LTS bugfix releases more-so, so those specific updates will be much lower risk to you and our customers. Sadly, these LTS bugfix releases won’t have any preparing pages to work from, but you’ll be able to review the list of updated libraries in the release notes for these LTS bugfix releases as they come out too.

2 Likes

they will ship as they’re ready, in 7.12.0, 7.12.x bugfix releases, 7.13.0, 7.13.x bugfix releases

If I understand correctly, honestly, as a developer, it is much easier if you mass-upgrade all libraries in the same 7.13.0 release, otherwise 7.13.1 will have different libs and will technically be a major version for us (I’m ok with 2 release streams “before 7.13 and after 7.13”, maybe we can even keep publishing our features on those 2 streams, but having n release streams is harder).

I’m sure you’ve weighed the pro/cons, I just want to encourage your developers.

Time for a bold move, Atlassian hero developers :wink: We’ll all suffer, I’d rather suffer once.

PS: Hello Mr. Atkins! We’re in good hands here, technically-wise :wink:

Thanks for the answer and the clarification. I thought there will be a “last server version”, which will be LTS and supported until the last server licenses are valid (~ Feb 2024).
I am looking forward to the dependency upgrades and hope they won’t break too much. Backporting is very important for us, as we want to be compatible with all supported Confluence versions.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.