IllegalStateException lanciata da Maven (? SSL-correlati) durante il download dipendenze del progetto

Question

Sono la creazione di un ambiente di sviluppo su una macchina ARM, con le seguenti versioni di Java e Maven, sia installato tramite apt-get:

(xenial)craig@localhost:~$ mvn -version 
Apache Maven 3.3.9 
Maven home: /usr/share/maven 
Java version: 1.8.0_91, vendor: Oracle Corporation 
Java home: /usr/lib/jvm/java-8-openjdk-armhf/jre 
Default locale: en_US, platform encoding: ANSI_X3.4-1968 
OS name: "linux", version: "3.14.0", arch: "arm", family: "unix" 

(xenial)craig@localhost:~$ java -version 
openjdk version "1.8.0_91" 
OpenJDK Runtime Environment (build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14) 
OpenJDK Zero VM (build 25.91-b14, interpreted mode) 

Tuttavia, quando eseguo un mvn clean install sul mio progetto, fallisce il tentativo di scaricare un file POM che esiste . (Posso visitare nel mio browser.)

Lo stacktrace è abbastanza grande, ma la radice sembra essere:

Caused by: java.lang.IllegalStateException 
    at sun.security.ec.ECDHKeyAgreement.deriveKey(Native Method) 
    at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:130) 
    at sun.security.ec.ECDHKeyAgreement.engineGenerateSecret(ECDHKeyAgreement.java:163) 
    at javax.crypto.KeyAgreement.generateSecret(KeyAgreement.java:648) 
    at sun.security.ssl.ECDHCrypt.getAgreedSecret(ECDHCrypt.java:101) 
    at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1067) 
    at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) 
    at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) 
    at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) 
    at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) 
    at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) 
    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403) 

C'è, purtroppo, non è molto di più ad esso - Maven fallisce con:

Caused by: org.eclipse.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for org.jacoco:jacoco-maven-plugin:jar:0.7.6.201602180812 

E lo stack termina con l'eccezione generata in deriveKey(). Mi manca qualche libreria crittografica sulla mia macchina?

Questa è una nuova installazione di Xenial (16.04 LTS).

Answer 1

Durante l'installazione di Oracle JRE è la soluzione più semplice, ecco le istruzioni nel caso in cui si desideri utilizzare specificamente OpenJDK Zero VM, sia con Maven, SSL, l'accordo con chiave ECDH o qualsiasi altro metodo crittografico implementato in codice nativo nel provider di crittografia predefinito OpenJDK.

Ho supposto che il metodo ECDHKeyAgreement.deriveKey non riesca perché è un metodo nativo e OpenJDK Zero VM come pacchetto in Ubuntu per Raspberry Pi non è in grado di gestirlo; Non sono in grado di eseguire il debug di questo errore.

Ubuntu include il provider di crittografia BouncyCastle implementato in puro Java. È necessario installarlo solito modo:

sudo apt install libbcprov-java* 

(questo installa anche la documentazione)

quindi seguire le istruzioni in /usr/share/doc/libbcprov-java/README.Debian per renderlo il provider predefinito di crittografia. In particolare, è necessario creare un collegamento al jar del provider dalla directory ext di JRE, quindi fare un update-java-alternatives -l seguito da (nel mio caso: ho utilizzato i valori predefiniti forniti in Ubuntu 16.04 installazione del server Raspberry Pi - lo specifico JRE directory può cambiare nel tempo):

sudo ln -s /usr/share/java/bcprov.jar /usr/lib/jvm/java-1.8.0-openjdk-armhf/jre/lib/ext/bcprov.jar 

quindi modificare il file di /usr/lib/jvm/java-1.8.0-openjdk-armhf/jre/lib/security/java.security (invocando l'editor con sudo), aggiungendo la riga:

security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider 

... dove sono elencati i fornitori di crypto, e l'aggiunta di 1 alla priorità di quelli già presenti, in modo che l'elenco assomigli a questo:

security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider 
security.provider.2=sun.security.provider.Sun 
security.provider.3=sun.security.rsa.SunRsaSign 
security.provider.4=sun.security.ec.SunEC 
security.provider.5=com.sun.net.ssl.internal.ssl.Provider 
security.provider.6=com.sun.crypto.provider.SunJCE 
security.provider.7=sun.security.jgss.SunProvider 
security.provider.8=com.sun.security.sasl.Provider 
security.provider.9=org.jcp.xml.dsig.internal.dom.XMLDSigRI 
security.provider.10=sun.security.smartcardio.SunPCSC 

Crypto in Java ora dovrebbe funzionare, anche se molto lentamente. Ecco un esempio di programma che ho usato per confermare che lo fa, se non si vuole usare Maven per questo:

import java.io.InputStream; 
import java.net.URL; 
import java.net.URLConnection; 

public class URLGet { 
     public static void main(String[] args) { 
       try { 
         URL url = new URL(args[0]); 
         URLConnection urlConnection = url.openConnection(); 
         try (
           InputStream stream = urlConnection.getInputStream(); 
         ) { 
           byte[] buf = new byte[4096]; 
           int read; 
           while ((read = stream.read(buf, 0, buf.length)) > 0) { 
             System.out.write(buf, 0, read); 
           } 
         } 
       } catch (Exception e) { 
         e.printStackTrace(System.err); 
       } 
     } 
} 

Point in qualsiasi URL HTTPS (ad es java URLGet https://www.google.com/) per confermare che Java in grado di gestire SSL .