Posté par antistress (site web personnel) .
Évalué à 3 (+0/-0).
Dernière modification le 28 septembre 2024 à 17:48.
even if you only write new code in a memory-safe language, while only applying bug fixes to old code, the number of memory safety issues will decreases rapidly, even when the total amount of code written in unsafe languages increases. This is because vulnerabilities decay exponentially – in other words, the older the code, the fewer vulnerabilities it’ll have.
Posté par antistress (site web personnel) .
Évalué à 8 (+5/-0).
Dernière modification le 29 septembre 2024 à 00:53.
L'article explique que le fait de se concentrer sur le nouveau code, en choisissant pour celui-ci un langage memory-safe, permet à la totalité du projet d'atteindre un très grand niveau de sécurité.
Il relativise fortement l'intérêt de tout réécrire un projet
Java n'est certainement pas plus sûr que n'importe quel langage à garage collector… et il est une énorme source de fuite mémoire (par pointeur caché toujours présent) ce qui n'est pas memory safe.
En outre pour de multiples raison, Java est à fuir:
- licence et manœuvre d'oracle douteuse.
- JVM libre pas toujours parfaites et JVM autres excessivement chères.
- programmes excessivement complexes à déployer et maintenir.
- Plantages à l'exécution courants et complexe à debuguer (Surtout pour les non développeurs du soft)
A l'inverse Go à les même avantages sans les inconvénients.
Après pour les autres besoins ils existent d'autres langages (Rust, Python, JS, Julia, TypeScript… )
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
oui alors concernant les 2 derniers arguments, "programmes complexes" et "Plantages à l'exécution courants et complexe à debuguer", c'est vrai pour tous les soft mal écrits quelque soit le langage, Est-ce qu'on peut plus facilement écrire un mauvais code en java qu'en C, Go, python, js, lisp, perl,… ? ça dépend principalement de ce qui est entre le clavier et la chaise.
Et je ne vois pas un nom de quoi un non-developpeur devrait être capable de "debogguer" ça implique aussi l'écriture du patch ?
Perso, la première fois que j'ai vu une stack lors d'un crash d'un script python, je me suis gratté la tête quelques minutes pour comprendre dans quel sens il fallait lire (pareil en java du reste)
En Python les stack trace de plantages sont bien plus claires. Go je ne connais pas assez.
Un non développeur a souvent besoin de debuguer à l'install quand ça plante. Souvent ce n'est pas à proprement parler un bug mais un problème de configuration. (Librairie absente ou pas trouvé ou mauvaise version)
Et parlant configuration, la JVM est sans doute ce qui se fait de pire… (Go, Python ou Rust n'ont pas ce problème)
Après Python à un autre problème, ce sont les venv qui sont aussi complexe à analyser.
Pour toutes ces raisons je préfère Go pour remplacer Java: pas de dépendances. Ça juste marche.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
L'openjdk est libre, parfaitement fonctonnel et s'il faut bien sur toujours se méfier d'Oracle, il y a suffisamment de contributeurs et distributeurs pour forker en cas de coup fourré.
Je ne comprends pas ton histoire de pointeur caché 😀.
Go peut effectivement être considéré comme un Java léger.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
En fait les fuites mémoire par pointeurs "cachés" peuvent se produire dans tout langages. C'est quand tu libère un objet en pensant qu'il va être détruit alors qu'un pointeur quelque part continue de désigner l'objet… cela peut se produire dans des boucles qui peuvent finir par tout bouffer.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Jr ne connais pas ces langages mais si tu peux faire une boucle, ça doit être possible.
En pseudo code simpliste c'est:
B b = manager.
While true {
A a = New A
b.append(a)
# delete a
}
Si b garde quelque part une référence sur a, a ne sera jamais détruit.
Certains langages peuvent limiter ces problèmes. Mais Java le facilite par sa sur-utilisation du pointeur.
PS: Rust même sans Garbage collector n'est pas à l'abri mais en invitant à éviter les pointeurs (au profit de l'appartenance) limite beaucoup le problème.
En C tu vire toi même l'objet donc au pire tu fait un segfault mais il n'y a pas ce problème… si tu pense à le virer mais tu est obligé d'y penser.
PS2: on est d'accord c'est une erreur de conception du programme le langages ne peut pas tout comprendre. Mais Java est terrible pour ça car c'est "caché"
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
PS: Rust même sans Garbage collector n'est pas à l'abri mais en invitant à éviter les pointeurs (au profit de l'appartenance) limite beaucoup le problème.
En C tu vire toi même l'objet donc au pire tu fait un segfault mais il n'y a pas ce problème… si tu pense à le virer mais tu est obligé d'y penser.
PS2: on est d'accord c'est une erreur de conception du programme le langages ne peut pas tout comprendre. Mais Java est terrible pour ça car c'est "caché"
Je connais suffisamment chaque langage que tu cite pour avoir était payé pour en écrire (sauf rust mais je commence à avoir une base de code en rust tout de même) mais je comprends rien à ce que tu racompte
Si Google est passé de Java à Kotlin pour le développement d'Androïd c'est bien parce que l'on ne peut pas être vraiment serein en Java… alors exactement je ne connais pas tous les enjeux mais l'idée est là.
Même si OpenJDK est fonctionnel, il dispose des dernieres fonctionnalités en retard je crois. Mais effectivement la JVM n'est pas le plus gros pb.
Disons que c'est un ensemble d'éléments qui incite à fuir Java.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Posté par barmic 🦦 .
Évalué à 3 (+1/-0).
Dernière modification le 01 octobre 2024 à 23:43.
Même si OpenJDK est fonctionnel, il dispose des dernieres fonctionnalités en retard je crois.
OpenJDK c'est java, il fourni les sources comme linux.org fourni des sources et des gens se proposent de compiler et packager ça, on appel ça une distribution comme pour linux. Il y en a qui te font payé pour avoir du support et d'autres qui sont complètement libres et gratuites (certaines ne sont pas libres car elles ajoutent par exemple des polices non libre = mais comme ça ne vient pas d'OpenJDK ça ne fait pas parti de java tout comme ajouter Google Chrome dans une distribution linux ne rend pas linux non libre).
Si Google est passé de Java à Kotlin pour le développement d'Androïd
Je sais pas trop ce que tu entends par là. Google n'est jamais passé de Java à Android que ce soit pour AOSP lui-même qui est écris en C++ et Java (et maintenant ils intègrent du rust) et pour créer des applications ils ont annoncés que kotlin était supporté, au même titre que java. Pour ce qui est des applications Google sur Android ça je ne sais pas, mais ça n'a pas fait l'objet d'une annonce particulière pour l'ensemble de leur apps.
Du coup parler de fuir java ça demande d'être étayé.
JVM libre pas toujours parfaites et JVM autres excessivement chères.
programmes excessivement complexes à déployer et maintenir.
Plantages à l'exécution courants et complexe à debuguer (Surtout pour les non développeurs du soft)
Vraiment il y a un moment où il faut se mettre à la page si tu veux troller sur un sujet. On a arrêter de parler de la licence de Qt, on doit pouvoir arrêter de parler de problèmes qui n'existent plus depuis 15 ans, non ?
Je parle bien sûr pour les 2 premiers points les 2 d'après n'ont simplement pas de sens.
Je m'interroge sur la pertinence de l'argument dans le cadre du noyau Linux et de l'introduction de Rust. En gros l'argument est que le vieux code (maintenu) a vu l'essentiel des bugs et vulnérabilités éliminées au cours du temps, et qu'en écrivant le nouveau dans des langage sur on insère pas de vulnérabilité mémoire, donc c'est plutôt gagnant.
Dans le cadre particulier de Linux et Rust par contre il semble que l'introdution de Rust impose de réécrire certaines parties du code en C. On pourrait alors arguer que ce soit à double tranchant : d'un côté c'est pour le meilleur parce que Rust est safe, et que la réécriture impose certaines contraintes de Rust et imposent de meilleures propriétés au code, d'un autre … c'est une réécriture de code potentiellement éprouvé donc qui risque d'introduire de nouveaux problèmes, un peu à rebours des arguments de l'article.
C'est pas une simple corrélation ils ont une explication avec, qui tient la route. Si tu veux réfuter le truc il faut réfuter l'explication aussi. Le cas de Linux est sûrement particulier parce que c'est du code bas niveau qui vient avec son propre gestionnaire de mémoire et qu'il y a beaucoup de systèmes bas niveau à toucher, ce qui prend du temps, c'est les débats actuels, et c'est pourquoi qu'ils ont commencés des expérimentations avec des pilotes qui sont potentiellement moins au cœur du système.
Donc c'est une problématique, qui fait débat certes, un questionnement, mais comme dit le commentaire au dessous c'est probablement plus un problème de transition qu'une réfutation de l'intérêt de la démarche pour la sécurité. Et quand bien même ça le ferait pas pour Linux, c'est potentiellement juste un cas particulier.
Je n'ai pas relu attentivement l'artcicle que je cite, mais je ne me rapelle pas y avoir vu une démonstration. Au contraire, il part de la conclusion attendue et essaie d'y faire coller les faits en montrant une simple corrélation.
Bien sûr mais on peut supposer que c'est temporaire et minoritaire… dans tous les cas on aurait rajouter du code…
Ce qu'il y a c'est que pour Linux on continue les 2 développements en //. Alors comme certaines fonctionnalités sont développés en C alors qu'elles pourraient l'être en Rust on est plutôt dans le cas dénoncé.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# TL;DR
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 28 septembre 2024 à 17:48.
# Java !
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+4/-2).
Il faut donc tout réécrire en Java qui est le plus mémoire sûr des langages modernes !
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java !
Posté par antistress (site web personnel) . Évalué à 4 (+1/-0).
Au delà de ta boutade, l'article dit le contraire. Merci pour ta participation !
[^] # Re: Java !
Posté par Dr BG . Évalué à 4 (+2/-0).
Je ne vois pas où ils disent le contraire. J'ai loupé quelque chose ?
[^] # TL;DR in french
Posté par antistress (site web personnel) . Évalué à 8 (+5/-0). Dernière modification le 29 septembre 2024 à 00:53.
L'article explique que le fait de se concentrer sur le nouveau code, en choisissant pour celui-ci un langage memory-safe, permet à la totalité du projet d'atteindre un très grand niveau de sécurité.
Il relativise fortement l'intérêt de tout réécrire un projet
[^] # Re: Java !
Posté par Christophe . Évalué à 10 (+12/-1).
Forcément, une fois que tu as alloué toute la mémoire à la VM, il n'y a plus la place pour une fuite !
[^] # Re: Java !
Posté par Letho . Évalué à 3 (+2/-0). Dernière modification le 29 septembre 2024 à 19:54.
Bon. J'aime beaucoup Java. Mais j'ai ri quand même.
[^] # Re: Java !
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+4/-4). Dernière modification le 28 septembre 2024 à 23:19.
Java n'est certainement pas plus sûr que n'importe quel langage à garage collector… et il est une énorme source de fuite mémoire (par pointeur caché toujours présent) ce qui n'est pas memory safe.
En outre pour de multiples raison, Java est à fuir:
- licence et manœuvre d'oracle douteuse.
- JVM libre pas toujours parfaites et JVM autres excessivement chères.
- programmes excessivement complexes à déployer et maintenir.
- Plantages à l'exécution courants et complexe à debuguer (Surtout pour les non développeurs du soft)
A l'inverse Go à les même avantages sans les inconvénients.
Après pour les autres besoins ils existent d'autres langages (Rust, Python, JS, Julia, TypeScript… )
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Java !
Posté par jigso . Évalué à 3 (+1/-0).
oui alors concernant les 2 derniers arguments, "programmes complexes" et "Plantages à l'exécution courants et complexe à debuguer", c'est vrai pour tous les soft mal écrits quelque soit le langage, Est-ce qu'on peut plus facilement écrire un mauvais code en java qu'en C, Go, python, js, lisp, perl,… ? ça dépend principalement de ce qui est entre le clavier et la chaise.
Et je ne vois pas un nom de quoi un non-developpeur devrait être capable de "debogguer" ça implique aussi l'écriture du patch ?
Perso, la première fois que j'ai vu une stack lors d'un crash d'un script python, je me suis gratté la tête quelques minutes pour comprendre dans quel sens il fallait lire (pareil en java du reste)
[^] # Re: Java !
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+2/-1).
C'est surtout le (re)lire qui est problématique 😀.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java !
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1 (+2/-2).
En Python les stack trace de plantages sont bien plus claires. Go je ne connais pas assez.
Un non développeur a souvent besoin de debuguer à l'install quand ça plante. Souvent ce n'est pas à proprement parler un bug mais un problème de configuration. (Librairie absente ou pas trouvé ou mauvaise version)
Et parlant configuration, la JVM est sans doute ce qui se fait de pire… (Go, Python ou Rust n'ont pas ce problème)
Après Python à un autre problème, ce sont les venv qui sont aussi complexe à analyser.
Pour toutes ces raisons je préfère Go pour remplacer Java: pas de dépendances. Ça juste marche.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Java !
Posté par devnewton 🍺 (site web personnel) . Évalué à 8 (+5/-0).
L'openjdk est libre, parfaitement fonctonnel et s'il faut bien sur toujours se méfier d'Oracle, il y a suffisamment de contributeurs et distributeurs pour forker en cas de coup fourré.
Je ne comprends pas ton histoire de pointeur caché 😀.
Go peut effectivement être considéré comme un Java léger.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Java !
Posté par abriotde (site web personnel, Mastodon) . Évalué à -1 (+1/-3).
En fait les fuites mémoire par pointeurs "cachés" peuvent se produire dans tout langages. C'est quand tu libère un objet en pensant qu'il va être détruit alors qu'un pointeur quelque part continue de désigner l'objet… cela peut se produire dans des boucles qui peuvent finir par tout bouffer.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Java !
Posté par Pol' uX (site web personnel) . Évalué à 4 (+2/-0).
T'as un exemple de à quoi ça pourrait ressembler en caml ou bien en haskell ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Java !
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+0/-1).
Jr ne connais pas ces langages mais si tu peux faire une boucle, ça doit être possible.
En pseudo code simpliste c'est:
Si b garde quelque part une référence sur a, a ne sera jamais détruit.
Certains langages peuvent limiter ces problèmes. Mais Java le facilite par sa sur-utilisation du pointeur.
PS: Rust même sans Garbage collector n'est pas à l'abri mais en invitant à éviter les pointeurs (au profit de l'appartenance) limite beaucoup le problème.
En C tu vire toi même l'objet donc au pire tu fait un segfault mais il n'y a pas ce problème… si tu pense à le virer mais tu est obligé d'y penser.
PS2: on est d'accord c'est une erreur de conception du programme le langages ne peut pas tout comprendre. Mais Java est terrible pour ça car c'est "caché"
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Java !
Posté par barmic 🦦 . Évalué à 3 (+1/-0).
Je connais suffisamment chaque langage que tu cite pour avoir était payé pour en écrire (sauf rust mais je commence à avoir une base de code en rust tout de même) mais je comprends rien à ce que tu racompte
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Java !
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+3/-4).
Si Google est passé de Java à Kotlin pour le développement d'Androïd c'est bien parce que l'on ne peut pas être vraiment serein en Java… alors exactement je ne connais pas tous les enjeux mais l'idée est là.
Même si OpenJDK est fonctionnel, il dispose des dernieres fonctionnalités en retard je crois. Mais effectivement la JVM n'est pas le plus gros pb.
Disons que c'est un ensemble d'éléments qui incite à fuir Java.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Java !
Posté par barmic 🦦 . Évalué à 3 (+1/-0). Dernière modification le 01 octobre 2024 à 23:43.
OpenJDK c'est java, il fourni les sources comme linux.org fourni des sources et des gens se proposent de compiler et packager ça, on appel ça une distribution comme pour linux. Il y en a qui te font payé pour avoir du support et d'autres qui sont complètement libres et gratuites (certaines ne sont pas libres car elles ajoutent par exemple des polices non libre = mais comme ça ne vient pas d'OpenJDK ça ne fait pas parti de java tout comme ajouter Google Chrome dans une distribution linux ne rend pas linux non libre).
Je sais pas trop ce que tu entends par là. Google n'est jamais passé de Java à Android que ce soit pour AOSP lui-même qui est écris en C++ et Java (et maintenant ils intègrent du rust) et pour créer des applications ils ont annoncés que kotlin était supporté, au même titre que java. Pour ce qui est des applications Google sur Android ça je ne sais pas, mais ça n'a pas fait l'objet d'une annonce particulière pour l'ensemble de leur apps.
Du coup parler de fuir java ça demande d'être étayé.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Java !
Posté par barmic 🦦 . Évalué à 7 (+5/-0).
Vraiment il y a un moment où il faut se mettre à la page si tu veux troller sur un sujet. On a arrêter de parler de la licence de Qt, on doit pouvoir arrêter de parler de problèmes qui n'existent plus depuis 15 ans, non ?
Je parle bien sûr pour les 2 premiers points les 2 d'après n'ont simplement pas de sens.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# Le noyau Linux et cette approche
Posté par Thomas Douillard . Évalué à 5 (+3/-1).
Je m'interroge sur la pertinence de l'argument dans le cadre du noyau Linux et de l'introduction de Rust. En gros l'argument est que le vieux code (maintenu) a vu l'essentiel des bugs et vulnérabilités éliminées au cours du temps, et qu'en écrivant le nouveau dans des langage sur on insère pas de vulnérabilité mémoire, donc c'est plutôt gagnant.
Dans le cadre particulier de Linux et Rust par contre il semble que l'introdution de Rust impose de réécrire certaines parties du code en C. On pourrait alors arguer que ce soit à double tranchant : d'un côté c'est pour le meilleur parce que Rust est safe, et que la réécriture impose certaines contraintes de Rust et imposent de meilleures propriétés au code, d'un autre … c'est une réécriture de code potentiellement éprouvé donc qui risque d'introduire de nouveaux problèmes, un peu à rebours des arguments de l'article.
[^] # Re: Le noyau Linux et cette approche
Posté par Voltairine . Évalué à 3 (+2/-0).
Je suis également dubitative. Rappellons que cet argument vient de Gooogle pour le développement d'Android :
https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
Il faut aussi se méfier des corrélations, cela ne démontre pas une relation de cause à effet.
[^] # Re: Le noyau Linux et cette approche
Posté par Thomas Douillard . Évalué à 3 (+1/-1).
C'est pas une simple corrélation ils ont une explication avec, qui tient la route. Si tu veux réfuter le truc il faut réfuter l'explication aussi. Le cas de Linux est sûrement particulier parce que c'est du code bas niveau qui vient avec son propre gestionnaire de mémoire et qu'il y a beaucoup de systèmes bas niveau à toucher, ce qui prend du temps, c'est les débats actuels, et c'est pourquoi qu'ils ont commencés des expérimentations avec des pilotes qui sont potentiellement moins au cœur du système.
Donc c'est une problématique, qui fait débat certes, un questionnement, mais comme dit le commentaire au dessous c'est probablement plus un problème de transition qu'une réfutation de l'intérêt de la démarche pour la sécurité. Et quand bien même ça le ferait pas pour Linux, c'est potentiellement juste un cas particulier.
[^] # Re: Le noyau Linux et cette approche
Posté par Voltairine . Évalué à 1 (+0/-0).
Je n'ai pas relu attentivement l'artcicle que je cite, mais je ne me rapelle pas y avoir vu une démonstration. Au contraire, il part de la conclusion attendue et essaie d'y faire coller les faits en montrant une simple corrélation.
[^] # Re: Le noyau Linux et cette approche
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+2/-1).
Bien sûr mais on peut supposer que c'est temporaire et minoritaire… dans tous les cas on aurait rajouter du code…
Ce qu'il y a c'est que pour Linux on continue les 2 développements en //. Alors comme certaines fonctionnalités sont développés en C alors qu'elles pourraient l'être en Rust on est plutôt dans le cas dénoncé.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.