Hi, sorry I was wrong - problem is with something else. I run tests on Windows/Java7 and i think current configuration at www.apache.org allows only the following cipher suites: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 and Java7 is unable to negotiate connection (even with unrestricted policy) because on Java list there are only ciphers with SHA1.
java 7 Cipher Suites: [ // short list without SSLv3 and 3DES/RC4 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA ] Quick fix can be MNG-6414 to skip downloading Apache license for dependencies with Apache license. BR Sylwester pon., 21 maj 2018 o 10:35 użytkownik Hervé BOUTEMY <[email protected]> napisał: > guys, please have a look at the build before extrapolating ideas on what > may fail > > as I wrote, the issue is not with central, it's with > https://www.apache.org/ > > I'll copy/paste the exception: > Caused by: org.codehaus.plexus.resource.loader.ResourceNotFoundException: > Could not find resource 'https://www.apache.org/licenses/LICENSE-2.0.txt'. > at org.codehaus.plexus.resource.DefaultResourceManager.getResource > (DefaultResourceManager.java:173) > > > I perfectly know that Java 7u131 and more have TLS 1.2 enabled by default > (like Java 8), but before it had to be enabled explicitely: I did the tests > that were used to document the central TLS 1.1 discontinuation announce [1] > (and there is still a typo here: the second error message is simply "peer > not authenticated", and you get it with Maven 3.0 and 3.1). > I know the technical details. > > I know we can deal the situation from a pure technical perspective, asking > infra to add a Java 7u131+ to the CI server: don't hesitate to go this way > if you want (and ignore that most developers use latest free Oracle JDK, > that is 7u80) > > I also know that: > - we'll switch to Java 8 for 3.6 in a few weeks > - the JDK we are talking about is only used to build Maven: core ITs to > test the binary are executed without any issue with Java 7u80 and Java 8 on > Linux and Windows > hence the proposal to simply build with Java 8: I don't see what is > technically invalid here. > What I know is that it is the only solution I'll take time to work on, > since I think the other is a waste of my time. > > > Now, don't hesitate: yes, a new Java 7u131+ JDK on the CI server will also > fix the issue > Just do it if it's the only option you want. > > Regards, > > Hervé > > [1] > https://central.sonatype.org/articles/2018/May/04/discontinue-support-for-tlsv11-and-below/ > > Le dimanche 20 mai 2018, 23:09:33 CEST Michael Osipov a écrit : > > Am 2018-05-20 um 22:28 schrieb Sylwester Lachiewicz: > > > Hi, > > > Difference between repo1.maven.org and maven.apache.org is that out > site > > > accepts only tlsv1.2 ( > > > https://www.ssllabs.com/ssltest/analyze.html?d=maven.apache.org) where > > > Central now accepts tls 1.0, 1.1, 1.2 > > > https://www.ssllabs.com/ssltest/analyze.html?d=repo1.maven.org > > > > > > I think TLSv1.2 can be enabled for client connections > > > https://bugs.openjdk.java.net/browse/JDK-7093640 from Java 1.7u95 only > > > with > > > property jdk.tls.client.protocols. > > > > > > Java 1.7u80 is latest public version available and releases after > 1.7.0_80 > > > are only available to Oracle Customers. I found details here: > > > > https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-http > > > s > > > > > > So I think only option is to switch to Java 8 only and with Maven > Central > > > switch to TLSv1.2 only we can just forget about java 7 for Maven > projects > > > builds.. > > > > > > BR > > > Sylwester > > > > > > sob., 19 maj 2018 o 11:41 użytkownik Hervé Boutemy < > [email protected]> > > > > > > napisał: > > >> Maven master branch build is failing on ASF Jenkins for one week > > >> > > >> looks related to TLS 1.2 only support on https://www.apache.org/, > when > > >> the build is currently done with JDK 7u80 which has TLS 1.2 disabled > by > > >> default > > >> I tried to enable TLS 1.2 adding > > >> "-Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2" > > >> option, but it does not work (works for dependencies download through > > >> Maven > > >> Artifact Resolver + Wagon, but the failing code uses directly > > >> java.net.URL.openStream() ) > > >> > > >> IMHO, the simplest solution is to update our Maven core Jenkinsfile to > > >> build with Java 8, since it's completely decoupled from the ITs run > > >> (happening with misc JDK and OSes) > > > > I concur, works for me with https://www.azul.com/downloads/zulu/: > > Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; > > 2018-02-24T20:49:05+01:00) > > Maven home: D:\Entwicklung\Programme\apache-maven-3.5.3\bin\.. > > Java version: 1.7.0_181, vendor: Azul Systems, Inc. > > Java home: C:\Program Files\Zulu\zulu-7\jre > > Default locale: de_DE, platform encoding: Cp1252 > > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
