Java Security Exception when downloading the Gradle wrapper in Bitbucket Pipelines

[Deleted user]

I recently made some changes to one of my repositories, including updating to Java 9, and now my Pipelines builds are failing due to a security exception caused when Pipelines attempts to download the Gradle wrapper. Here's the stack trace:

Exception in thread "main" java.lang.ExceptionInInitializerError
 at java.base/javax.crypto.JceSecurityManager.<clinit>(JceSecurityManager.java:65)
 at java.base/javax.crypto.Cipher.getConfiguredPermission(Cipher.java:2606)
 at java.base/javax.crypto.Cipher.getMaxAllowedKeyLength(Cipher.java:2630)
 at java.base/sun.security.ssl.CipherSuite$BulkCipher.isUnlimited(CipherSuite.java:602)
 at java.base/sun.security.ssl.CipherSuite$BulkCipher.<init>(CipherSuite.java:574)
 at java.base/sun.security.ssl.CipherSuite$BulkCipher.<clinit>(CipherSuite.java:460)
 at java.base/sun.security.ssl.CipherSuite.<clinit>(CipherSuite.java:1074)
 at java.base/sun.security.ssl.SSLContextImpl.getApplicableSupportedCipherSuiteList(SSLContextImpl.java:353)
 at java.base/sun.security.ssl.SSLContextImpl.access$100(SSLContextImpl.java:41)
 at java.base/sun.security.ssl.SSLContextImpl$AbstractTLSContext.<clinit>(SSLContextImpl.java:589)
 at java.base/java.lang.Class.forName0(Native Method)
 at java.base/java.lang.Class.forName(Class.java:300)
 at java.base/java.security.Provider$Service.getImplClass(Provider.java:1844)
 at java.base/java.security.Provider$Service.newInstance(Provider.java:1820)
 at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
 at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
 at java.base/javax.net.ssl.SSLContext.getInstance(SSLContext.java:169)
 at java.base/javax.net.ssl.SSLContext.getDefault(SSLContext.java:99)
 at java.base/javax.net.ssl.SSLSocketFactory.getDefault(SSLSocketFactory.java:123)
 at java.base/javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory(HttpsURLConnection.java:332)
 at java.base/javax.net.ssl.HttpsURLConnection.<init>(HttpsURLConnection.java:289)
 at java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.<init>(HttpsURLConnectionImpl.java:86)
 at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:62)
 at java.base/sun.net.www.protocol.https.Handler.openConnection(Handler.java:57)
 at java.base/java.net.URL.openConnection(URL.java:1049)
 at org.gradle.wrapper.Download.downloadInternal(Download.java:62)
 at org.gradle.wrapper.Download.download(Download.java:51)
 at org.gradle.wrapper.Install$1.call(Install.java:62)
 at org.gradle.wrapper.Install$1.call(Install.java:48)
 at org.gradle.wrapper.ExclusiveFileAccessManager.access(ExclusiveFileAccessManager.java:69)
 at org.gradle.wrapper.Install.createDist(Install.java:48)
 at org.gradle.wrapper.WrapperExecutor.execute(WrapperExecutor.java:107)
 at org.gradle.wrapper.GradleWrapperMain.main(GradleWrapperMain.java:61)
Caused by: java.lang.SecurityException: Can not initialize cryptographic mechanism
 at java.base/javax.crypto.JceSecurity.<clinit>(JceSecurity.java:118)
 ... 33 more
Caused by: java.lang.SecurityException: Can't read cryptographic policy directory: unlimited
 at java.base/javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:324)
 at java.base/javax.crypto.JceSecurity.access$000(JceSecurity.java:73)
 at java.base/javax.crypto.JceSecurity$1.run(JceSecurity.java:109)
 at java.base/javax.crypto.JceSecurity$1.run(JceSecurity.java:106)
 at java.base/java.security.AccessController.doPrivileged(Native Method)
 at java.base/javax.crypto.JceSecurity.<clinit>(JceSecurity.java:105)
 ... 33 more

Here is a link to the failing build, and here is the repository in which the build was run.

[Bruno Rosa]

It looks like you're running into https://github.com/docker-library/openjdk/issues/101. I have the same problem here when I try to build using Docker on my local machine - outside Pipelines. I suspect this is related to the image you're using rather than Pipelines itself. Plus the Docker image you're using java seems to have been deprecated in favor of the openjdk one. I don't have this problem when I try to use openjdk:9 (instead of java:9) for example - you might want to give it at try. Hope it helps.