MrLapinot a écrit 854 commentaires

Quelle est la différence avec Marionnet ?

http://www.marionnet.org/

De ce que je vois, Marionnet ne fonctionne que depuis un LiveCD (pour l'instant) et a une interface graphique vachement plus jolie (je trouve). D'autres infos ?

Tu as quoi comme téléphone pour lire du ogg dessus ?

Tu viens de réinventer Maildir, félicitations !

Bon, j'exagère un peu, la solution que tu suggères est légèrement plus élaborée, mais on n'en est pas loin. Il suffit d'avoir plusieurs boîtes Maildir, une dans chaque dossier qui t'intéresse en fait (par exemple ton dossier Comptes contiendra 3 répertoires, cur, new et temp, qui stockeront tes mails liés à la banque). Reste à trouver un logiciel qui fait du multicomptes et gère le format Maildir, c'est pas bien dur (mais un peu lourd, ça impose de créer un "compte" mail par dossier).

Ce n'est pas une raison. Une mise à jour de noyau, ça nécessite un redémarrage du serveur. Si le serveur est critique, on peut retarder ce redémarrage jusqu'au prochain week-end / vacances par exemple. Mais si la faille de sécurité est encore plus critique, alors on assume de couper le service pendant 5 minutes, le temps d'un redémarrage (ou alors on met en place un serveur de backup pour la transition, etc.). Reste que pour savoir si la faille est critique ou pas, il faut communiquer dessus.

La différence, c'est qu'une mise à jour classique (surtout du noyau), tu peux prendre ton temps pour la faire. Une mise à jour de sécu, en général, tu agis avec plus de célérité.

Alors copy cheap ? pas cheap ? Ce qui me semble clair c'est que ya des algos d'une complexité trop importante qui ont du échapper à la vigilance de leur auteurs, en tout cas.

Ça ne peut pas être pire que la résolution des conflits dans darcs, en tout cas ;-)

Je médis mais c'est ce que j'utilise au quotidien et j'en suis très content (pour mon usage sur des projets de taille moyenne).

Je me demande surtout pourquoi les pages qui parlent de ces outils évitent généralement de dire la vérité, à savoir que ces outils sont aussi utilisés par des criminels.

En tout cas, tu ne peux pas reprocher à Tor d'esquiver le problème : en bas de leur page [http://www.torproject.org/torusers.html] que tu cites, il y a un lien vers [http://www.torproject.org/faq-abuse.html.en] qui traite exclusivement des mauvaise utilisations potentielles de Tor. Après, on peut ne pas être d'accord avec leur façon de présenter les choses sur cette page, mais ils n'évitent pas la question.

So yes, criminals could in theory use Tor, but they already have better options, and it seems unlikely that taking Tor away from the world will stop them from doing their bad things. At the same time, Tor and other privacy measures can fight identity theft, physical crimes like stalking, and so on.

Elle n'a qu'à dire qu'elle est informaticienne !

+1 pour rsnapshot qui offre l'avantage que, quand on merde en modifiant (voire supprimant, ça m'est arrivé) un fichier de conf, un cp tout bête permet de récupérer la version précédente.

Par contre, les possibilités de sauvegarde distante de rsnapshot sont pas terrible (disons qu'il faut que ce soit le serveur à sauvegarder qui initie la connexion, ce qui ne me convenait pas vu que mon serveur de backup n'est pas toujours lancé) donc j'utilise rdiff-backup pour faire un miroir du snapshot le plus récent de rsnapshot. Finalement, j'ai donc un backup journalier en externe, et des snapshots toutes les quelques heures en local en cas de merdouille de ma part.

Il ne s'agit pas de la distribution utilisée mais de la distribution préférée. Ce qui, tu en conviendras, change totalement la donne.

Bash devant zsh, c'est exactement la même chose qu'IE devant Firefox : beaucoup moins de fonctionnalités, activation par défaut avec l'OS.

... en l'occurrence, ce serait plutôt celui du crémier.

------------->[]

"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(...)

> 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 ;-)

- 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.

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.

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

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

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.

(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).

"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.

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

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.

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...

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

Un lien ?