# Restricting source access to atlassian-jwt, atlassian-security, and atlassian-seraph (DC) **URL:** \ **Category:** Announcements\ **Tags:** data-center\ **Created:** [November 20, 2024, 1:23pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409 "2024-11-20T13:23:56Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![TomRijnbeek](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/tomrijnbeek/32/50268_2.png) [@TomRijnbeek](https://community.developer.atlassian.com/u/TomRijnbeek)\ **Post date:** [November 20, 2024, 1:23pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/1 "2024-11-20T13:23:56Z")
Hey developer community. On Monday 25 November, we will be changing the access to the following Atlassian repositories to private: - [https://bitbucket.org/atlassian/atlassian-jwt](https://bitbucket.org/atlassian/atlassian-jwt) - [https://bitbucket.org/atlassian/atlassian-seraph](https://bitbucket.org/atlassian/atlassian-seraph) - [https://bitbucket.org/atlassian/atlassian-security](https://bitbucket.org/atlassian/atlassian-security) 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. ---
**Author:** ![remie](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/remie/32/34985_2.png) [@remie](https://community.developer.atlassian.com/u/remie)\ **Post date:** [November 20, 2024, 1:51pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/2 "2024-11-20T13:51:38Z")
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? ---
**Author:** ![BenRomberg](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/benromberg/32/51777_2.png) [@BenRomberg](https://community.developer.atlassian.com/u/BenRomberg)\ **Post date:** [November 20, 2024, 1:57pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/3 "2024-11-20T13:57:13Z")
@TomRijnbeek is just the source repository being made private? Can we still access current and future releases of `atlassian-jwt` via a Maven repository? ---
**Author:** ![EliasBrattliSorensen](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/eliasbrattlisorensen/32/41934_2.png) [@EliasBrattliSorensen](https://community.developer.atlassian.com/u/EliasBrattliSorensen)\ **Post date:** [November 20, 2024, 2:01pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/4 "2024-11-20T14:01:55Z")
> 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? ---
**Author:** ![TomRijnbeek](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/tomrijnbeek/32/50268_2.png) [@TomRijnbeek](https://community.developer.atlassian.com/u/TomRijnbeek)\ **Post date:** [November 20, 2024, 2:50pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/5 "2024-11-20T14:50:39Z")
@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. ---
**Author:** ![PaoloMariottiACE](https://avatars.discourse-cdn.com/v4/letter/p/ac8455/32.png) [@PaoloMariottiACE](https://community.developer.atlassian.com/u/PaoloMariottiACE)\ **Post date:** [November 20, 2024, 3:12pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/6 "2024-11-20T15:12:39Z")
can’t you just develop fixes in a private fork? …a malicious user might not need public sources ---
**Author:** ![MarkusSutterMibexSof](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/markussuttermibexsof/32/52579_2.png) [@MarkusSutterMibexSof](https://community.developer.atlassian.com/u/MarkusSutterMibexSof)\ **Post date:** [November 20, 2024, 3:14pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/7 "2024-11-20T15:14:40Z")
> Limiting access to these four repositories… What is the forth? I see only three listed in your post. 🤔 Solved: the 4th is probably atlassian-oauth, for which sources are not part of future product releases. ---
**Author:** ![remie](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/remie/32/34985_2.png) [@remie](https://community.developer.atlassian.com/u/remie)\ **Post date:** [November 20, 2024, 4:02pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/8 "2024-11-20T16:02:28Z")
> [@TomRijnbeek](#): > > I don’t think your comparison with Wordpress holds up entirely here. Why not? > [@TomRijnbeek](#): > > 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 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. ---
**Author:** ![scottohara](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/scottohara/32/52316_2.png) [@scottohara](https://community.developer.atlassian.com/u/scottohara)\ **Post date:** [November 20, 2024, 10:23pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/9 "2024-11-20T22:23:28Z")
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. ---
**Author:** ![tbinna](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/tbinna/32/35870_2.png) [@tbinna](https://community.developer.atlassian.com/u/tbinna)\ **Post date:** [November 21, 2024, 2:30am UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/10 "2024-11-21T02:30:11Z")
I agree with the sentiment of others here. 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](https://community.developer.atlassian.com/t/challanges-when-implementing-graphql-client-for-forge-storage-api-in-forge-remote/86277)). 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.** ---
**Author:** ![t.rieder](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/t.rieder/32/36714_2.png) [@t.rieder](https://community.developer.atlassian.com/u/t.rieder)\ **Post date:** [November 21, 2024, 3:44pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/11 "2024-11-21T15:44:28Z")
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. ---
**Author:** ![TomRijnbeek](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/tomrijnbeek/32/50268_2.png) [@TomRijnbeek](https://community.developer.atlassian.com/u/TomRijnbeek)\ **Post date:** [November 22, 2024, 5:08pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/12 "2024-11-22T17:08:52Z")
To follow up on the question about sources being made available. You can go through the usual support process over at [Atlassian Support](https://support.atlassian.com/contact/). 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. ---
**Author:** ![remie](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/remie/32/34985_2.png) [@remie](https://community.developer.atlassian.com/u/remie)\ **Post date:** [November 22, 2024, 6:06pm UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/13 "2024-11-22T18:06:51Z")
> [@TomRijnbeek](#): > > 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. Ok, so the official Atlassian policy is Sois belle et tais-toi, and be happy we limited ourselves (for now). Fine. ~~Can I speak to the manager please?~~ Let’s see what the public opinion is about this issue > **[Remie Bolte on LinkedIn: Restricting source access to atlassian-jwt,...](https://www.linkedin.com/posts/remiebolte_restricting-source-access-to-atlassian-jwt-activity-7266047450921021440-cwb3)** > > Did you know that Atlassian really loves security through obscurity? 🫠 > > Atlassian has announced that they are removing public access to several repositories… ---
**Author:** ![chrschommer](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/chrschommer/32/48326_2.png) [@chrschommer](https://community.developer.atlassian.com/u/chrschommer)\ **Post date:** [November 25, 2024, 7:22am UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/14 "2024-11-25T07:22:45Z")
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. ---
**Author:** ![aorlov](https://avatars.discourse-cdn.com/v4/letter/a/7c8e57/32.png) [@aorlov](https://community.developer.atlassian.com/u/aorlov)\ **Post date:** [December 19, 2024, 11:58am UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/15 "2024-12-19T11:58:59Z")
Our real problems after this restriction. We updated `jwt-core`/`jwt-api` from 3.3.3 to 4.0.3: 1. Version 4.0 supports only java 17+ (we knew from javac) 2. Our apps started to **fail at runtime** (not compile time), because some dependencies changed their scope: - `commons-codec:commons-codec` has `compile`-scope in 3.3.3 and became `provided` in 4.0.3 - `net.minidev:json-smart` has `compile`-scope in 3.3.3 and became `provided` in 4.0.3 The main question for Atlassian is: **How can we safely update these libraries?** Alternatives: 1. Will Atlassian provide public release notes for vendors somehow? 2. Will be these changes (changing the scope) described in these release notes? 3. Will Atlassian provide the source code and Git-history? We can’t see the changes between versions without commit history. We requested the source code for Bitbucket, Jira and Confluence, but it was without Git-history. This restriction has really big impact :(, we can’t be sure about stability. **And one question for 3rd Atlassian vendors.** **How do you solve these problems?** Kind regards ---
**Author:** ![system](https://global.discourse-cdn.com/atlassiandeveloper/original/3X/7/8/78672baa5ba80cd9164376457051d0eec038b082.png) [@system](https://community.developer.atlassian.com/u/system)\ **Post date:** [January 18, 2025, 11:59am UTC](https://community.developer.atlassian.com/t/restricting-source-access-to-atlassian-jwt-atlassian-security-and-atlassian-seraph-dc/86409/16 "2025-01-18T11:59:39Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.