Le Journal

Spring Framework est disponible depuis quelques jours. Cette version est importante avec une profonde évolution des bases techniques : focus sur Java 25, Spring Boot 4, Jakarta EE 11, Jackson 3, Kotlin 2.2, JUnit 6. Bref, une importante évolution des dépendances et du socle technologique. Spring Framework 7 améliore singulièrement les tests avec la possibilité de faire une pause et de reprendre selon le contexte gardé en cache. Autre nouveauté, la possibilité de faire un versionning d'API en spécifiant dans le code la version souhaitée de l'API : par exemple : @RequestMapping(path "=/hello", version = "2"). Jusqu'à présent, la notion de version = n'était pas possible. Spring Framework propose aussi un client HTTP déclaratif. Il est possible de créer une solution http avec une "simple" annotation @HttpServiceClient :@HttpServiceClient("christmasJoy")public interface ChristmasJoyClient { @GetExchange("/greetings?random") String getRandomGreeting();}Cette nouvelle approche devrait rendre les clients HTTP plus souples et plus rapide à créer et à configurer.Pour faciliter les tâches asynchrones, Spring Framework 7 introduit le multiple TaskDecorator beans. Ainsi vous pouvez en déclarer plusieurs et Spring s'occupe de composer la chaîne asynchrone selon l'ordre défini ou si vous avez défini un @Order. Sur la partie sécurité, Spring Framwork 7 adopte le JSpecify pour le Null Safety. Côté dépréciation, cette version retire ou déprécie plusieurs éléments :- les paquets javax.* sont retirés- Jackson 2.x n'est plus supporté. Seule la v3 l'est.- Spring JCL est retiré au profit d'Apache Commons Logging- JUnit 4 est retiré.Pour en savoir plus : https://www.baeldung.com/spring-boot-4-spring-framework-7Annonce de disponibilité : https://spring.io/blog/2025/11/13/spring-framework-7-0-general-availabilityCatégorie actualité: FrameworksSpringImage actualité AMP: 

Le runtime container, runC, utilisé par Docker et Kubernetes, subit trois importantes vulnérabilités : CVE-2025-31133, CVE-2025-52565 et CVE-2025-52881. Ces alertes sont dues à Aleksa Sarai, un ingénieur logiciel de SUSE. runC n'est pas le composant d'infrastructure le plus connu. Or, ce runtime container est le runtime référence pour exécuter les conteneurs. Il s'occupe des opérations bas niveau (création d'un conteneur, configuration des espaces de noms, monter un conteneur, etc). Il est utilisé par Docker et Kubernetes. Cela signifie que les failles de runC impactent ces deux plateformes. Les CVE-2025-31133 et CVE-2025-52881 concernent TOUTES les versions de runC. La 3e impacte les versions 1.2.8, 1.3.3 et 1.4.0rc3...Ces CVE ont un score de 7,3 : cela signifie une criticité haute. Pour résumer l'impact de chaque vulnérabilité :CVE-2025-31133 : un hacker peut remplacer /dev/null par un symlink durant la phase d'initiation du conteneur et il peut prendre le contrôle d'une target en lecture-seule depuis le conteneur compromisCVE-2025-52565 : cette faille concerne /dev/console. Le hacker peut remplacer un chemin cible pour un symlink et peut provoquer un montage compromis et fournir un accès à procfsCVE-2025-52881 : tromper runC pour qu'il puisse écrire dans /proc une redirection vers une cible compromise. Cette faille contourne les protections LSM pour faire une écrire arbitraire dans des fichiers sensibles tels que /proc/sysrq-trigger"Malheureusement, les correctifs sont assez volumineux car ils ont nécessité un important travail de développement sur github.com/cyphar/filepath-securejoin ainsi que des modifications importantes de runc. Je recommande donc d'utiliser les versions publiées." commente Aleksa. L'ingénieur ajoute que le correctif est assez imposant car il cible toutes les CVE. Annonce des failles : https://seclists.org/oss-sec/2025/q4/138Catégorie actualité: SécuritéDocker, KubernetesImage actualité AMP: