Aris Adamantiadis a écrit 151 commentaires

Mettre une image du jeu en cross-ref, sur la page principale, n'était pas la meilleure idée non plus.

Le bitcoin n'est absolument pas anonyme, dans le sens où toutes les transactions sont publiques et indiquent clairement la source et la destination d'un transfert.
Si on peut savoir quel bitcoin tu as reçu, le vote n'est plus anonyme. Cela n'a aucun avantage supplémentaire par rapport à un numéro que tu recevrais et enverrais par email au candidat de ton choix.

Commentaire probablement inutile, mais "à priori" est désormais accepté par l'académie française, à côté de "cédérom" et "sandouiche".
http://www.langue-fr.net/spip.php?article128

Pareil. Il suffit d'avoir le support de ce personnage critiqué et critiquable pour que le projet soit lui-même critiqué.
Si il faut faire des modifications, elles doivent être plus importantes que simplement fusionner ces répertoires. Il faut supprimer le /tmp global (et tous les endroits world-writable), simplifier les 3 ou 4 endroits où l'on trouve de la doc (/var, /usr/doc, /usr/share/doc,...), virer tout ce qui est configuration et données statiques de /var, réordonner le bordel de /etc, etc.

Et surtout ne pas annoncer qu'on a le support de gens notoirement détestés dans la communauté.

Une faille de sécurité dans le protocole SSL 3.0 (et inférieur) et TLS 1.0 a été découverte. Ces protocoles garantissent l'accès chiffrés aux serveurs web. Il n'y a donc plus aucun site web qui est à l'abri d'une attaque man in the middle.

Faux.

La faille n'a pas été découverte. Comme expliqué plus loin, c'est connu depuis longtemps. La nouveauté, c'est qu'un vecteur d'attaque a été découvert, et un exploit fonctionnel a été developpé.

Concrètement, l'attaque consiste à injecter du texte connu dans une page web (via du JavaScript introduit dans une publicité vérolée par exemple). Après, il suffit d'écouter la conversion (il faut quand même une session de 30 minutes pour l'exploit actuel) pour découvrir la clef AES. L'exploit permet donc de déchiffrer la page mais aussi les cookies et donc de s'identifier sur le site visé.

Totalement faux. L'exploit ne récupère pas la clef AES (d'ailleurs cette clef change entre chaque session) mais permet de récupérer des morceaux de cleartext, un byte à la fois.
Le principe est le suivant : l'attaquant force la victime, via un JS introduit dans un flux non chiffré, à récupérer des éléments à des URLs précises, sur un site https (le simple fait d'inclure une image est suffisant). En utilisant des URL suffisamment longues et en introduisant des décalages, il est possible de deviner le dernier byte d'un bloc chiffré en AES-CBC.
Il est donc possible de deviner le cookie pour https://www.paypal.com d'une victime, bien que cette victime ne visite pas le site.

Il y a 3 manières de mitiger le problème :

• Tout le monde passe en TLS 1.2. Ca va demander pas mal de temps de dev des deux côtés, vu que openssl ne supporte pas encore TLS1.2 et NSS non plus.
• Les clients utilisent le workaround implémenté dans openssl, qui consiste à découper le premier paquet en deux. L'attaque n'est apparemment pas réalisable sur le deuxième paquet.
• Les services sensibles sur https peuvent forcer la réécriture du cookie d'authentification à chaque accès, ou mieux, forcer la réécriture d'un cookie tampon contenant des valeurs aléatoires.

Si TLS était mieux conçu, il aurait suffit d'activer AES256-CTR par défaut comme en SSH.

C'est en effet une partie bien trollesque que j'avais repéré aussi.
Java est certainement plus sûr, parce qu'il faut le vouloir pour laisser un buffer overflow dedans. Mais il introduit de nouvelles possibilités de failles propres à java, tout en prenant compte que la VM et les libs sont elles aussi ecrites en C++.

Ce qui a fait de windows un OS mal sécurisé, ce sont surtout des problèmes de design et d'implémentation, datant d'un temps où la sécurité ne comptait pas autant qu'aujourd'hui pour la conception d'un OS, pas le langage en lui-même.

