Most organizations of significant size require a rollback plan as part of standard change management procedures. This type of change makes rollback extremely difficult. How will Atlassian be able to accommodate these customers?
Customers need to be able to install downgrades of existing, published apps.
Vendors also need some way to ship testing versions of apps to customers. If all of this needs to go through a MPAC website to act as a security gatekeeper, fine. That way, Atlassian can still “pull the plug” if a specific artifact URL is being used as part of an active exploit, and I would hope it meets your security requirements.
For a trip down memory lane, there were 65 votes for the inverse of this change back in 2011…today’s equivalent would have to be 10X or 100X the number of votes, given the growth in customer base.
@CharafEddineSAIDI adding to what others already voiced:
Besides public Marketplace apps, we at Communardo also do customer-individual (bespoke), private apps, i.e. not uploaded to Marketplace but installed directly by uploading a JAR/OBR file to Confluence or Jira. I’d say we have about 50 – 100 customers like that. ALL of them will have to re-enable this manual upload feature as soon as they upgrade to an affected product version. All of them.
And, depending on their degree of systems automation, they may have to repeat this for each future upgrade if they set this in the setenv file, because that file is overwritten during product upgrades
Similar to others I question the benefit of this, see this as a kind of breaking change, and predict unhappy/puzzled customers.
Thank you for your comment. It has effectively captured the key points regarding UPM changes.
To clarify, we have not removed the upload feature from UPM. It has just been disabled by default. From a security perspective, this helps reduce our attack surface, as uploads are not required to be activated on every DC instance. We acknowledge that this is not practical for instances relying on custom or private plugins. However, impacted customers can still install private Apps by re-enabling the upload feature or through the file system.
We are already studying different approaches to introduce App signing and an RFC should be published in the upcoming days/weeks. This is a long term solution and will require coordinated efforts from Atlassian, App vendors, and customers. We will take a phased approach to introduce app signing gradually while considering several requirements, such as backward compatibility, certificats management or air-gapped instances. After receiving the feedback on RFC, we believe that the app signing project will span over multiple months and will require multiple updates before reaching its final version. However, the first releases should already mitigate the identified risks related to uploads. I agree that this will make UPM restrictions ineffective as only the installation of signed apps will be allowed. After deploying app signing, we may reconsider restrictions on uploads or provide new means to upload apps without affecting our attack surface.
I understand the inconvenience caused by the short notice. It didn’t help you prepare for these changes in UPM. We needed to implement and provide our customers with this feature as fast as possible. This was identified as a security requirement. I believe these fast-paced evolutions are exceptional and will not be the norm.
With DC you already kicked out smaller companies. So it is quite safe to assume, that the majority of the remaining large companies are using custom apps and will enable (and forgot) this feature anyway.
→ What are your analytics saying about this?
And a loooooot of companies are using ScriptRunner… which (in my opinion) is even more dangerous than the ability to upload apps…
