yAroTweet » Java - Page 1

Ce sujet est issu d\'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d\'origine, merci de cliquer sur ce lien

J'utilise régulièrement un uploadeur de photos en Java sur un site où j'ai mes habitudes. Comme toujours, je reçois un popup de Java me prévenant que l'application peut comporter des risques pour la sécurité à leur permettre cet upload, sauf que contrairement à d'habitude le message signalant le risque est en ROUGE.
Je suppose que cela vient de la dernière mise à jour. Oracle ne plaisante vraiment pas avec la sécurité de leur produit.

conseil a tous, désactivez le plugin java de tous vos navigateurs et ne prenez aucun risque. Au boulot on classe les problèmes actuels du plugin java à "très grave".

Au contraire, l'exécution de programmes java type netbeans/eclipse ne présente aucun risque, au moins connu

Tu veux dire qu'il faut décocher "Activer Javascript" dans Fx ? Ca coupe une patte au browser, ça

non, java!

Si même squalyl recommande de désactiver Java, c'est que ça va vraiment mal

Ouais bah c'est un vrai souci quand les deux applications critiques de votre structure sont des applis Java accessibles uniquement en web depuis un serveur d'application Oracle...

Oracle recommande de limiter l'utilisation du plugin java, c'est dire...

Quand je pense... je me demande si OpenJDK est plus sécurisé que l'implémentation officielle (qui d'après la doc Ubuntu, est libre à 95% du code). Le problème est que le seul site pour lequel j'ai besoin de Java, et dont j'ai parlé au-dessus, ce site plante sur l'upload si j'utilise OpenJDK plutôt que Java. Say whaaaaaaaaaat

./209
Peut-être n'est ce pas simplement la faute d'Oracle, mais qu'ils reconnaissent qu'un navigateur possède trop de droits sur le système tout en étant accessible de l'extérieur. Des extensions vérolées pourraient-elles poser autant de problèmes ?

En même temps, Oracle, depuis qu'ils jouent aux super-héros ...

Tiens, je me demandais justement si IcedTea n'était pas mieux que le plug-in d'Oracle, du coup...

Meowcate (./210) :
Quand je pense... je me demande si OpenJDK est plus sécurisé que l'implémentation officielle (qui d'après la doc Ubuntu, est libre à 95% du code). Le problème est que le seul site pour lequel j'ai besoin de Java, et dont j'ai parlé au-dessus, ce site plante sur l'upload si j'utilise OpenJDK plutôt que Java. Say whaaaaaaaaaat

Attention, OpenJDK n'inclut pas de plugin pour les navigateurs; ni pour les applets, ni pour JavaWebStart. Il y a le plugin IcedTeaWeb qui gère les applets et aussi JavaWebStart, mais c'est une implémentation différente (contrairement au reste de OpenJDK qui est pratiquement le même code que la version propriétaire), donc si l'applet utilise quelque chose de pas très standard, ça pourrait poser problème. Cela dit, il y a aussi des applets qui vérifient l'identifiant du JRE et refusent de fonctionner si ce n'est pas exactement celui qu'ils ont testé.

Peut-être n'est ce pas simplement la faute d'Oracle, mais qu'ils reconnaissent qu'un navigateur possède trop de droits sur le système tout en étant accessible de l'extérieur.

Bah oui, plus on permet à un site web de faire, plus c'est dangereux. C'est bien pour ça qu'ActiveX a été pratiquement abandonné (c'était carrément la passoire! Du coup, tous les navigateurs non-IE ont refusé de l'implémenter), mais les applets Java ne sont qu'un cran en dessous.

Nil (./214) :
Tiens, je me demandais justement si IcedTea n'était pas mieux que le plug-in d'Oracle, du coup...

Probablement, mais il y a quand-même eu récemment pas mal de CVEs du plugin Java propriétaire qui ont aussi dû être corrigés dans IcedTeaWeb ou OpenJDK.

Kevin Kofler (./215) :
Cela dit, il y a aussi des applets qui vérifient l'identifiant du JRE et refusent de fonctionner si ce n'est pas exactement celui qu'ils ont testé.

Ça, c'est normal. Vu qu'un JRE7 est incompatible avec un JRE6, c'est la moindre des choses.
Ce qui devrait être VRAIMENT normal, d'ailleurs, c'est de pouvoir installer plusieurs plug-ins par navigateur et de pouvoir choisir par applet celui qu'on veut utiliser. Parce qu'en l'état actuel des choses, la non rétro-compatibilité de Java 7 avec Java 6 pose énormément de problèmes.

"Java, write once, run everywhere"

"As long as you have the good version."

Nil (./216) :

Kevin Kofler (./215) :
Cela dit, il y a aussi des applets qui vérifient l'identifiant du JRE et refusent de fonctionner si ce n'est pas exactement celui qu'ils ont testé.

Ça, c'est normal.

Non, ce ne l'est pas.

Vu qu'un JRE7 est incompatible avec un JRE6