Le support d'IPv6 pour nmap est uniquement pour le connect() scan. Il ne gère ni le SYN scan ni l'UDP.
Oui j'ai fais des nmap, ne t'inquiètes pas :) L'absence de synscan dans un scanner évolué comme nmap, c'est un problème bloquant.

Malgré les différents patches qui ont été proposés par de nombreux contributeurs. On est en 2011 et le scanner de ports le plus utilisé au monde n'a pas de support pour IPv6.

Je ne comprends pas vraiment comment l'équipe gère ses priorités.

C'est normal qu'il n'y ait pas d'infos à ce sujet sur le site de "Jeudis du Libre" ?

Qu'en est-il en comparaison avec shibboleth (implé SAML2 libre) ? Je sais que l'intégration avec shibboleth peut être vraiment très très rapide (un module apache à installer, deux trois règles dans le apache.conf et ça tourne). Mais je sais que shibboleth ne fait pas l'unanimité (malgré sa popularité dans le secteur académique).

Est-ce que la gestion d'un fournisseur d'identité est plus simple avec Lasso ? (L'integration de LDAP ou AD avec shibboleth IP est pas toujours très simple, faut aimer éditer du XML à la main ...)

merci

*d'ordre politique et légal*

Désolé, on a pas du lire le même texte de licence. Celui qui demande ça c'est la GPL. C'est aussi pourquoi mon projet est en LGPL (qui permet le meilleur des deux mondes).

Licencier son code en BSD et puis se plaindre que les gens ne font que le strict minimum de ce qui est imposé par la licence, c'est fort.

Il est évident que ce genre d'escrocs se sert de comptes paypal compromis, et n'aura aucune difficulté à acheter autant de comptes que nécessaire.
Je ne vois pas l'intérêt de ce système, si ce n'est pour écarter les extensions qui ne marchent pas du tout et s'arranger pour avoir un minimum de participants.

Alors pour toi un non technicien est un imbécile ? pour moi c'est quelqu'un qui veut "que ça marche" sans savoir ce qu'il y a sous le capot. C'est tout à fait raisonnable, et c'est cette personne que je défend en disant que flash est important pour lui.
Tenter de le convaincre est voué à l'échec, flash a beaucoup trop d'importance aujourd'hui pour qu'on puisse s'en passer (mais par contre je conseille d'office flashblock).

C'est simple : sans flash, linux est inutilisable pour le commun des mortels. Facebook, youtube, dailymotion & co sont des incontournables et il n'est pas possible d'expliquer à un non technicien que flash est une techno propriétaire merdique, ce qu'il veut c'est voir une vidéo.
Je pense qu'il faut se réjouir que des solutions libres arrivent petit à petit à remplacer la bouse proprio d'adobe (qui ne tourne même pas sous amd64), qui est quand même le seul logiciel proprio sur ma machine (à l'exception des drivers nvidia).

Ce qui se passe est l'interaction entre un programme et le serveur X. Le programme peut obliger le serveur X à rentrer dans une boucle récursive dont il contrôle la profondeur. Lorsqu'un programme devient récursif, il se met à prendre de la place sur le stack pour pouvoir revenir à son état d'origine après les différents appels de fonction.
Le bug se produit lorsque le stack descend tellement bas qu'il tombe sur un espace d'adressage déjà utilisé et controllé par l'application.
Dans ce cas, il suffit à l'application d'écrire dedans pour écrire dans le stack du serveur X, ce qui donne très facilement un contrôle total du serveur X.

A mon sens il y a deux bugs ici :
- Le serveur X ne devrait pas pouvoir rentrer en récursion arbitraire avec des entrées utilisateurs; Si récursion il y a, elle doit être bornée avec des limites raisonnable. Si il n'y avait pas eu de possibilité d'exploitation, ça aurait tourné en local DoS, ce qui n'est pas un comportement valable non plus.
- Le noyau ne devrait pas autoriser le stack à s'approcher d'aussi près de pages déjà allouées. C'est d'ailleurs ce qui a été implémenté comme solution : une page de garde est rajoutée au sommet du stack à chaque agrandissement afin d'éviter que l'application ne se mette à écrire dans des zones qui ne sont pas dans le stack.
C'est d'ailleurs quelque chose que windows fait depuis longtemps pour séparer les différents stacks des différents threads d'un même processus.

J'ai pensé *exactement* la même chose en lisant la citation !

Je n'ai pas encore trouvé d'éditeur XML libre capable d'ouvrir un fichier sauvegarde de freecol, qui fait en moyenne 1Mb, sans ramer... pourtant j'ai 6Gb de ram !
Il semblerait qu'aucun ne soit optimisé pour dérouler l'arbre à la volée plutôt qu'en un coup. D'ailleurs c'est aussi le problème de wireshark (le faire tourner sur un pcap de 3 ou 4 Gb c'est assez rigolo).

