community.developer.atlassian.com Open in urlscan Pro
2602:fd3f:3:ff01::2b  Public Scan

Form analysis
1 forms found in the DOM

POST /login

<form id="hidden-login-form" method="post" action="/login" style="display: none;">
  <input name="username" type="text" id="signin_username">
  <input name="password" type="password" id="signin_password">
  <input name="redirect" type="hidden">
  <input type="submit" id="signin-button" value="Log In">
</form>

Text Content

Skip to main content

 * Documentation

Log In
 * 
 * 
   


Atlas Camp is heading to Brussels, Belgium on 3-7 February. Secure your spot
today!




RESTRICTING SOURCE ACCESS TO ATLASSIAN-JWT, ATLASSIAN-SECURITY, AND
ATLASSIAN-SERAPH (DC)

Announcements
data-center

You have selected 0 posts.

select all

cancel selecting

604 views 65 likes 5 links 11 users
3
3



read 4 min

Nov 20
1 / 15
Nov 21

1d ago


TomRijnbeekAtlassian Staff
Nov 20


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-seraph
 * 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.





604 views 65 likes 5 links 11 users
3
3



read 4 min

remieMarketplace Partner
Nov 20


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?

18


BenRombergMarketplace Partner
Nov 20


@TomRijnbeek is just the source repository being made private? Can we still
access current and future releases of atlassian-jwt via a Maven repository?

1


EliasBrattliSorensenMarketplace Partner
Nov 20


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

1 Reply
7


TomRijnbeekAtlassian Staff
Nov 20


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

1 Reply
3


PaoloMariottiACE
Nov 20


can’t you just develop fixes in a private fork? …a malicious user might not need
public sources

5


MarkusSutterMibexSof
Nov 20


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

1


remieMarketplace Partner
Nov 20


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.

3


scottoharaMarketplace Partner
Nov 20


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.

5


tbinnaMarketplace Partner
30d


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

12


t.rieder
29d


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.

6


TomRijnbeekAtlassian Staff
1
EliasBrattliSorensen
28d


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.




remieMarketplace Partner
1
28d


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

linkedin.com


REMIE BOLTE ON LINKEDIN: RESTRICTING SOURCE ACCESS TO ATLASSIAN-JWT,...

Did you know that Atlassian really loves security through obscurity? 🫠
Atlassian has announced that they are removing public access to several
repositories…






chrschommerMarketplace Partner
26d


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.

3


24 days later
aorlov
1d


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

1






THIS TOPIC WILL CLOSE A MONTH AFTER THE LAST REPLY.


Reply



NEW & UNREAD TOPICS

Topic list, column headers with buttons are sortable. Topic Replies Views
Activity Improved security and usability: 2025 Data Center product updates
Announcements
jira-data-centerconfluence-data-centerdata-center
15 577 4d Calling all devs to our biggest Atlas Camp yet!
Announcements
forgeevent-listenerdeveloper-eventatlas-camp-2025
2 116 18d Bitbucket Data Center 9.4 Long Term Support release is here!
Announcements
bitbucket-data-center
6 93 10d Jira Software and Jira Service Management Data Center 10.3 Long Term
Support are here!
Announcements
3 146 4d Important Atlas Camp milestones
Announcements
eventsforge-eventsevent-listenerdeveloper-eventatlas-camp-2025
4 138 4d


WANT TO READ MORE? BROWSE OTHER TOPICS IN ANNOUNCEMENTS OR VIEW LATEST TOPICS.




 * System status
 * Privacy
 * Notice at Collection
 * Developer Terms
 * Trademark
 * Cookie preferences
 * © 2024 Atlassian




Invalid date Invalid date








MANAGE PREFERENCES

When you visit any website, it may store or retrieve information on your
browser, mostly in the form of cookies. This information might be about you,
your preferences or your device and is mostly used to make the site work as you
expect it to. The information does not usually directly identify you, but it can
give you a more personalized web experience. Because we respect your right to
privacy, you can choose not to allow some types of cookies. Click on the
different category headings to find out more and change our default settings.
However, blocking some types of cookies may impact your experience of the site
and the services we are able to offer.
More information
Accept all

STRICTLY NECESSARY COOKIES

Always Active

These cookies are necessary for the website to function and cannot be switched
off in our systems. They are usually only set in response to actions made by you
which amount to a request for services, such as setting your privacy
preferences, logging in or filling in forms. You can set your browser to block
or alert you about these cookies, but some parts of the site will not then work.
These cookies do not store any personally identifiable information.

TARGETING COOKIES

Always Active

These cookies may be set through our site by our advertising partners. They may
be used by those companies to build a profile of your interests and show you
relevant adverts on other sites. They are based on uniquely identifying your
browser and internet device. If you do not allow these cookies, you will
experience less targeted advertising.

FUNCTIONAL COOKIES

Always Active

These cookies enable the website to provide enhanced functionality and
personalisation. They may be set by us or by third party providers whose
services we have added to our pages. If you do not allow these cookies then some
or all of these services may not function properly.

PERFORMANCE COOKIES

Always Active

These cookies allow us to count visits and traffic sources so we can measure and
improve the performance of our site. They help us to know which pages are the
most and least popular and see how visitors move around the site. If you do not
allow these cookies we will not know when you have visited our site, and will
not be able to monitor its performance.

Back Button


COOKIE LIST



Search Icon
Filter Icon

Clear
checkbox label label
Apply Cancel
Consent Leg.Interest
checkbox label label
checkbox label label
checkbox label label

Reject all Confirm my choices