Migration depuis les versions antérieures d' IBM Semeru Certified Edition pour z/OS

À partir de Java 25, les applications qui chargent des bibliothèques natives à l'aide de méthodes restreintes telles que System.loadLibrary() ou System.load() recevront des avertissements lorsque ces méthodes seront appelées. Cette modification s'inscrit dans le cadre de la JEP 472, qui prépare à de futures restrictions concernant l'accès natif. Le message d'avertissement s'affiche comme suit :

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

Option 1 : Option de ligne de commande « JVM »

• Masquer les avertissements concernant les modules sans nom : ajoutez l'option ` JVM ` --enable-native-access=ALL-UNNAMED à la commande de démarrage de votre application. Cela permet à tout le code des modules sans nom d'appeler des méthodes restreintes sans générer d'avertissements.
• Masquer les avertissements pour des modules spécifiques : si votre application utilise des modules nommés, indiquez le nom du module : --enable-native-access=module.name.
• Masquer les avertissements pour plusieurs modules : utilisez une liste séparée par des virgules : --enable-native-access=module1,module2.

Option 2 : attribut de manifeste JAR

Ajouter Enable-Native-Access: ALL-UNNAMED au manifeste d'un fichier JAR exécutable. Cela permet au fichier JAR d'appeler des méthodes restreintes sans avoir besoin d'options de ligne de commande.

• Ces options d' JVM ation doivent être ajoutées au niveau de l'application, et non dans le code de la bibliothèque ou du framework.
• Ces avertissements sont purement informatifs et n'empêchent pas l'application de fonctionner sous Java 25.
• Dans une prochaine version de Java, les méthodes restreintes seront bloquées par défaut, à moins que l'accès natif ne soit explicitement activé.
• Prévoyez de mettre à jour les scripts de démarrage de votre application, les configurations de déploiement ou les manifestes JAR afin d'y inclure l'activation de l'accès natif appropriée.

• Activation de l'accès natif dans la documentation Java d' Oracle.
• Spécification JEP 472.

À partir de Java 24, plusieurs limites de sécurité des API JAXP (Java API for XML Processing) ont été abaissées afin de renforcer la protection contre les attaques basées sur le XML. Ces modifications font partie de la version JDK-8343004 et concernent les applications qui traitent des documents XML contenant des entités volumineuses ou des structures fortement imbriquées.

Les limites suivantes sont réduites :

• jdk.xml.totalEntitySizeLimit - Réduit de 5 × 10⁷ (50 000 000) à 1 × 10⁵ (100 000)
• jdk.xml.maxGeneralEntitySizeLimit - Modifié de 0 (illimité) à 1×10⁴ (10 000)
• jdk.xml.maxParameterEntitySizeLimit - Réduit de 1×10⁶ (1 000 000) à 1×10⁴ (10 000)
• jdk.xml.entityExpansionLimit - Réduit de 64 000 à 6 400
• jdk.xml.entityReplacementLimit - Réduit de 3 × 10⁶ (3 000 000) à 1 × 10⁵ (100 000)

Lorsque des applications traitent des documents XML qui dépassent ces limites, des erreurs telles que celles-ci se produisent :

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

Ce problème a été constaté dans les flux de travail de la Facilité de gestion (MF) d' z/OS. Il peut également affecter d'autres applications qui traitent des fichiers XML volumineux, notamment des fichiers de configuration ou des formats d'échange de données.

Mesures d'atténuation :

Option 1 : Augmenter les limites à l'aide des propriétés du système

Définissez des limites plus élevées lors du démarrage de l' JVM. Par exemple, pour rétablir les valeurs par défaut précédentes :

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

Avertissement : l'augmentation de ces limites peut exposer votre application à des failles de sécurité liées au format XML. Ce paramètre jdk.xml.maxGeneralEntitySizeLimit=0 supprime complètement la limite, ce qui correspondait à la valeur par défaut précédente, mais n'est pas recommandé pour des raisons de sécurité. N'augmentez les limites qu'après un examen minutieux des mesures de sécurité.

Option 2 : Utiliser le fichier de configuration JAXP

Créez un fichier de configuration JAXP personnalisé pour définir des limites à l'échelle du système à l'aide du modèle fourni à cet effet. Copiez le modèle et créez un fichier de configuration personnalisé :

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

Modifiez le fichier de configuration pour définir les limites souhaitées :

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

Spécifiez ensuite le fichier de configuration au démarrage de l' JVM :

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

Remarque : cette méthode vous permet de gérer les paramètres JAXP de manière centralisée sans avoir à modifier les scripts de démarrage de l'application pour chaque propriété.

Option 3 : Définir des limites par programmation

Configurez les limites dans le code de votre application à l'aide de l'API JAXP :

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

Option 4 : Refactorisation du traitement XML

Envisagez de restructurer les documents XML volumineux en fichiers plus petits et plus faciles à gérer, ou utilisez des API de traitement en continu (telles que StAX ) qui traitent le XML de manière incrémentielle plutôt que de charger des documents entiers en mémoire.

Pour plus d'informations sur les restrictions de sécurité JAXP et les bonnes pratiques, consultez le Guide de sécurité de l'API Java pour le traitement XML (JAXP).

La JEP 486 désactive définitivement le gestionnaire de sécurité dans Java 25. Par conséquent, certaines fonctionnalités d' JAAS s ne prennent plus en charge le Gestionnaire de sécurité, et plusieurs méthodes ont été modifiées. Pour plus d'informations, consultez la section « Désinstallation de Security Manager ».

• doAs() les méthodes ont été transférées vers callAs().
• doAsPrivileged() et privateDoAs() les méthodes ont été transférées vers callAsPrivileged().

Pour plus d'informations sur les modifications apportées au niveau de l' JAAS, consultez la documentation disponible à l'adresse JAAS ainsi que la documentation relative à l'API sur JAAS.

Dans Java 25, le module « OpenJCEPlus » n'est plus inclus dans l'image d'exécution de base; il est désormais distribué sous forme de module autonome. Cette modification concerne les images d'exécution personnalisées créées avec jlink, dans lesquelles le module doit être ajouté explicitement. Sans OpenJCEPlus,, les applications se rabattront sur les autres implémentations JCE, ce qui peut entraîner une baisse significative des performances cryptographiques et l'absence de certains algorithmes accélérés par le matériel disponibles sur IBM Z.

Pour inclure OpenJCEPlus dans une image d'exécution personnalisée, utilisez :

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

Vérifiez vos scripts de compilation et vos images de conteneur pour vous assurer que le module est bien ajouté au cours jlink du traitement. Aucune modification n'est nécessaire pour les installations standard du SDK ou lors de l'exécution directe de Java.

Les classes internes des paquets com.ibm.securitycom.ibm.misc et, incluses dans les versions précédentes d' Semeru, ne sont plus disponibles. Si vous essayez d'utiliser ces classes, vous obtiendrez une erreur indiquant que le paquet n'existe pas.

/usr/lpp/fonts/worldtype