Pourquoi mettre du sel dans les mots de passe des web apps ? Les mots de passe sont enregistrés en clair, sinon on ne peut pas l'envoyer par mail à l'utilisateur qui a répondu à ses « questions de sécurité. »
Mais bon, vu comment sont codées la plupart des applications, il est certainement plus facile d'entrer par XSS, injection SQL, hijack de session ou snif mail que par brute force sur les mots de passe... Je suis pour les châtiments corporels contre les devs qui pondent ce genre d'atrocités, mais mon chef m'a répondu qu'on aurait trop de pertes ;-)
Bien sûr, je comprends bien que ceux qui ont été confrontés à des militaires peuvent être choqués... Mais une armée ne se définit pas uniquement par ses armes. Le modèle peut aussi être simplement la structure, la hiérarchie, tout comme pour l'Armée du Salut.
Alors je ne suis pas pour un affrontement armé, mais le choix d'ODEBI me fait me poser la question sur la similitude entre « militaire » et « militant »...
Je pense que ce message ne m'était pas adressé, mais je vais quand même y répondre ;-)
Tout d'abord, ce n'est pas au dévelopeur de configurer le serveur d'applications. C'est l'architecte qui doit déterminer les modules nécessaire, et la configuration en est déduite directement par l'équipe d'exploitation. Bien sûr, les dévelopeurs (probablement uniquement les séniors) peuvent être consultés pour afiner l'architecture.
Sinon, si tu savais configurer JBoss ou JOnAS, je pense que tu aurais également quelques bases en lancement de JVM : Xmx fixe la taille maximale utilisable de mémoire. C'est Xms pour la mémoire au lancement ;-)
Enfin, on n'a pas besoin d'un serveur J2EE complet pour utiliser beaucoup de mémoire... Sur le projet qui m'exaspère le plus, on tourne sur du Tomcat, mais il y a tellement de couches rajoutées et extrèmement mal codées qu'en pratique la consommation mémoire explose (préchargement systématique d'instances utilisées uniquement en traitement mensuel ou annuel, codage non thread-safe imposant d'instancier systématiquement à chaque utilisation, sérialisation/désérialisation XML pour des messages locaux à l'application, utilisation de DOM pour les flux XML sus-nommés, réutilisation de code par copier/coller...)
Non, tous les développeurs Java ne pensent pas ça...
En fait, je dois dire que ça me désole quand je vois les goinfres de mémoire que je suis obligé de coder pour certains clients ! Mais tant qu'ils payent, je dois faire profil bas. Ça ne m'empêche pas en revanche de chercher à réduire l'empreinte mémoire et processeur sur les applications où on peut agir sur l'architecture.
En l'occurence, je me demande si ce "réseau des pirates" n'est pas une opération des majors pour apporter de l'eau à leur moulin, vu comment c'est mal ficelé.
Bah... je ne donnerai qu'un extrait du WHOIS : Registrant ID:tuiGTF39kRMWYHAC
Registrant Name:Jean Patate
Registrant Organization:Jean Patate
Registrant Street1:1 av des champs elyses
Registrant Street2:
Registrant Street3:
Registrant City:PAris
Registrant State/Province:
Registrant Postal Code:75008
Registrant Country:FR
Registrant Phone:+33.147474747
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:mlevypro@gmail.comJe crois qu'il n'y a rien à ajouter...
On peut encore améliorer la lisibilité des fichiers lilypond : avec un simple \include on peut utiliser les notes telles qu'on les connait (do, ré, mi...) plutôt que les lettres. Les altération sont alors d et b pour dièse et bémol, plutôt que is et es (je ne sais d'ailleurs pas lequel correspond à quoi...)
Juste une hypothèse, je n'utilise pas Nessus :
Peut-être que ça tournait déjà sur 64 bits, mais ce n'était pas possible de détecter les vulnérabilités où la cible est un système 64 bits.
Oui, mais pour pouvoir jeter la clef, il ne faut pas qu'elle ait été stoquée sur le FS ! Ou alors il faut chiffrer cette clef pour pouvoir jeter la nouvelle clef de chiffrement pour pouvoir oublier la première clef...
StackOverflowError at Brain (unknown location)
(oui, je sais, mon cerveau a une pile *très* limitée...)
Firefox n'est pas limité à l'affichage des pages HTML provenant du réseau... Etant donné que java est présent, ça peut être une bonne idée de proposer également la javadoc par exemple.
On peut espérer qu'ils ne passent pas par la couche ATA qui ne sert à rien, et qu'ils laissent le noyau gérer directement l'espace ! Sinon, à quoi ça sert que patrick_g nous fasse des super nouvelles sur le noyau si personne n'utilise ses nouvelles fonctionnalités ;-) (j'ai la flemme de rechercher, mais j'ai retenu que plusieurs FS étaient adaptés aux SSD sans couche de traduction ATA).
PS : le clavier du YeeLoong a la touche fn à droite de la touche ctrl, ce que je trouve pas du tout pratique .... ( http://sorbaioli.org/photos/lemote_yeeloong/hq/img-8.jpg )
C'est justement le contraire... Sinon, c'est juste une question d'habitude : pendant un moment mon portable pro était dans la même disposition (un IBM ThinkPad) et mon portable perso était dans l'autre (un Sony VAIO), et j'arrivais à ne pas trop me tromper.
Lors de la conférence qui a eu lieu il y a peu à Belfort, il a dit utiliser maintenant un prototype qui n'est pas actuellement disponible. Il a laissé entendre qu'il n'était pas basé sur une architecture i386, et donc pas un XO-1. À suivre...
Dans ce cas, c'est la page « normale » du site qui est trop lourde ! Une page principale devrait s'afficher quasi immédiatement, sinon le visiteur passera son chemin...
Moi, la question que je me pose, c'est comment il est possible qu'il n'y ait pas un seul commentaire sans faute de grammaire/orthographe ?
Y a un moment faut ptet revenir aux sources...
Globalement, je suis plutôt d'accord avec ceux qui trouvent que le DD doit discuter avec upstream avant de faire une modification qui peut être très sensible... et c'est ce qu'il a fait !
Le message a été posté sur openssl-dev, et contient à la fin, après avoir exposé ses découvertes avec Valgrind et les deux lignes incriminées (l'emphase est de moi) :
What I currently see as best option is to actually comment out
those 2 lines of code. But I have no idea what effect this
really has on the RNG. The only effect I see is that the pool
might receive less entropy. But on the other hand, I'm not even
sure how much entropy some unitialised data has.
What do you people think about removing those 2 lines of code?
Donc, contrairement à ce que je peux entendre un peu partout, le développeur savait qu'il y avait un impact sur l'entropie du générateur. Mais bon, je vous laisse parcourir le fil de discussion, il n'y a eu que trois réponses qui sont également en faveur de la suppression (mise en commentaire ou compilation conditionnelle) des deux lignes.
Je cite juste une partie de ta citation :
[...] autant que le lui permet l'état ou le profil de celle-ci.
Ça répond à ta question pour savoir s'il faut coller le bord du trottoir.
Oula... respire un bon coup et relis la discussion : tu mélanges plusieurs personnes !
La seule chose que je disais, c'est que lorsque tu es pris pour 1 ou 2 km/h de trop, en pratique sur le compteur la vitesse est largement supérieure à la vitesse autorisée. J'en ai marre des gens qui chouinent pour "rien du tout en trop"...
Je ne travaille pas pour les forces de l'ordre.
Je ne travaille pas dans les cinémomètres.
Je ne travaille pas pour la sécurité routière.
Je pense que les règles sont là pour être respectées. Il faut bien mettre une limite sinon on ne pénalise jamais... Tu aurais l'idée en parachutisme de retarder au maximum l'ouverture de la voile, puis te dire à 2m du sol que tu n'as pas besoin d'ouvrir pour une si petite hauteur ?
Sauf que les appareils de navigation style tomtom pratiquent une sur-évaluation du même ordre parce qu'ils sont dans la très grande majorité des cas utilisés en voiture. C'est pour cela que je disais de faire l'expérience avec un portable et GpsDrive...
Plus la tolérance du compteur... qui affichait alors une vitesse supérieure à 100km/h !
Pour ceux qui ont le matériel, une petite expérience est amusante : embarquez dans votre voiture un portable, un récepteur GPS et un GpsDrive entre les deux. La vitesse affichée à l'écran est systématiquement inférieure à celle du compteur, et pas uniquement de quelques unités...
[^] # Re: MD6
Posté par François B. . En réponse à la dépêche Rugby et cryptographie : Shabal est en demi-finale !. Évalué à 2.
Pourquoi mettre du sel dans les mots de passe des web apps ? Les mots de passe sont enregistrés en clair, sinon on ne peut pas l'envoyer par mail à l'utilisateur qui a répondu à ses « questions de sécurité. »
Mais bon, vu comment sont codées la plupart des applications, il est certainement plus facile d'entrer par XSS, injection SQL, hijack de session ou snif mail que par brute force sur les mots de passe... Je suis pour les châtiments corporels contre les devs qui pondent ce genre d'atrocités, mais mon chef m'a répondu qu'on aurait trop de pertes ;-)
[^] # Re: L'armée, c'est rigolo
Posté par François B. . En réponse à la dépêche La Ligue ODEBI lance un projet "d'armée numérique". Évalué à 1.
Est-ce pour autant qu'il ne faut rien faire ?
[^] # Re: L'armée, c'est rigolo
Posté par François B. . En réponse à la dépêche La Ligue ODEBI lance un projet "d'armée numérique". Évalué à 8.
Alors je ne suis pas pour un affrontement armé, mais le choix d'ODEBI me fait me poser la question sur la similitude entre « militaire » et « militant »...
[^] # Re: Passerelle Apache Felix?
Posté par François B. . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 1.
Tout d'abord, ce n'est pas au dévelopeur de configurer le serveur d'applications. C'est l'architecte qui doit déterminer les modules nécessaire, et la configuration en est déduite directement par l'équipe d'exploitation. Bien sûr, les dévelopeurs (probablement uniquement les séniors) peuvent être consultés pour afiner l'architecture.
Sinon, si tu savais configurer JBoss ou JOnAS, je pense que tu aurais également quelques bases en lancement de JVM : Xmx fixe la taille maximale utilisable de mémoire. C'est Xms pour la mémoire au lancement ;-)
Enfin, on n'a pas besoin d'un serveur J2EE complet pour utiliser beaucoup de mémoire... Sur le projet qui m'exaspère le plus, on tourne sur du Tomcat, mais il y a tellement de couches rajoutées et extrèmement mal codées qu'en pratique la consommation mémoire explose (préchargement systématique d'instances utilisées uniquement en traitement mensuel ou annuel, codage non thread-safe imposant d'instancier systématiquement à chaque utilisation, sérialisation/désérialisation XML pour des messages locaux à l'application, utilisation de DOM pour les flux XML sus-nommés, réutilisation de code par copier/coller...)
[^] # Re: Passerelle Apache Felix?
Posté par François B. . En réponse à la dépêche JOnAS 5.1 M5 : Serveur d'application certifié Java EE 5 !. Évalué à 2.
En fait, je dois dire que ça me désole quand je vois les goinfres de mémoire que je suis obligé de coder pour certains clients ! Mais tant qu'ils payent, je dois faire profil bas. Ça ne m'empêche pas en revanche de chercher à réduire l'empreinte mémoire et processeur sur les applications où on peut agir sur l'architecture.
[^] # Re: Un bloggeur
Posté par François B. . En réponse à la dépêche Pétition « Pacte pour les Libertés Numériques ». Évalué à 5.
Bah... je ne donnerai qu'un extrait du WHOIS :
Registrant ID:tuiGTF39kRMWYHAC
Je crois qu'il n'y a rien à ajouter...Registrant Name:Jean Patate
Registrant Organization:Jean Patate
Registrant Street1:1 av des champs elyses
Registrant Street2:
Registrant Street3:
Registrant City:PAris
Registrant State/Province:
Registrant Postal Code:75008
Registrant Country:FR
Registrant Phone:+33.147474747
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:mlevypro@gmail.com
[^] # Re: Téléchargement des sources?
Posté par François B. . En réponse à la dépêche Fusion Compiz / Compiz-Fusion et autres nouvelles. Évalué à 4.
[^] # Re: Et l'impression??
Posté par François B. . En réponse à la dépêche La FSFE lance une campagne pour les lecteurs PDF libres. Évalué à 2.
[^] # Re: 64 bits
Posté par François B. . En réponse à la dépêche Sortie d'OpenVAS 2.0.0 (fork de Nessus). Évalué à 1.
Peut-être que ça tournait déjà sur 64 bits, mais ce n'était pas possible de détecter les vulnérabilités où la cible est un système 64 bits.
[^] # Re: Granularité du COW ?
Posté par François B. . En réponse à la dépêche Btrfs intègre le noyau Linux dès la prochaine version 2.6.29. Évalué à 1.
StackOverflowError at Brain (unknown location)
(oui, je sais, mon cerveau a une pile *très* limitée...)
[^] # Re: Et firefox, il sert à quoi alors ?
Posté par François B. . En réponse à la dépêche Agrégation de Mathématiques et logiciels libres. Évalué à 3.
[^] # Re: je suis trop geek...
Posté par François B. . En réponse à la dépêche Certificats cadeaux pour des logiciels libres. Évalué à 2.
Il faut dire aussi que je suis en train de chercher une solution pas trop chère pour moi. C'est vraiment hors de prix !
[^] # Re: YeeLoong libre
Posté par François B. . En réponse à la dépêche Portage de GNewSense sur MIPS. Évalué à 1.
PS : le clavier du YeeLoong a la touche fn à droite de la touche ctrl, ce que je trouve pas du tout pratique .... ( http://sorbaioli.org/photos/lemote_yeeloong/hq/img-8.jpg )
C'est justement le contraire... Sinon, c'est juste une question d'habitude : pendant un moment mon portable pro était dans la même disposition (un IBM ThinkPad) et mon portable perso était dans l'autre (un Sony VAIO), et j'arrivais à ne pas trop me tromper.
[^] # Re: Mouais..
Posté par François B. . En réponse à la dépêche Barack Obama et l'Open Source. Évalué à 1.
[^] # Re: Impressionnant
Posté par François B. . En réponse à la dépêche Android désormais disponible et libre. Évalué à 5.
[^] # Re: OT: j'ai mal aux yeux.
Posté par François B. . En réponse à la dépêche Normalisation d'OOXML, enfin diront certains.... Évalué à 2.
Y a un moment faut ptet revenir aux sources...
Peut-être...
[^] # Re: Les concurrents font mieux...
Posté par François B. . En réponse à la dépêche DRM et Tivoisation : 3 cas Apple, Yahoo Music, M6 replay. Évalué à 4.
http://people.debian.org/~evan/ccsummary
http://lists.debian.org/debian-legal/2005/04/msg00031.html
[^] # Re: jusqu'à la prochaine fois
Posté par François B. . En réponse à la dépêche Atheros libère un pilote pour ses composants 802.11n. Évalué à 4.
[^] # Re: Un petit correctif
Posté par François B. . En réponse à la dépêche La fin du verrou global dans le noyau Linux ?. Évalué à 2.
# Discussion avec upstream sur la suppression des lignes incriminées
Posté par François B. . En réponse à la dépêche Découverte d'une faille de sécurité critique dans OpenSSL de Debian. Évalué à 1.
http://marc.info/?l=openssl-dev&m=114651085826293&w=(...)
Le message a été posté sur openssl-dev, et contient à la fin, après avoir exposé ses découvertes avec Valgrind et les deux lignes incriminées (l'emphase est de moi) :
What I currently see as best option is to actually comment out
those 2 lines of code. But I have no idea what effect this
really has on the RNG. The only effect I see is that the pool
might receive less entropy. But on the other hand, I'm not even
sure how much entropy some unitialised data has.
What do you people think about removing those 2 lines of code?
Donc, contrairement à ce que je peux entendre un peu partout, le développeur savait qu'il y avait un impact sur l'entropie du générateur. Mais bon, je vous laisse parcourir le fil de discussion, il n'y a eu que trois réponses qui sont également en faveur de la suppression (mise en commentaire ou compilation conditionnelle) des deux lignes.
[^] # Re: Eclairer ma lanterne
Posté par François B. . En réponse à la dépêche Riposte graduée : la résistance s'organise à l'international. Évalué à 1.
Je suis de retour, tu la veux sous quelle forme la morale ? :-p
Bon, maintenant je laisse tomber, j'ai assez perdu de temps avec toi. Tu ne veux (peux) pas comprendre, c'est ton problème, ce n'est plus le mien !
[^] # Re: Eclairer ma lanterne
Posté par François B. . En réponse à la dépêche Riposte graduée : la résistance s'organise à l'international. Évalué à 1.
[...] autant que le lui permet l'état ou le profil de celle-ci.
Ça répond à ta question pour savoir s'il faut coller le bord du trottoir.
[^] # Re: Eclairer ma lanterne
Posté par François B. . En réponse à la dépêche Riposte graduée : la résistance s'organise à l'international. Évalué à 2.
La seule chose que je disais, c'est que lorsque tu es pris pour 1 ou 2 km/h de trop, en pratique sur le compteur la vitesse est largement supérieure à la vitesse autorisée. J'en ai marre des gens qui chouinent pour "rien du tout en trop"...
Je ne travaille pas pour les forces de l'ordre.
Je ne travaille pas dans les cinémomètres.
Je ne travaille pas pour la sécurité routière.
Je pense que les règles sont là pour être respectées. Il faut bien mettre une limite sinon on ne pénalise jamais... Tu aurais l'idée en parachutisme de retarder au maximum l'ouverture de la voile, puis te dire à 2m du sol que tu n'as pas besoin d'ouvrir pour une si petite hauteur ?
[^] # Re: Eclairer ma lanterne
Posté par François B. . En réponse à la dépêche Riposte graduée : la résistance s'organise à l'international. Évalué à 1.
[^] # Re: Eclairer ma lanterne
Posté par François B. . En réponse à la dépêche Riposte graduée : la résistance s'organise à l'international. Évalué à 1.
Pour ceux qui ont le matériel, une petite expérience est amusante : embarquez dans votre voiture un portable, un récepteur GPS et un GpsDrive entre les deux. La vitesse affichée à l'écran est systématiquement inférieure à celle du compteur, et pas uniquement de quelques unités...