Confluence 7.12.3 wasn't semver

Confluence Development Confluence Server
1

Release management seems to have failed on Confluence 7.12.3.
It contained an update to the xstream dependencies that sent most of our apps into misery, i.e. the parts that used XStream didn’t work anymore.

Those changes have been teasered in Preparing for Confluence 7.13 | Confluence Data Center and Server 8.0 | Atlassian Documentation - but obviously are contained in Confluence 7.12.3 - simply have a look at confluence/WEB-INF/lib

Any comments?

4 Likes
2

@christoffer I’ve reached out to the Confluence Server team for comment, and will share info as soon as available. Thanks.

2 Likes
4

Totally agree with @christoffer. Suffered from this as well :frowning: XStream dependency update has been announced for 7.13, but become available in 7.12.3

5

@christoffer @sash011 XStream was updated (to 1.4.17) due to a medium security vulnerability. Because of the severity level, it was also applied to previous 7.12.x versions.

We recommend using XStream via confluence-compat-lib (see XStream 1.4 upgrade | Confluence Data Center and Server 8.0 | Atlassian Documentation) which should help to avoid problems like this in the future.

Thank you for sharing details on how this adversely affected you. We’ll work on how we can communicate these types of changes better in the future.

2 Likes
6

Hi @christoffer, @sash011

Thanks @nmansilla, yes we needed to backport this lib upgrade to 7.12.3 because it was a security issue around the library. The steps to fix any broken plugin are detailed in the issue description.
PS: It was API compatible change from XStream in 1.4.17, but not OSGi compatible. It had potential to break plugins which bundle XStream themselves, OSGi gets confused finding different implementation for XmlPullParser through ServiceLoader.

Please see all the issues fixed as part of 7.12.3 here:
https://confluence.atlassian.com/doc/issues-resolved-in-7-12-3-1072475372.html
I would take your feedback to our team to minimise this sort of disruption in future.

Thanks,
Ganesh

1 Like
7

Thanks for taking the time to reply and for shifting right on security. We were bundling 1.4.16 and used a very minimalistic allowlist exactly because of earlier CVEs. So we ran into the aforementioned OSGi confusion.
A proactive post in here with the material you provided in your answers would have helped - especially because you mentioned that you were aware of the potential breakage.

2 Likes
8

Yes, the Issues resolved in 7.12.3 | Confluence Data Center and Server 8.0 | Atlassian Documentation shows fixed/resolved issues and xstream upgrade is part of it.
What confused us is that we have not seen this in “preparing for 7.12” documentation, but only in “preparing for 7.13”.
That is why we have been hit by bugs reported by our customers who have been testing upgrades to 7.12.3 and found out that the app fails miserably.

9

Heads up, I had some trouble with Spring Java Configuration and XStreamManagerCompat.

OsgiServices.importOsgiService(XStreamManagerCompat.class) gives a ServiceUnavailableException

I got this to work, don’t really want to do it this way but it works (in my Spring Java configuration class):

@Bean
    public XStreamManagerCompat xStreamManagerCompat() {
        // org.eclipse.gemini.blueprint.service.ServiceUnavailableException: service matching
        // filter=[(objectClass=com.atlassian.confluence.compat.setup.xstream.XStreamManagerCompat)]
        // unavailable
        //	at
        // org.eclipse.gemini.blueprint.service.importer.support.internal.aop.ServiceDynamicInterceptor.getTarget(ServiceDynamicInterceptor.java:404)
        //
        //        return importOsgiService(XStreamManagerCompat.class);

        return new XStreamManagerCompat((XStreamManager)ContainerManager.getComponent("xStreamManager"),
                    XStreamManagerCompat.class.getClassLoader());
    }
1 Like