Dans ce cas, posons la question, est ce qu'il y avait besoin de log4j, si on suppose qu'on peut toujours faire sans certaines fonctions ?
Après tout, pourquoi ne pas rester à Println ou la lib par défaut de java ?
Quelqu'un a eu besoin de chaque bout de fonctionnalité ajouté à un moment. Quelqu'un l'a codé. Je suppose que c'est grosso modo tout ce qu'il faut.
La maintenance, c'est important, mais je sais aussi que dire "non", c'est en général assez peu populaire comme position, comme j'ai pu le voir sur le projet Ansible quand des modules ont été refusés, comme on a pu le voir lorsque que Debian a décidé de passer à systemd, ou les discussions sur les thèmes de GNOME.
Sans aller loin dans le passé, il suffit de voir il y a une semaine sur Linuxfr la discussion sur le manifest v3 et le fait de retirer des fonctionnalités en cadrant un peu mieux ce qui est faisable ou pas.
Dans le cas de log4j, le souci n'est pas forcément de rajouter le lookup jdni, car de ce que j'ai compris, c'était prévu pour être fait via la configuration sous le contrôle d'un admin. Avoir la configuration des logs centralisés dans LDAP via une syntaxe standard de Java, c'etait pas non plus déconnant.
La question d'activer jdni par défaut ou pas, c'est au niveau de la JVM, et pareil, je suppose que les devs de JVM ont du se dire "si quelqu'un utilise la fonction dans le code, alors c'est implicitement qu'il a besoin de l'utiliser".
On peut se poser la question de la gestion récursive des variables, mais je sais que j'ai déjà eu besoin de ça avec ansible, donc je suis assez sur que d'autres auraient pu en avoir besoin dans d'autres contextes, et qu'un dev aurait pu le rajouter en tout bonne foi.
Et pour l'usage de la réflexivité, je suppose que c'est un pattern important pour java (ou du moins, ça avait l'air important quand j'ai appris java).
Ensuite, il faut aussi rappeler que les lookups JDNI sont maintenant désactivés par défaut sur les JVM d'il y a moins de 3 ans (si je me souviens bien) et surtout qu'il existe un concept de sandbox dans la JVM depuis grosso modo toujours. Sandbox qui n'est semble t'il pas utilisé par la majorité des programmes, car ç'est long à coder. Et qui n'est pas activé par défaut, car ça n'aboutirais que à forcer les gens à retirer dés qu'un truc ne marche pas (cf les tutos partout qui commence par "il faut retirer selinux")
Alors, moins de fonctionnalité, sans doute que oui, mais il faut bien voir que dire "non", c'est mal vu, et que dire non ne retire pas le besoin, et qu'à un moment, tu va commencer à perdre des utilisateurs, puis des contributeurs, et le souci n'a fait que bouger ailleurs.
OpenBSD a moins de fonctions qu'une distro Linux. Mais curieusement, les distros Linux sont massivement plus utilisés.
[^] # Re: La vraie remise en question
Posté par Misc (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 5.
Dans ce cas, posons la question, est ce qu'il y avait besoin de log4j, si on suppose qu'on peut toujours faire sans certaines fonctions ?
Après tout, pourquoi ne pas rester à Println ou la lib par défaut de java ?
Quelqu'un a eu besoin de chaque bout de fonctionnalité ajouté à un moment. Quelqu'un l'a codé. Je suppose que c'est grosso modo tout ce qu'il faut.
La maintenance, c'est important, mais je sais aussi que dire "non", c'est en général assez peu populaire comme position, comme j'ai pu le voir sur le projet Ansible quand des modules ont été refusés, comme on a pu le voir lorsque que Debian a décidé de passer à systemd, ou les discussions sur les thèmes de GNOME.
Sans aller loin dans le passé, il suffit de voir il y a une semaine sur Linuxfr la discussion sur le manifest v3 et le fait de retirer des fonctionnalités en cadrant un peu mieux ce qui est faisable ou pas.
Dans le cas de log4j, le souci n'est pas forcément de rajouter le lookup jdni, car de ce que j'ai compris, c'était prévu pour être fait via la configuration sous le contrôle d'un admin. Avoir la configuration des logs centralisés dans LDAP via une syntaxe standard de Java, c'etait pas non plus déconnant.
La question d'activer jdni par défaut ou pas, c'est au niveau de la JVM, et pareil, je suppose que les devs de JVM ont du se dire "si quelqu'un utilise la fonction dans le code, alors c'est implicitement qu'il a besoin de l'utiliser".
On peut se poser la question de la gestion récursive des variables, mais je sais que j'ai déjà eu besoin de ça avec ansible, donc je suis assez sur que d'autres auraient pu en avoir besoin dans d'autres contextes, et qu'un dev aurait pu le rajouter en tout bonne foi.
Et pour l'usage de la réflexivité, je suppose que c'est un pattern important pour java (ou du moins, ça avait l'air important quand j'ai appris java).
Ensuite, il faut aussi rappeler que les lookups JDNI sont maintenant désactivés par défaut sur les JVM d'il y a moins de 3 ans (si je me souviens bien) et surtout qu'il existe un concept de sandbox dans la JVM depuis grosso modo toujours. Sandbox qui n'est semble t'il pas utilisé par la majorité des programmes, car ç'est long à coder. Et qui n'est pas activé par défaut, car ça n'aboutirais que à forcer les gens à retirer dés qu'un truc ne marche pas (cf les tutos partout qui commence par "il faut retirer selinux")
Alors, moins de fonctionnalité, sans doute que oui, mais il faut bien voir que dire "non", c'est mal vu, et que dire non ne retire pas le besoin, et qu'à un moment, tu va commencer à perdre des utilisateurs, puis des contributeurs, et le souci n'a fait que bouger ailleurs.
OpenBSD a moins de fonctions qu'une distro Linux. Mais curieusement, les distros Linux sont massivement plus utilisés.