allcolor a écrit 1778 commentaires

a supporter windows et linux

Linux n'est pas un fork de windows.

effectivement a les forcer a forker et supporter un OS seuls, ce qui augmente enormement leurs couts et rend la vente de smartphones Android a prix concurrentiel impossible.

Ben acer veut utiliser un fork… ben ils doivent assumer dans ce cas.

Pourquoi google devrait les aider à supporter android et en même temps le fork. Que Alibaba le fasse avec acer.

Parce que sinon c'est facile pour Alibaba qui propose le fork tout en laissant le support du fork et de l'original à google.

Reste l'option de tuer le process, ça devrait libérer la mémoire… puis faire des trucs avec le pointeur NULL y a des chances qu'a un endroit ou l'autre ça segfault… ce qui libérera la ram… bon je ===>[]

si j'ai bien suivi

Apparemment non, tu confonds udev et dbus dejà…

on a quoi d'autre de plus haut niveau ?

Plein des trucs, par exemple:

http://jmonkeyengine.org/
http://www.crystalspace3d.org/main/Main_Page
http://www.ogre3d.org/
http://www.panda3d.org/

etc…

Si on regarde en java 7, getField est public dans SunToolkit, http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/awt/SunToolkit.java

Alors qu'en java 6, c'est private:

http://javasourcecode.org/html/open-source/jdk/jdk-6u23/sun/awt/SunToolkit.java.html

C'est une aberration ce changement… sans ça, même en loadant SunToolkit, y aurait pas eu la vulnérabilité.

Oracle Java 1.7 provides an execute() method for Expression objects, which can use reflection to bypass restrictions to the sun.awt.SunToolkit getField() function, which operates inside of a doPrivileged block. The getField() function also uses the reflection method setAccessible() to make the field accessible, even if it were protected or private. Because sun.awt.SunToolkit is public, it can be called from anywhere.

Donc c'est la combinaison d'un bug dans Expression + le setAccessible de getField dans sun.awt.SunToolkit (qui est éxécuté sous le domaine de sécurité de Expression et non de l'applet) qui permet ce bug.

C'est quand même énorme d'avoir laissé passer ça.

Ben tu fournis un lien dans ton journal qui pointe sur le source…

cf:
http://eromang.zataz.com/2012/08/27/java-7-applet-rce-0day-gondvv-cve-2012-4681-metasploit-demo/

Là tu as source code : http://pastie.org/pastes/4594319/text

Si on veut analyser la chose il faut d'abord la récupérer, ensuite la décompacter et enfin la décompiler.

On s'en fout du payload exécuté (et chargé) c'est fait après la faille, la faille est utilisée par l'applet qui enlève le securitymanager… Après ça il peut exécuter/downloader/pouet ce qu'il veut avec les droits de l'utilisateur.

lui donne tous les droits (entre autre sur file://)

file:// c'est juste une url valide pour mettre la provenance du code executable associé au domaine de sécurité, à mon avis n'importe quel url valide fait l'affaire.

La faille semble plutôt être que la classe "sun.awt.SunToolkit" possède une méthode getField (large et pas seulement limitée à elle-même, ie: renvoi un field de n'importe quel classe) accessible sur laquelle aucune vérification du callstack n'est faite.

Ça se discute…

Je parle ici d'un fait réel, c'est une imprimante laser, ce n'est pas des cartouches mais un toner… et je ne vois pas ce qu'un toner vide peut provoquer comme dommage au mécanisme à part la mauvaise foi. Ce genre de réglage est là uniquement pour pousser à l'achat de nouveau toner après x feuilles imprimées et pas pour une raison de sécurité ou de maintient des mécanismes d'impression.

Sinon tu achètes une imprimante laser qui a une durée de vie plus longue et coût moins cher pour des impressions en grande quantité dans le temps

J'ai une HP 1515n et dans la config par défaut, il y a un compteur de page qui bloque l'impression et demande de changer le toner d'encre en indiquant qu'il n'y a plus d'encre… et impossible d'imprimer, sauf en allant dans un sous-sous-sous menu de la configuration et indiquer d'ignorer 'ink level' et à ce moment là l'imprimante laisse imprimer (ce point n'est pas indiqué dans la documentation) en ayant ce réglage, j'ai pû encore imprimer 400 feuilles correctement encrées. L'utilisateur lambda qui ne sait pas comment changer cette configuration par défaut (bloquage), va aller acheter un nouveau toner alors qu'il n'en faut un nouveau que bien plus tard lorsque le toner est vraiment vide. Ce genre de réglage est je trouve une honte et abusif qui pousse à la surconsommation.

Il faut que le constructeur me laisse décider moi-même si le niveau d'encrage est trop faible et ne me force pas la main… un toner doit se remplacer quand il est vide et pas avant (et pas quand HP le décide)

Non c'est de la pub qui s'affiche dans la fenêtre principal de skype… et ça ne le fait que si tu n'a pas de thunes sur le compte skype.

C'est pas toi qui risque de gagner le prix Nobel de l'orthographe…

L'éducation naziogauchiste que tu as reçu doit être très mauvaise.

Je trouve ton commentaire insultant pour les devs, car tu supposes qu'ils n'ont pas été capable de faire quelque chose de trivial et que tu ne t'es pas donné la peine de chercher ou de simplement t'abstenir de juger sur des faits non avérés.

Pour le fait de ne pas avoir chercher c'est sûr, pour le fait que ma question soit insultante soit… peut-être entre les lettres alors. Pour le fait que forcément ils ont forcément fait cette chose trivial, avec tout ce que j'ai vu dans plein de projets, ça ne semble pas irréaliste qu'ils ne l'aient pas fait. Je me suis fié au journal et au commentaire de départ, en supposant erronément que ce devoir de recherche avait été effectué… mal m'en a pris.

Je ne bash pas un projet, je pose une question…

Je n'ai pas été impoli, toi par contre… et pas la peine de me moinsser pour te le faire remarquer.

Je me fie à ce journal, j'ai pas été voir, le journal donne à penser que c'était pas le cas… Mais ça ne te dispense pas de la politesse quand même.

Et dans ce cas si certains ne veulent pas de systemd peut-être faudrait-il qu'ils proposent autre chose de mieux

Mais pourquoi ne pas passer par une abstraction (quitte à ce que l'API d'abstraction soit du 1-1 vers l'API systemd pour ce genre d'appel)… ce qui fait qu'il n'y aurait qu'a implémenter l'API d'abstraction (gnome) pour chaque système différent et pas porter entièrement systemd… de plus je trouve un peu choquant qu'un DM impose un init particulier, on se croirait sur windows là.

Cela est vrai si seulement elle reste pour toujours une arme de dissuasion… Il suffit d'une utilisation pour avoir un énorme risque d'escalade. Faire confiance à tout jamais qu'une telle arme ne soit utilisée qu'en dissuasion est un acte de foi que je ne suis pas prêt à faire… Je suis très loin d'être sûr que l'obtention de l'arme nucléaire par l'iran soit un gage de stabilité, le risque d'escalade me semble important.

Le truc c'est que je peux très bien avoir un code, une lib, qui contient différents modules. Avec chacun des injections différentes.

Pareil avec Spring, vu qu'il suffit dans la config soit de mettre des exclusions ou de scanner des packages différents, soit de qualifié l'annotation autowired/

http://static.springsource.org/spring/docs/2.5.x/api/org/springframework/beans/factory/annotation/Qualifier.html

Dans mon code appelant, je peux injecter Searches et en l'annotant différement j'aurai l'une ou l'autre des implémentations.

Pareil avec Spring, tu fais un :

@Service("cache") 
...
@Service("nocache")
...

et pour l'endroit ou c'est injecté :

@Autowired
@Qualifier("cache")
...

@Autowired
@Qualifier("nocache")
...

Enfin, à ce que je vois spring est plus ancien (ça vaut ce que ça vaut), permet tout ce que fais guice et plus et est plus "connu"… à priori, je vais rester sur spring ;-)

Déjà, l'xml de configuration plus je peux m'en passer mieux je me porte.

Tu peux t'en passer en spring (avec les annotations justement et l'autoconfig).

