3- log4j est maintenu par 4 honorable personnes contributrices
Ce qui est plutôt beaucoup pour ce genre de bibliothèques très ciblées. Des tonnes de bibliothèques beaucoup plus grosses sont maintenues par quelques personnes sur leur temps libre. Le développeur principal de Jackson (bibliothèque JSON et bien plus quasi omniprésente dans le monde Java) par exemple travaille dessus sur son temps libre. C'est le cas de bien d'autres projets Open Source.
Et même quand ce n'est pas sur le temps libre, il y a souvent très peu de contributeurs et beaucoup de choses à faire.
Ensuite, peu de développeurs sont sensibilisés à la sécurité. Et même dans ce cas, quand tu vois arriver une pull request avec un truc qui peut être pratique pour les gens, tu ne prends pas toujours le recul nécessaire pour te rendre compte des conséquences. Bien souvent les problèmes de sécurité sont amenés comme ça : une fonctionnalité qui a l'air pratique alors pourquoi pas... et boum deux ans après quelqu'un se rend compte qu'il y a une faille évidente.
Maven en question ?
Ben non, justement. Maven a tout un tas de mécanismes pour corriger ce problème très simplement.
Beaucoup d'entreprises ont des proxies Maven que tous les builds utilisent pour récupérer les dépendances : elles peuvent bannir les anciennes versions directement sur le proxy.
Je pense aussi que beaucoup d'entreprises ont un pom parent et il est facile via une directive dependencyManagement de forcer la version de log4j - alors ce ne sera pas exactement forcé car si un projet la déclare explicitement, la version explicite prend le pas, mais ça enlève au moins toute la partie "une vieille dépendance dépend d'une vieille version de ce truc". Mais pour ça, tu peux utiliser l'enforcer plugin pour bannir des dépendances.
Il y a aussi tout un tas de gens qui ont développé des agents pour réécrire le code à la volée.
Log4j 2 est loin d'être la pire dépendance pour ce genre de problèmes car l'API est assez récente et assez stable donc la mise à jour très facile. Ca aurait pu être bien pire (genre nécessiter des changements d'API dans tous les sens pour que des vieux trucs non maintenus puissent encore fonctionner).
Un point qui me chagrine est que chaque fois qu'il y a une faille, on dirige plein d'argent et plein de recherche sur le projet qui a posé souci et on perd de vue que c'est un problème général. Tous les jours, on utilise du code Open Source dont on a absolument aucune idée du contenu (le problème est le même pour le code proprio mais on l'utilise moins facilement). On espère que les gens qui le développent savent ce qu'ils font et sont sérieux et honnêtes. Ben pour l'instant, on a eu globalement du bol. Est-ce que ça va durer ?
Et j'attends avec une impatience toute relative la première GitHub Action non officielle utilisée largement qui sera reprise par un mainteneur peu scrupuleux et qui injectera du code un peu partout dans tous les repositories qui l'utilisent. Ca va être extrêmement sympathique.
# Ca vaut ce que ça vaut mais...
Posté par Guillaume Smet (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 10.
Ce qui est plutôt beaucoup pour ce genre de bibliothèques très ciblées. Des tonnes de bibliothèques beaucoup plus grosses sont maintenues par quelques personnes sur leur temps libre. Le développeur principal de Jackson (bibliothèque JSON et bien plus quasi omniprésente dans le monde Java) par exemple travaille dessus sur son temps libre. C'est le cas de bien d'autres projets Open Source.
Et même quand ce n'est pas sur le temps libre, il y a souvent très peu de contributeurs et beaucoup de choses à faire.
Ensuite, peu de développeurs sont sensibilisés à la sécurité. Et même dans ce cas, quand tu vois arriver une pull request avec un truc qui peut être pratique pour les gens, tu ne prends pas toujours le recul nécessaire pour te rendre compte des conséquences. Bien souvent les problèmes de sécurité sont amenés comme ça : une fonctionnalité qui a l'air pratique alors pourquoi pas... et boum deux ans après quelqu'un se rend compte qu'il y a une faille évidente.
Ben non, justement. Maven a tout un tas de mécanismes pour corriger ce problème très simplement.
Beaucoup d'entreprises ont des proxies Maven que tous les builds utilisent pour récupérer les dépendances : elles peuvent bannir les anciennes versions directement sur le proxy.
Je pense aussi que beaucoup d'entreprises ont un pom parent et il est facile via une directive dependencyManagement de forcer la version de log4j - alors ce ne sera pas exactement forcé car si un projet la déclare explicitement, la version explicite prend le pas, mais ça enlève au moins toute la partie "une vieille dépendance dépend d'une vieille version de ce truc". Mais pour ça, tu peux utiliser l'enforcer plugin pour bannir des dépendances.
Il y a aussi tout un tas de gens qui ont développé des agents pour réécrire le code à la volée.
Log4j 2 est loin d'être la pire dépendance pour ce genre de problèmes car l'API est assez récente et assez stable donc la mise à jour très facile. Ca aurait pu être bien pire (genre nécessiter des changements d'API dans tous les sens pour que des vieux trucs non maintenus puissent encore fonctionner).
Un point qui me chagrine est que chaque fois qu'il y a une faille, on dirige plein d'argent et plein de recherche sur le projet qui a posé souci et on perd de vue que c'est un problème général. Tous les jours, on utilise du code Open Source dont on a absolument aucune idée du contenu (le problème est le même pour le code proprio mais on l'utilise moins facilement). On espère que les gens qui le développent savent ce qu'ils font et sont sérieux et honnêtes. Ben pour l'instant, on a eu globalement du bol. Est-ce que ça va durer ?
Et j'attends avec une impatience toute relative la première GitHub Action non officielle utilisée largement qui sera reprise par un mainteneur peu scrupuleux et qui injectera du code un peu partout dans tous les repositories qui l'utilisent. Ca va être extrêmement sympathique.