Je suis bien content de trouver de la doc sur Vim, en français en plus : http://www.swaroopch.com/notes/Vim_fr
Cependant, j'aimerais bien trouver une version PDF de cette traduction. Je pourrais l'imprimer en anglais mais ça réduirait l'intérêt d'une jolie traduction pour calmer mes neurones dans le train.

Quelqu'un aurait-il vu une version PDF francophone ?

C'est grâce à Ikarios, que j'ai acheté lorsque j'avais 14 ans dans les années 99 mon premier cd de slackware 7 (avec le cd sources !) pour faire mes débuts sous linux. Aucune autre offre valable n'existait en europe à l'époque, et les révues n'offraient pas encore de distributions complètes.

Pour tout ça, un grand merci.

Je m'attendais à mieux qu'un argument "Microsoft l'a fait avant". Que je sache, la perte de performances sous windows à l'installation de nouveaux programmes est surtout due à la mauvaise gestion de la base des registres, ainsi qu'au bordel que ces applications (surtout les jeux et les free/malwares) installent dedans (et sans les retirer après desinstallation).
Sous unix, ça fonctionne totalement différemment, et le modèle n'est pas sujet à ce genre de maladie (déjà parce que la plupart des utilisateurs n'installent pas de freewares ou de logiciels qui foutent le boxon).

Bref, à part des a-priori, on a quoi ?

"En effet les logiciels et services, toujours plus nombreux et imposés lors de chaque installation, alourdissent la distribution, et forcent beaucoup d'utilisateurs de tout horizon, désireux de choisir eux même leurs logiciels, à se tourner vers une installation minimale d'Ubuntu, via un cd minimal, n'installant rien de plus de base qu'un shell et quelques paquets."

J'attends encore de voir une démonstration de l'affirmation de la première partie de la phrase. Une démonstration chiffrée avec des benchmarks et des blindtest. Je ne vois aucune raison qui permette d'expliquer qu'une machine est plus rapide parce qu'il y a moins de programmes installés dessus par défaut, mais alors aucune (hint: les daemons qui tournent à attendre à rien faire ne font effectivement rien).

en même temps quand on a un disque dur de plus de 4GB (tous les pc depuis 2000) et plus de 256MB de ram (j'ose espérer qu'un développeur en a plus), ça n'a strictement aucun impact...

Bon je réponds à moi-même:
svn co svn://anonsvn.kde.org/home/kde/trunk/playground/devtools/kdevelop4-extra-plugins/

La communication ne me semble pas non plus au rendez-vous. A part cette page sur linuxfr (que d'ailleurs je trouve super !), le site de kdevelop parle encore de la version 3.5 et ne donne pas de lien pour télécharger kdevelop4 (merci pour les liens d'ailleurs).

Petite surprise au premier démarrage, pas de bouton "nouveau projet". Il ne faut pas oublier de lancer kbuildsycoca4 (quoi que ça fasse) pour recharger les plugins.

Dans les points positifs, je viens d'importer mon projet basé sur cmake (petite pub: www.libssh.org), l'importation s'est très bien déroulée, compilation aussi, et les menus/editions ont l'air d'être bien plus fluides qu'avec eclipse.

petite déception, absence du plugin git dans le pack officiel. Je ne sais pas encore où le trouver et le vide sidéral du site de kdevelop n'aide pas.

Pour les ubuntusers, les packages à installer avant de compiler sont
kdebase-workspace-dev kdelibs5-dev