java 6 publishing no longer possible

[ashawley]

In June 2018, Maven Central updated their servers to only support newer SSL/TLS protocols, so a Java 6 build will be unable to publish.

Moving builds to Java 7 or 8 could have unintended consequences, since there may be changes in the Java class library between versions, but what else can be done?

See Lukas Rytz comment in this issue where it was originally discovered:

scala/scala-collection-compat#77

[SethTisue]

I see at scala/scala-parser-combinators#159 that it isn't only publishing that's affected, it's also even just retrieving artifacts over https

[ashawley]

Is it possible to do the build in Java 6, but then do a separate publish step in Java 8 and skip rebuilding the Jar on the second call?

$ env JAVA_HOME=$(/usr/libexec/java_home -v 1.6) sbt ++2.11.12 test package
$ env JAVA_HOME=$(/usr/libexec/java_home -v 1.8) sbt ++2.11.12 publish

I don't know enough sbt to know what is and isn't possible.

[lrytz]

That's not straightforward, unfortunately, because sbt is very careful about invalidating previously compiled artifacts if some dependency changes (for example a jar on the classpath, like the java standard library). Also, Seth points out that the Java 6 build doesn't even manage to fetch artifacts (if they are not in the cache), so we could not build on 6 reliably. I'm really not sure how we can keep building, or even testing on 6.

[ashawley]

Are there any tricks in sbt to dismantle those dependencies between tasks?

I've seen there is a skip syntax:

set skip in packageBin := true

And then there's a syntax for unhooking things

set packageBin in publish := {}

Is there also a way to fake the classpath is the same?

[SethTisue]

perhaps some add-on is available for Java 6 that addresses the problem?

[lrytz]

I've tried skip, but it only worked for in Compile, nothing else, in sbt 0.13.x. Possibly that's better in 1.x.

[ashawley]

It looks like Travis uses OpenJDK 1.6u41, released on 2012. By comparison, Oracle released u201 of their JDK in April 2018.

Ubuntu tries to backport security fixes periodically. They have done that up to u121 which is July-2016.

https://launchpad.net/ubuntu/+source/openjdk-6

Coincidentally, there were some TLS protocol changes in u121. However, I haven't found any evidence that the JDK-8133817 change was backported or not.

http://www.oracle.com/technetwork/java/javase/documentation/overview-156328.html#R160_121

TLS v1.2 support now available

TLS v1.2 is now a TLS protocol option with the release of JDK 6u121. By default, TLS v1.0 will remain the default enabled protocol on client sockets.

As an example, both the TLS v1.1 and TLS v1.2 protocols can be enabled for use on SSL/TLS connections via SSLSocket/SSLEngine/SSLServerSocket APIs:

sslSocket.setEnabledProtocols(new String[] { "TLSv1.1", "TLSv1.2"}); 

or by setting up and using a TLS v1.2 based SSLContext :

SSLContext ctx = SSLContext.getInstance("TLSv1.2"); 

or by using the SSLParameters API:

sslParameters.setProtocols(new String[] {"TLSv1.1", "TLSv1.2"}); 

The new jdk.tls.client.protocols System Property may also be used to control the protocols in use for a TLS connection (JDK-8151183).
One may launch their application with this property. E.g. java -Djdk.tls.client.protocols="TLSv1.2" will enable only TLS v1.2 on client SSLSockets.

Note that protocol versions specified via the new jdk.tls.client.protocols property will suppress any value set via the jdk.tls.client.enableSSLv2Hello property. SSLv2Hello can be passed to the jdk.tls.client.protocols value if necessary.

[lrytz]

Aha, interesting! Any idea where we could find OpenJDK 6 builds? The Oracle JDK downloads are way behind, I guess they make the newer ones only available to subscribers. I looked at https://github.com/shyiko/jabba/blob/master/index.json#L85-L90, they are not there..

[ashawley]

In a blog post on this issue, there's a fourth option, that suggests using HTTP.

The last entry at the bottom of the FAQ suggests that HTTP will always exist one of the hosts.

I cannot implement the above required changes in my environment -- what are my options?

We don't recommend this, but http://repo1.maven.org is, and will continue to be supported in the long term.

Is there a way to have sbt use the HTTP protocol for Maven?

[ashawley]

I tried using -Dsbt.repository.secure=false, but it seems that not all the repositories are parameterized with this setting. In particular, it seems typesafe-ivy-releases and sbt-ivy-snapshots are hard-coded to use https:

  ==== Maven Central: tried
    http://repo1.maven.org/maven2/org/scala-sbt/sbt/0.13.17/sbt-0.13.17.pom
    -- artifact org.scala-sbt#sbt;0.13.17!sbt.jar:
    http://repo1.maven.org/maven2/org/scala-sbt/sbt/0.13.17/sbt-0.13.17.jar
  ==== typesafe-ivy-releases: tried
    https://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt/0.13.17/ivys/ivy.xml
  ==== sbt-ivy-snapshots: tried
    https://repo.scala-sbt.org/scalasbt/ivy-snapshots/org.scala-sbt/sbt/0.13.17/ivys/ivy.xml

[SethTisue]

isn't it only Maven Central that's now rejecting the old-style https connections?

[ashawley]

It seems to be a different error from Maven Central

:::: ERRORS
  Server access Error: Connection reset url=https://repo.typesafe.com/typesafe/ivy-releases/org.scala-sbt/sbt/0.13.17/ivys/ivy.xml
  Server access Error: Connection reset url=https://repo.scala-sbt.org/scalasbt/ivy-snapshots/org.scala-sbt/sbt/0.13.17/ivys/ivy.xml