Posté par MrLapinot (Jabber id, page perso, ) le 26/01/2008 à 00:23. (lien). Évalué à 2.

"We will release Lenny with KDE 3.
(...)
The primary reason against shipping KDE 4.0 with Lenny is that this release
lacks many applications that would make KDE 4 a complete desktop, such as KMail, and still requires a lot of overall polishing, making it unsuitable for
most users. KDE 4.1 is expected to fix most of these shortcomings, but the release date has not yet been finalised.
(...)
P.S.: Anyway, you never know what the future will bring, we will review our
decisitions with respect shipping KDE 4 in Lenny in a few months."

http://lists.debian.org/debian-devel-announce/2008/01/msg000(...)

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 23/01/2008 à 21:42. (lien). Évalué à 1.

> KDE 4.0 est enfin sorti et le 4.1 sera sur tous les OS majeurs.

A priori, il ne sera pas sur Debian Lenny. De là à dire que... enfin ce que tu as dit n'engage que toi ;-)

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 11/01/2008 à 11:30. (lien). Évalué à 1.

- Où est le lien pour télécharger les sources ?

Où est le lien pour télécharger le logiciel ? Les sources n'ont à être mises à disposition que des gens qui possèdent le logiciel.

- C'est GPL ? Tiens ça n'est pas spécifié sur le site.

Ce n'est pas obligatoire de le préciser. Certes, on pourrait voir ça comme un plus, un argument de vente, mais rien ne t'oblige à en faire la pub. Du moins, tant que tu ne fournis pas le logiciel.

Pour le reste, tout à fait d'accord, le site pue des chaussettes. Mais il ne me semble poser aucun problème légal.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 08/01/2008 à 19:54. (lien). Évalué à 6.

Mouais. Bah c'est présent depuis le début chez Kimsufi (la solution concurrente proposée par OVH). Enfin mieux vaut tard que jamais.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 03/01/2008 à 12:08. (lien). Évalué à 2.

L'excellent http://linux-attitude.fr/ bien sûr (ex-dadmin) !

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 30/12/2007 à 11:08. (lien). Évalué à 2.

En tout cas, pour parler de combinateur-y, c'est forcément un langage fonctionnel :-)

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 28/12/2007 à 16:04. (lien). Évalué à 3.

Alpine ne gère pas gpg nativement - c'est une vraie galère.

