Download the beta from our site to start testing your app for compatibility with the changes. Be sure to take a look at our Preparing for Confluence 7.18 guide to find out what you need to do to make your app compatible. We’ll update that page regularly, so keep an eye on it to see any changes.
In the XStream uplift notes linked from the “Preparing” page above, there is an issue with apps in the recent 09 May 2022 change, due to the default switch in XStream from blocklist to allowlist.
The docs state that, if your app is instantiating XStream manually, you will need to configure the allowlist yourself. (This was not previously necessary due to the default being “allow”.)
This sounds great in theory, but in practice, most of this functionality is walled off because the principal allowlist configuration package “com.thoughtworks.xstream.security” is not exported into OSGi-land by Confluence, meaning it is not accessible to third-party apps, and thus the allowlist cannot be fully configured.
This prevents any app from calling (for example) the xStream.addPermission() method, because all of the possible arguments to the method would have to come from the above invisible-to-us package.
It does seem to be possible to call xStream.allowTypes() with an explicit list of class names without errors, so the sky is not falling (yet), but the lack of an export for the “.security” package means that apps are largely stuck with the default base allowlist and they cannot easily change it.
Is there any chance this package could get exported? Ideally before 7.18.0 goes out?
Note that this change also breaks plugin cross-compatibility with Confluence 7.9 and below (which is still within the two-year support window, so dropping support is not a viable option).
If you instantiate XStream manually, you can’t call xStream.allowTypes() on Conf <=7.9 without jumping through hoops (because that method does not exist on the bundled XStream 1.1.1), and yet we must call it on Conf 7.18+ so that deserialization does not fail.
It seems like the XStream upgrade docs might have been better off starting with a big warning stating “you are no longer allowed to instantiate XStream manually and you must rewrite your code to use our compat-lib interface if you want it to work with Confluence 7.18 onward”.
Thanks for reaching out with feedback. Let us first put why XStream upgrade is required. XStream until 1.4.18 is subject to multiple vulnerabilities like RCE, DoS, Arbitrary Code Execution and many more. We had to upgrade XStream for few of these fixes as part of [CONFSERVER-69322] XStream upgrade to 1.4.18 - Create and track feature requests for Atlassian products..
We must say that, yes, we haven’t enabled allowlist by default in ConfluenceXStream API to minimise disruption. But at the end it is security vs stability, and we tried to keep a balance by giving a choice to admins to switch to allowlist if they want the security.
We are not exporting security package as we are moving towards removing XStream as exposed API slowly, this will allow us to work with XStream in future easily with less breaking changes. XStream allows you to configure all the allowlist not just through allowTypes, but also allowTypeHierarchy and allowTypesByRegExp.
Lastly, instead of exporting more XStream packages, we would suggest following ways to make your app compatible:
Use confluence-compat-lib to fetch a ConfluenceXStream and let it handle pre-7.9 compatibility. You can also configure allowlist using <xstream-security tag allowing it to work where Confluence version supports it. Please refer to this document to understand how to use confluence-compat-lib or <xstream-security.
Bundle your own XStream and have greater control. This might increase your app size, but gives you the cheapest solution.
Thanks for the response. Bundling XStream would certainly work, although it almost doubles our .JAR size (adds 0.6 Mb) and it seems an unwise use of our customer’s JVM resources.
I suggest the linked documentation be updated. It has implied since the beginning (two years ago) that you were still able to use your own “new XStream()” instance, but this is no longer truly the case.
For example, if you’re not planning to export the needed packages, the recommendation “If your app uses its own XStream, you’ll need to mark the allowlist in that XStream instance” doesn’t fully work. There’s no way to revert your “new XStream()” to the previous behavior (blocklist only) without exporting those packages, for example, or to fine-tune other parts of the allowlist. And if we’re going to have to enumerate all of the required types anyway, we might as well just use the compat-lib. (And at least some of us were using XStream in a trivial manner that was safe from all of those vulnerabilities, so we don’t care about allowlist vs blocklist.)
And even if you did export those packages, or if you use the very-limited methods available without exporting those packages, the docs should also mention that the code you recommend writing to “mark the allowlist” will break compatibility with Confluence <=7.9, unless you explicitly test the Confluence version in your code and then play fancy games to refrain from loading specific classes when they are not otherwise available.
So I suggest the only real options that the docs should recommend are those that you listed above, which are: (a) bundle your own XStream, or (b) use the compat-lib API.