I just wanted to test our app against 10.0.1 but unfortunately the atlassian.upm.signature.check.disabled=true flag seems to be broken, in contrast to 10.0.0-rc2! Installing the app now fails with the dreaded “Signature check failed” error. We’ve tried troubleshooting it by setting ALL possible system flags and also using the upm configuration file.
We use the docker image. I just replace the image tag from 10.0.0-rc2 to 10.0.1 and it breaks, so I’m quite sure the problem is on the Atlassian side. Could you please check that?
We are also running into the signature check failure, using the Confluence 10.0.1 docker image and an upm.properties file with atlassian.upm.signature.check.disabled=true in /var/atlassian/application-data/confluence-shared/upmconfig.
Replace the existing JAR of UPM (version 8.0.2) in the Confluence installation directory with version 8.0.1.
The file is located here: <INSTALL_DIR>/confluence/WEB-INF/atlassian-bundled-plugins/com.atlassian.upm.atlassian-universal-plugin-manager-plugin-8.0.2.jar
@SteffenMueller@jens@cheinig We are really sorry for the inconvenience. Our team noticed the issue and is already working on the fix. We will inform you about the progress.
Will there be a 10.0.2 with the fixes that will then be the official minimum 10.x release available or will the 10.0.1 stay the lowest available 10.x version?
I have just tested login.action and viewpage.action and haven’t found this warning. So much so we allow all methods of org.apache.commons.lang3.StringUtils class.
To further reproduce the issue, can you please confirm how did you start the instance, plugins installed, Java version used and attach the logs if possible.
Thanks for reporting this @jens - whilst Velocity has been bolstered with the central blocklist in 10.0, the actual allowlist mechanism has remained unchanged, and certainly hasn’t changed between RC2 and GA. The issue you mention however, has been reported by numerous customers and partners since the release of Confluence 9.0.
Despite all of the customer reports and instance data gathered, I, and none of our support engineers have been able to identify a common factor, nor reproduce this issue.
I am currently investigating a lead that if the very first Velocity template rendered upon instance startup originates from UPM, this allowlist error will trigger and persist until the instance is restarted.
If you’ve any other clues to contributing factors that would help us reproduce it, I’m all ears. You’re also most welcome to attach a debugger yourself - we expect the bug lies in the vicinity of org.apache.velocity.util.introspection.SecureIntrospectorImpl#isAllowlistedClassPackageCached (org.apache.velocity:velocity:1.6.4-atlassian-39).
@Kusal I’ve attached a debugger and reproduced it.
I’m sending you a PN with the details, but your assumption seems to be correct: SecureIntrospectorImpl#allowlistedClassesRef contains a Class object loaded from UPM’s classloader (and the UPM JAR includes an exploded commons-lang3).
That explains why isAllowlistedClassPackageInternal returns false when checking the StringUtils Class object loaded from the web app classloader.
@jponting could you please check the docker pipeline. It is 8h after your post and 10.0.2 ubi image is not available yet. Would be great if it will be available soon. Thanks