Alpine gère mieux l'IMAP (selon ses concepteurs). En réalité, Alpine gère bien l'IMAP quand le serveur est UW (développé par l'université de washington, tout comme alpine). Google vous renseignera sur les longs et interminables trolls à propos du support de l'IMAP par UW, pine et Courier. http://www.courier-mta.org/fud/ est un bon point de départ. En fait, mutt se sort assez bien de l'IMAP dès qu'on active le cache local (sinon c'est infernal, et ce n'est pas le cas par défaut malheureusement).

Alpine permet de stocker la configuration sur le serveur IMAP et a une notion de "rôles" assez puissante pour gérer les identités.

Les développeurs d'alpine ont une mentalité que je n'aime pas.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 24/12/2007 à 16:19. (lien). Évalué à 2.

(on est d'accord sur tout le reste, je réponds juste sur un point précis)

Et en quoi un protocole ne peut pas se baser sur un ou plusieurs algorithmes ?

Il peut tout à fait.

Tiens question conne, les protocoles de routages, ils reposent ou pas sur des algorithmes de routages ?

Je connais moins bien ce domaine, mais je dirais oui. Tu as un algorithme (pour trouver la route optimale), et un protocole qui décrit les messages que les routeurs s'échangent pour mener à bien cet algorithme - mais à un même algo peuvent correspondre plusieurs protocoles, éventuellement.

Les protocoles censé d'assurer l'intégrité d'une communication, ils reposent ou pas sur des algorithmes de détection et de correction d'erreur ?

Pas forcément, mais ceux qui sont efficaces le font (exemple de protocole con qui n'utilise aucun algorithme de détection d'erreur : renvoyer en écho tout ce qu'on reçoit pour confirmation).

Les protocoles de chiffrements (ssl par exemple), ils reposent ou pas sur des algorithmes de chiffrements?

Oui. Plus précisément, tu as (par exemple) des protocoles d'échanges de clefs qui reposent sur des algorithmes de chiffrements. En général, quand on étudie un protocole en crypto, on suppose à la base que les schémas de chiffrement sous-jacents sont parfaits (éventuellement avec une certaines probabilité d'être cassés).

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 24/12/2007 à 15:19. (lien). Évalué à 2.

"On ne parle pas d'algorithme mais de protocole [...] qui évite le rejeu" ...
Donc tu implémentes bien un algorithme.
Un protocole c'est pas juste "le troisième bit à gauche à 1", il peut y avoir des algorithmes. Et pour éviter le rejeu, c'est pas avec juste une bonne structure de donnée, mais avec les algorithmes sous-jacents.

Excuse-moi mais ce que tu racontes n'a (dans le contexte de cette discussion du moins) absolument aucun sens.

Selon Wikipédia : "Dans les réseaux informatiques et les télécommunications, un protocole de communication est une spécification de plusieurs règles pour un type de communication particulier." Par opposition à (même source) : "un algorithme est un énoncé dans un langage bien défini d’une suite d’opérations permettant de résoudre par calcul un problème."

Bref, un algorithme permet de résoudre un problème. Un protocole, c'est une convention pour la communication entre plusieurs personnes, qui apporte certaines garanties sur le déroulement des échanges.

Quant à la question du rejeu, il s'agit d'éviter qu'un message intercepté puisse être renvoyé plus tard, comme si c'était un message neuf (pense à un ordre de virement : même si le protocole est parfaitement sécurisé, si ton message est intercepté et renvoyé 10 fois par l'attaquant, bah tu risques d'avoir moins d'argent que prévu sur ton compte).

Désolé si tu estime qu'un programme qui a rien a voir avec les spécifs est un bon programme, surtout si c'est de la crypto, alors tes programmes vont pas êtres très solides.

Il peut s'agir d'un bon programme, simplement on va avoir du mal à le prouver. Je bosser actuellement sur un précompilateur C pour programmes coopératifs qui est une vraie tuerie en matières de performances ; c'est un excellent programme. Mais on n'a pas encore prouvé que son fonctionnement est correct. D'un côté on la qualité, de l'autre la preuve de cette qualité.

Il faut quand même savoir que presque aucun logiciel de crypto n'est prouvé formellement - les algorithmes et protocoles sous-jacents peuvent éventuellement l'être (et encore pas toujours), mais le logiciel en lui-même, c'est quelque chose de très nouveau et exceptionnel. Cela n'a pas empêché d'avoir des logiciels de qualité jusqu'ici (comme ssh par exemple).

"On suit pas la spécifs ... mais je vous assure mon truc c'est trop de la balle".

"On suit pas la norme RSA, mais je vous assure, mon truc est encore plus secure. Comment ? Ah ca pas besoin de vérifier contre la specif (ni de vérifier la specif), vu que c'est moi qui vous le dis. Non ca vous convient pas? bizarre"

Là encore, tu confonds. Norme et spécification sont deux choses très différentes. D'un côté, tu as des standards adoptés et reconnus par la communauté (industrielle, scientifique, etc.). De l'autre, tu as des choix de conception interne. Maintenir l'adéquation entre le programme et la spécification, c'est comme entre le programme et la documentation : c'est un boulot énorme, et rarement mené à bien.

Naturellement, ce serait mieux que les deux aillent ensemble. Et c'était précisément le sens de mon premier message.

Mais merci de ne pas tout déformer. A priori (je n'ai aucune information là-dessus), quand MS dit "on utilise RSA à cet endroit", ils utilisent RSA conformément au standard. Et ils ne créent pas leurs algorithmes de cryptographie dans leur coin, juste pour se marrer.

Par contre, en ce qui concerne les protocoles (tu noteras la différence), ils ont à faire face à de nouveaux besoins, pour lesquels il n'y a ni norme, ni standard : ils sont donc logiquement amenés à créer de nouveaux protocoles, selon des spécifications internes, et parfois, ça évolue.

J'espère avoir été plus clair cette fois-ci.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 22/12/2007 à 19:24. (lien). Évalué à 2.

Sous OpenWRT, tu peux installer les modules ebtables. Sous DD-WRT, je ne sais pas.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 22/12/2007 à 19:21. (lien). Évalué à 2.

On ne parle pas d'algorithme mais de protocole cryptographique. En l'occurrence, fournis de base dans un framework de Microsoft. Le genre de truc qui te permet, sur le principe de l'AJAX (en envoyant des bouts de XML sur le réseau), d'effectuer des transactions, des trucs signés, chiffrés, authentifiés, en évitant que les requêtes ne soient forgées, qu'on rejoue une requête ou qu'on fasse de la confusion sur les types de données pour mettre à mal le protocole, etc. Enfin tout ça pour dire que c'est un sujet très compliqué, sur lequel il n'y a pas (encore) de protocoles reconnus et utilisés par tout le monde (surtout vu la diversité des usages). Tu es simplement totalement hors-sujet.

Un exemple de protocole crypto : http://fr.wikipedia.org/wiki/Needham-Schroeder

Il date de 78, et contient une faille découverte en 95. Juste pour te montrer la non-trivialité des problèmes dans le domaine.

Mais comme tu as l'air d'aimer casser du sucre sur le dos de Microsoft, voici une info exclusive pour toi : les chercheurs qui bossent dessus ont bien fait leur boulot, ils ont trouvé des failles (avec des méthodes formelles et tout et tout), mais ils ne les ont pas divulguées. Du moins pas avant quelques mois, le temps que les clients migrent à la version suivante. Ouais, c'est moche de garder ses découvertes pour soi quand on est chercheur, mais parfois, c'est aussi les impératifs industriels.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 21/12/2007 à 09:27. (lien). Évalué à 2.

La documentation, c'est bien joli, mais j'ai rencontré un chercheur Microsoft (non, je ne donnerai pas nom, n'insistez pas) qui m'a expliqué qu'elle n'était pas suivie. Pour être plus précis : lui, son domaine, c'est les protocoles cryptographiques (en gros). Et il expliquait qu'un énorme problème, c'est que les connaissances actuelles en vérification de protocoles cryptographiques étaient difficilement applicables, parce qu'elles se fondent sur une vérification de la spécification. Or la spécification n'est suivie qu'au tout début, ensuite l'implémentation diverge petit à petit (on patche, on rajoute des fonctionnalités, etc.) et la spécification n'est pas mise à jour. Du coup, il se retrouvait à vérifier un protocole théorique, différent de celui qui tourne vraiment (d'où les recherches actuelles pour extraire le modèle directement à partir du code).

Après, c'est peut-être différent pour SMB, mais je ne vois pas vraiment de raison. Même si Microsoft joue le jeu, honnêtement, et fourni les documents qu'elle possède, il n'est pas évident que ça suffise (à la limite, il faudrait pouvoir examiner le code, mais ça n'est clairement pas possible).

Si quelqu'un a des infos plus précises...

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 19/12/2007 à 12:22. (lien). Évalué à 2.

> Il ne faut pas oublier de parler de la perte des boites mails chez free.

Un lien ?

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 18/12/2007 à 23:09. (lien). Évalué à 2.

Beark, par défaut il font quand même de la "correction" d'erreurs de frappe et ils redirigent vers un serveur de pub en cas de domaine non trouvé (comme certains FAI, dont club-internet). Toutefois, si on s'inscrit (gratuitement), il est possible de désactiver cette "fonctionnalité". A noter aussi que les statistiques ne sont pas activées par défaut par contre.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 18/12/2007 à 22:21. (lien). Évalué à 2.

Merci beaucoup !

Pour ceux qui n'arrivent même pas à accéder à OpenDNS (il m'a fallu pas mal de tentatives) :
nameserver 208.67.222.222
nameserver 208.67.220.220

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 18/12/2007 à 20:32. (lien). Évalué à 2.

En effet, pour avoir le wifi, il faut utiliser OpenWRT kamikaze avec le noyau 2.4.
Et là, pas de modules ebtables, notament le fameux ebtable_broute...

Apparemment, il y a un problème de stabilité d'ebtables avec le noyau 2.4 : https://dev.openwrt.org/ticket/2482

Problème qui se pose peut-être aussi avec WhiteRussian ? En tout cas, chez moi ça a l'air de bien fonctionner. Cela dit, si tu t'en tiens à un noyau 2.4, pourquoi ne pas utiliser WhiteRussian (plus limitée, certes, mais déjà bien fournie) ?

D'autre part, il y a déjà un bridge, hors une interface ne peut pas faire partie de deux bridges. Est-il judicieux de mettre toutes les interfaces dans le bridge ?
Vous allez dire oui, car la règle ebtables n'autorise que l'IPV6 entre l'interface Internet et l'interface interne.

Ouaip, c'est la question que je me suis posée. D'où mon inquiétude de laisser fuir certains paquets. Je n'ai pas vraiment de réponse ; c'est clair en tout cas que ça tient plus du hack dégueu que de la solution idéale.

Question subsidiaire :
Shorewall ne permet pas d'établir des règles pour IPV6, comment on fait pour ne pas resté ouvert au grand Ternet (simplement) ?
Oui oui, on contribue à shorewall...

On utilise ip6tables. Mais comme on veut le suivi de connexion, on a besoin d'un noyau 2.6.20 au minimum. Donc on utilise kamikaze. Ah oui, mais on n'a pas le driver binaire tout pourri pour faire fonctionner le wifi - et le driver libre pour 2.6 est instable. Monde proprio, monde de merde...

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 18/12/2007 à 20:25. (lien). Évalué à 2.

> Qui accepterais sans condition touts les packets ipv6 venant de vlan1 dans le bridge ?

Le problème, c'est que par défaut tous les paquets du bridges sont "acceptés" (comme si c'était le même réseau). Il faut donc, comme présenté dans l'article, une règle négative : on spécifie que c'est tout ce qui n'est pas de l'ipv6 qui doit être routé classiquement (donc exclu du bridge). Ceci vaut naturellement si la policy de BROUTING est ACCEPT ; si elle est mise à DROP (ce qui serait un peu bizarre, on perd l'intérêt d'un bridge, mais pourquoi pas), ta remarque devient pertinente - mais il faut alors ajouter d'autres règles ACCEPT selon ses besoins.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 15/12/2007 à 09:16. (lien). Évalué à 2.

Enfin dmenu, c'est un menu qui se pilote entièrement au clavier, en même temps...

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 15/12/2007 à 09:12. (lien). Évalué à 2.

Pour le problème de Mod4 sur le Thinkpad, voici mon .Xmodmap :

keycode 234 = XF86Back
keycode 233 = XF86Forward
keycode 77 = Num_Lock
keycode 227 = F35
clear Mod4
add Mod4 = XF86Back

qui place Mod4 sur la touche "bureau précédent". Tu peux aussi le placer sur la touche Fn de la même manière.

Par contre, je viens de réaliser que ma touche AltGr ne fonctionne plus correctement, je ne sais pas s'il y a un lien.

[ Répondre ]

Posté par MrLapinot (Jabber id, page perso, ) le 12/12/2007 à 10:02. (lien). Évalué à 6.

Plus d'infos (techniques et non commerciales) ici : http://signal.eu.org/blog/2007/12/12/ipv6-chez-free/

Notamment :

apparemment c’est une technique appelée “6to4rd” (6to4 Rémi Després ?), inventée par un des concepteurs de Transpac (l’ancien réseau du futur des années 80 et du Minitel, tué par Internet justement, ça ne nous rajeunit pas !), probablement un dérivé de 6to4, donc une solution un peu “cheap” à base de tunnel qui ne fournit pas de l’IPv6 natif de bout en bout ;

[ Répondre ]