Migrazione dalle versioni precedenti di IBM Semeru Certified Edition per z/OS

A partire da Java 25, le applicazioni che caricano librerie native utilizzando metodi soggetti a restrizioni come System.loadLibrary() o System.load() riceveranno un avviso quando tali metodi vengono chiamati. Questa modifica rientra nella JEP 472, che prepara il terreno per future restrizioni all'accesso nativo. Il messaggio di avviso appare come segue:

WARNING: A restricted method in java.lang.System has been called
WARNING: java.lang.System::loadLibrary has been called by com.example.MyClass in an unnamed module
WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module
WARNING: Restricted methods will be blocked in a future release unless native access is enabled

Opzione 1: Opzione da riga di comando ` JVM `

• Disattiva gli avvisi relativi ai moduli senza nome: aggiungi l'opzione ` JVM ` --enable-native-access=ALL-UNNAMED al comando di avvio dell'applicazione. Ciò consente a tutto il codice contenuto nei moduli senza nome di richiamare metodi con restrizioni senza generare avvisi.
• Disattiva gli avvisi per moduli specifici: se la tua applicazione utilizza moduli con nome, specifica il nome del modulo: --enable-native-access=module.name.
• Disattiva gli avvisi per più moduli: utilizza un elenco separato da virgole: --enable-native-access=module1,module2.

Opzione 2: Attributo del manifesto JAR

Aggiungi Enable-Native-Access: ALL-UNNAMED al manifesto di un file JAR eseguibile. Ciò consente al file JAR di richiamare metodi con restrizioni senza richiedere opzioni da riga di comando.

• Queste opzioni di JVM devono essere aggiunte a livello di applicazione, non all'interno del codice della libreria o del framework.
• Questi avvisi hanno carattere puramente informativo e non impediscono l'esecuzione dell'applicazione in Java 25.
• In una futura versione di Java, i metodi con restrizioni saranno bloccati per impostazione predefinita, a meno che l'accesso nativo non venga abilitato esplicitamente.
• Si consiglia di aggiornare gli script di avvio dell'applicazione, le configurazioni di distribuzione o i manifest dei file JAR per includere le impostazioni necessarie per l'accesso nativo.

• Abilitazione dell'accesso nativo nella documentazione Java dell' Oracle.
• Specifica JEP 472.

A partire da Java 24, sono stati ridotti diversi limiti di sicurezza delle API JAXP (Java API for XML Processing) per migliorare la protezione contro gli attacchi basati su XML. Queste modifiche fanno parte della versione JDK-8343004 e riguardano le applicazioni che elaborano documenti XML contenenti entità di grandi dimensioni o strutture profondamente annidate.

I seguenti limiti vengono ridotti:

• jdk.xml.totalEntitySizeLimit - Ridotto da 5×10⁷ (50.000.000) a 1×10⁵ (100.000)
• jdk.xml.maxGeneralEntitySizeLimit - Modificato da 0 (illimitato) a 1×10⁴ (10.000)
• jdk.xml.maxParameterEntitySizeLimit - Ridotto da 1×10⁶ (1.000.000) a 1×10⁴ (10.000)
• jdk.xml.entityExpansionLimit - Ridotto da 64.000 a 6.400
• jdk.xml.entityReplacementLimit - Ridotto da 3×10⁶ (3.000.000) a 1×10⁵ (100.000)

Quando le applicazioni elaborano documenti XML che superano questi limiti, si verificano errori come i seguenti:

JAXP00010004: The accumulated size of entities is "100,003" that exceeded the "100,000" limit set by "jdk.xml.totalEntitySizeLimit"

Questo problema è stato riscontrato nei flussi di lavoro MF (Management Facility) di z/OS e potrebbe interessare altre applicazioni che elaborano file XML di grandi dimensioni, inclusi i file di configurazione o i formati di scambio dati.

Opzioni di mitigazione:

Opzione 1: Aumentare i limiti tramite le proprietà di sistema

Imposta limiti più elevati all'avvio dell' JVM e. Ad esempio, per ripristinare i valori predefiniti precedenti:

java -Djdk.xml.totalEntitySizeLimit=50000000
-Djdk.xml.maxGeneralEntitySizeLimit=0
-Djdk.xml.maxParameterEntitySizeLimit=1000000
-Djdk.xml.entityExpansionLimit=64000
-Djdk.xml.entityReplacementLimit=3000000

