In addition, we will stop distributing the sources as part of future product releases of these repositories as well as atlassian-oauth.
Why are we doing this?
We have identified these repositories as containing security-critical code. When identifying vulnerabilities for these repositories and fixing them, information about the vulnerabilities would be publicly available through the repositories before our customers have had a chance to upgrade their product instances with fixes to these security vulnerabilities. By keeping information about the exact vulnerabilities and fixes private until customers have upgraded their instances to be safe again, we significantly reduce the risk of these vulnerabilities being exploited on our customers’ instances.
Will other repositories remain publicly accessible?
For the time being, we will limit this security measure to the four repositories mentioned in this post. We are conscious that our documentation is not where we would like it to be, and that many of you rely on access to the source code to discover information on how to build your apps. Limiting access to these four repositories has limited impact on your ability to understand our sources, while covering the majority of our security critical code.
Out of curiosity, why does Atlassian think this is a valid approach given that there are many open source projects available that have security vulnerabilities but not restrict code access?
40% of the internet operates on Wordpress. Their code is public. Their users/customers do not always upgrade to the latest & greatest.
Imagine Wordpress going private citing this as a reason:
By keeping information about the exact vulnerabilities and fixes private until customers have upgraded their instances to be safe again, we significantly reduce the risk of these vulnerabilities being exploited on our customers’ instances.
They would be (rightfully) ridiculed. What is preventing us to ridicule Atlassian?
@TomRijnbeek is just the source repository being made private? Can we still access current and future releases of atlassian-jwt via a Maven repository?
Limiting access to these four repositories has limited impact on your ability to understand our sources, while covering the majority of our security critical code.
Will these sources be readily available on request like the product sources? Which support portal is appropriate for requesting sources for these repositories?
@remie I understand your sentiment. I don’t think your comparison with Wordpress holds up entirely here. Our goal and primary motivation isn’t to achieve through security through obscurity by hiding the source code, but it is to allow us to work on mitigating vulnerabilities - especially those that may not yet have been discovered in the public domain - without further details leaking out, accelerating active exploitation. In the past we have seen instructions appear online to actively exploit vulnerabilities while we were still working on solving them and rolling out the fixes. We have no problem sharing source of the repositories - and the process for requesting access will remain in place and expand to cover these repositories - but we don’t have a good way currently to get both the benefits of keeping active security mitigation work under wraps while maintaining the level of openness on the source we’ve had so far. Limiting this restriction in visibility to just these repositories strikes the balance between reducing risk while keeping the majority of the source easily accessible as it is today.
@BenRomberg The binaries will be copied into a publicly accessible Maven repository at the time that we release a product version containing that particular binary version. The sources will not be included.
@EliasBrattliSorensen Yes you will be able to access the source in the same manner as product sources. I am not up-to-date with what the exact process for that is right now, so let me follow up with the team internally to get you a better answer.
This would also apply to the Wordpress example, right?
Is there a reason why such development cannot be done in private forks? There has also been previous examples of Atlassian mirroring repositories. Surely this can be resolved in a way that does not include removing open source access to these packages.
There is an entire open source industry that has solved this problem already.
If Wordpress isn’t a good example, then how about OpenSSL?
Like Wordpress, OpenSSL is used at huge scale globally, and arguably one of the most security-critical pieces of infrastructure we have, yet they don’t see the need to hide their source code.
A combination of responsible disclosure of vulnerabilities and internal investigation & patching is the solution here.
Moving publicly available source behind an “available-on-request” model isn’t the answer.
We have been running our own Connect implementation for years, including our own atlassian-jwt implementation. Our own atlassian-jwt code heavily relies on Atlassian’s reference implementation. No longer having a reference means we are on our own and must rely on public announcements to patch our code. This sounds counter-productive to what I believe Atlassian is trying to achieve here.
More broadly, the Atlassian argument made in this post holds for any other repo that contains framework/platform code published by Atlassian. I don’t see how a security issue in ACSB or ACE is less security-critical than an issue in atlassian-jwt.
Making one repo at a time closed source is a brute-force method, which kills collaboration, contribution, and transparency. We often study the Atlassian code we rely on to deeply understand the API we are dealing with. Documentation is more often than not outdated, incorrect, or incomplete (a recent example). So, not having access to code ultimately means we must make assumptions that will likely lead to security issues.
I would like to encourage Atlassian to rethink the strategy of making more and more repositories closed source to improve security, engage more actively in collaboration, and be open to contributions. The current strategy is not solving the problem, it is just pushing it one level higher.
Any attacker capable of exploiting the vulnerabilities is also capable of decompiling the JAR files you roll out to customers to fix said vulnerabilities. Making the code private doesn’t exactly prevent them from building an exploit.
To follow up on the question about sources being made available. You can go through the usual support process over at Atlassian Support. The support folks know how to handle these requests.
As for the remaining comments, I won’t respond to each of them individually. We are fully aware how important access to our source code is for you all to develop your apps, which is why we are currently not planning on making any other component closed source.
I agree with others in the thread; this does not help mitigate anything in the future.
Soon after a (library) release, people will download the binaries, throw them into Fernflower, and diff the results.
You don’t need to be an expert to do that. Fernflower is pretty great at decompiling—I know that because we do it way more since getting sources is much more complicated than before.
Since a library release happens before you release the app, people will have access to it anyway. Even if you keep anything private until the app is released, that does not change much.
Between the public release and people getting a maintenance window to update, you have plenty of time to do what I have described before and use the vulnerability.
Thus, please reconsider this change. This will not change much, but it will make our lives harder.
You can have a private fork, and push to the public git after the app release, etc.