Entre

    <bean id="customerDAO" class="xxx.yyy.zzz.CustomerDAOImpl"></bean>
    <bean id="customerService" class="xxx.yyy.zzz.CustomerServiceImpl"
      p:customerDAO-ref="customerDAO">
    </bean>

et

bind(CustomerDAO.class).to(CustomerDAOImpl.class).in(Scopes.SINGLETON);

Ben en spring je fais comme ceci:

package xxx.yyy.zzz;
@Service("monService")
public class CustomerServiceImpl implements CustomerService {
   @Autowired
   private CustomerDAO customerDAO;
   ...
}

package xxx.yyy.zzz;
@Service("monDao")
public class CustomerDaoImpl implements CustomerDao {
   ...
}


public class MaClassQuiUtiliseUnService {
   @Autowired
   private CustomerService customerService;
   ...
}

Et dans l'xml spring, la seule chose que tu mets c'est ceci:

<context:annotation-config/>
    <!-- pour chaque package que tu veux scanner -->
<context:component-scan  base-package="xxx.yyy.zzz">
    <context:include-filter type="aspectj" expression="xxx.yyy.zzz.**" />
</context:component-scan>

Et c'est tout.

En plus avec spring, tu as la gestion des transaction (avec les annotations @Transactional) et encore bien d'autres trucs très pratique.

Qu'est-ce que ça apporte par rapport à spring ? J'utilise spring depuis des années et ça me semble bien plus puissant et ça n'a pas besoin de javaEE.

A première vue, je préfère largement les @Service et @autowired de spring que ce que je vois dans Guice…

Va trouver du boulot, en 2 jours tu as fait 83 commentaires (sans compter les 14 commentaires de l'autre compte parlatonprolo) totalement inutiles, déplacés, insultants et bêtes.

Ta moyenne méritée de -10 devrait t'indiquer que tu perds ton temps (et ton argent), et que si tu en veux (de l'argent) faut bosser et pas troller comme un porc sur dlfp.

Sans doute en France mais la France ne représente pas toute la francophonie et ailleurs c'est accepté. Que ça le choque 'rentrer' dans le sens d'entrer ça ne changera pas son usage accepté comme synonyme (en dehors de France en tous les cas).