Avviso: l'aumento di questi limiti potrebbe esporre la tua applicazione a vulnerabilità di sicurezza legate al formato XML. L'impostazione jdk.xml.maxGeneralEntitySizeLimit=0 elimina completamente il limite, che era l'impostazione predefinita precedente, ma non è consigliata per motivi di sicurezza. Aumentare i limiti solo dopo un'attenta valutazione della sicurezza.

Opzione 2: Utilizzare il file di configurazione JAXP

Creare un file di configurazione JAXP personalizzato per impostare i limiti a livello di sistema utilizzando il modello fornito a tale scopo. Copia il modello e crea un file di configurazione personalizzato:

cp $JAVA_HOME/conf/jaxp-strict.properties.template <my_path>/jaxp.properties

Modifica il file di configurazione per impostare i limiti desiderati:

jdk.xml.totalEntitySizeLimit=50000000
jdk.xml.maxGeneralEntitySizeLimit=0
jdk.xml.maxParameterEntitySizeLimit=1000000
jdk.xml.entityExpansionLimit=64000
jdk.xml.entityReplacementLimit=3000000

Quindi specificare il file di configurazione all'avvio dell' JVM e:

java -Djava.xml.config.file=<my_path>/jaxp.properties

Nota: questo metodo consente di gestire le impostazioni JAXP a livello centrale senza dover modificare gli script di avvio dell'applicazione per ogni singola proprietà.

Opzione 3: Impostare i limiti tramite codice

Configurare i limiti nel codice dell'applicazione utilizzando l'API JAXP:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setAttribute("jdk.xml.entityExpansionLimit", "64000");
factory.setAttribute("jdk.xml.maxGeneralEntitySizeLimit", "0");

Opzione 4: Ristrutturare l'elaborazione XML

Si consiglia di riorganizzare i documenti XML di grandi dimensioni in file più piccoli e più gestibili, oppure di utilizzare API di streaming (come StAX ) che elaborano l'XML in modo incrementale anziché caricare interi documenti in memoria.

Per ulteriori informazioni sui limiti di sicurezza e sulle migliori pratiche relative a JAXP, consultare la Guida alla sicurezza dell'API Java per l'elaborazione XML (JAXP).

La JEP 486 disattiva in modo permanente il Security Manager in Java 25. Di conseguenza, alcune funzionalità di JAAS non supportano più Security Manager e diversi metodi sono stati modificati. Per ulteriori informazioni, consultare la sezione "Rimozione di Security Manager".

• doAs() i metodi sono stati trasferiti su callAs().
• doAsPrivileged() e privateDoAs() i metodi sono stati trasferiti su callAsPrivileged().

Per ulteriori informazioni sulle modifiche apportate a livello di ` JAAS `, consultare la documentazione disponibile all'indirizzo JAAS e la documentazione relativa all'API all'indirizzo JAAS.

In Java 25, « OpenJCEPlus » non è più incluso nell'immagine di runtime di base; ora viene distribuito come modulo autonomo. Questa modifica riguarda le immagini di runtime personalizzate create con jlink, dove il modulo deve essere aggiunto esplicitamente. Senza l' OpenJCEPlus,, le applicazioni ricorreranno alle implementazioni alternative di JCE, il che potrebbe comportare un calo significativo delle prestazioni crittografiche e l'assenza di alcuni algoritmi con accelerazione hardware disponibili su IBM Z.

Per includere OpenJCEPlus in un'immagine di runtime personalizzata, utilizzare:

jlink --add-modules <existing_modules>,openjceplus ...

Controlla gli script di compilazione e le immagini dei container per assicurarti che il modulo venga aggiunto durante jlink l'elaborazione. Non sono necessarie modifiche per le installazioni standard dell'SDK o quando si esegue Java direttamente.

Le classi interne dei pacchetti com.ibm.securitycom.ibm.misc e, incluse nelle precedenti versioni di Semeru, non sono più disponibili. Se si tenta di utilizzare queste classi, verrà visualizzato un errore che indica che il pacchetto non esiste.

/usr/lpp/fonts/worldtype