C'est rétrocompatible dans 99,9% des cas, c'est-à-dire si l'applet est codé même approximativement correctement. Et si ce n'est pas le cas, il y a une erreur si et quand il y a un vrai problème et pas "tu n'as pas la même version que moi => ".

Ce qui devrait être VRAIMENT normal, d'ailleurs, c'est de pouvoir installer plusieurs plug-ins par navigateur et de pouvoir choisir par applet celui qu'on veut utiliser.

Mais je ne veux pas installer le plugin propriétaire juste parce que l'applet XYZ croit ne marcher avec rien d'autre qu'une version particulière et bourrée de trous de sécurité de ce plugin (alors que ce n'est en général même pas le cas).

Parce qu'en l'état actuel des choses, la non rétro-compatibilité de Java 7 avec Java 6 pose énormément de problèmes.

Il suffisait de respecter le standard et il n'y aurait pas ces problèmes. Les classes qui ont été retirées sont des classes internes qui n'ont jamais fait partie du standard et qui n'étaient déjà pas contenues dans OpenJDK 6 pour des raisons de licence.

(J'aime bien JAVA, mais je vous lisais et je me disais : ça doit faire des années que je ne suis plus tombé sur une applet dans un site... alors à la rigueur... )

Kevin Kofler (./215) :
Cela dit, il y a aussi des applets qui vérifient l'identifiant du JRE et refusent de fonctionner si ce n'est pas exactement celui qu'ils ont testé.

Et heureusement, ça devrait être le comportement par défaut même ! Ils n'autorisent que les cibles testées, pour limiter les risques de plantage ou de sécurité. Après, si qqn pense que c'est à l'utilisateur d'essuyer les plâtres, c'est normal qu'il ne comprenne pas pourquoi on devrait se prémunir des comportements non souhaitables...

./220 carrément

Kevin Kofler (./216) :
Cela dit, il y a aussi des applets qui vérifient l'identifiant du JRE et refusent de fonctionner si ce n'est pas exactement celui qu'ils ont testé.

oui, ça s'appelle une "validation"

Kevin Kofler (./220) :
Mais je ne veux pas installer le plugin propriétaire juste parce que l'applet XYZ croit ne marcher avec rien d'autre qu'une version particulière et bourrée de trous de sécurité de ce plugin

et dans votre chouper truc, vous avez pas moyen de trifouiller le "user agent" ?

Kevin Kofler (./16) :
C'est rétrocompatible dans 99,9% des cas, c'est-à-dire si l'applet est codé même approximativement correctement. Et si ce n'est pas le cas, il y a une erreur si et quand il y a un vrai problème et pas "tu n'as pas la même version que moi => ".

Sauf que là où la compatibilité est cassée, c'est entre Oracle Forms & Reports dans un environnement Oracle 10g et Java 7 (théoriquement lié à Oracle 11g). Sauf que migrer un serveur d'application ne se fait pas "comme ça" (et faut-il que les applications supportent la migration).
C'est quand même dramatique que ça soit Oracle qui se tire une balle dans son propre pied. Du coup, aucune application Forms & Reports 10g ne fonctionne avec Java 7.

Kevin Kofler (./16) :
Mais je ne veux pas installer le plugin propriétaire juste parce que l'applet XYZ croit ne marcher avec rien d'autre qu'une version particulière et bourrée de trous de sécurité de ce plugin (alors que ce n'est en général même pas le cas).

Bah il suffirait que ton plug-in non propriétaire indique qu'il répond aux exigences de telle et telle version, je ne vois pas où tu as vu que je parlais de plug-in propriétaire...

squalyl (./19) :
oui, ça s'appelle une "validation"

Ça s'appelle une "sottise". C'est la même chose pour les sites web qui n'acceptent qu'une liste de navigateurs. Il n'y a aucune justification technique!

et dans votre chouper truc, vous avez pas moyen de trifouiller le "user agent" ?

Pas sans recompiler tout OpenJDK avec un patch.

Nil (./20) :

Kevin Kofler (./16) :
Mais je ne veux pas installer le plugin propriétaire juste parce que l'applet XYZ croit ne marcher avec rien d'autre qu'une version particulière et bourrée de trous de sécurité de ce plugin (alors que ce n'est en général même pas le cas).

Bah il suffirait que ton plug-in non propriétaire indique qu'il répond aux exigences de telle et telle version, je ne vois pas où tu as vu que je parlais de plug-in propriétaire...

Le comportement dont je me plains, c'est une vérification de la version exacte jusqu'au numéro d'update (comparaison de chaînes de caractères)!

Avoir un pop-up pour dire que l'application n'est pas qualifiée pour cette version de la JRE et qu'aucun support n'est fourni, ok. Ne pas s’exécuter pour çà, pas OK.

Pen^2 (./17) :
(J'aime bien JAVA, mais je vous lisais et je me disais : ça doit faire des années que je ne suis plus tombé sur une applet dans un site... alors à la rigueur... )

C'est encore le cas de pas mal d'applis pro, apparemment (faut plutôt voir ça comme une appli lourde distribuée par HTTP que comme un site web)