🚲 Tanguy Ortolo a écrit 12690 commentaires

La génération d'une paire de clef pourrait se faire directement à l'installation.

Je n'ai pas vérifié récemment, mais il me semble qu'avec Enigmail, c'est justement le cas, sauf si l'utilisateur indique qu'il veut procéder autrement.

Tous les messages devraient être signé de base, et si on a une clef d'une personne : le mail devrait être directement crypté sans rien demandé de plus.

Je me demande si ce n'est pas justement le cas par défaut avec Enigmail, au moins pour la seconde partie de ta phrase.

Le WoT ont s'en fout un peu. Surtout si clef doivent vivre peu de temps, car la gestion de la révocation est complexe.

Traduction : la vraie sécurité on s'en fout un peu. C'est effectivement vrai pour la plupart des gens, mais ça risque d'être difficile de faire accepter un truc pareil aux développeurs de solutions de chiffrement, parce qu'eux s'y connaissent, justement, et auraient du mal à accepter de rendre facile une utilisation mal sécurisée de leur logiciel. Ceci dit, ça pourrait bien prendre la forme d'une option à l'installation : voulez-vous faire de la sécurité sérieuse, ou est-ce que vous vous en foutez ?

La clef publique (ou son fingerprint) peut aussi être attaché au mail signé, ainsi le plugin de la personne en face peut récupérer la clef toute seule.

Aucun intérêt, l'info est déjà dans la signature OpenPGP.

Mais les gens sont convaincus que ça leur est utile, et le ratio utilité/difficulté passe.

Hmm, les gens concernés, ce sont les enfants de 6 ans. Si je me souviens bien, à cet âge-là je me rendais certes compte qu'il était utile de savoir lire et écrire, mais étant un enfant, donc plus impulsif et moins raisonnable qu'aujourd'hui, aller à l'école ne m'amusait pas immédiatement, et si j'avais eu le choix, j'aurais bien séché la classe.

Tout ça pour dire qu'il y a des cas où il faut forcer les gens, en l'occurrence les enfants, à apprendre des trucs pas intuitifs. Ils peuvent comprendre que ça leur est utile, mais ça ne suffit pas à ce qu'ils le fassent volontairement. Cette dernière remarque s'applique également aux adultes, sauf qu'on ne peut pas trop forcer des adultes à aller prendre des cours...

Attention, ce n'est pas parce qu'une technologie n'est pas intuitive ou facile à assimiler qu'elle est mauvaise. Sinon, je vous signale qu'on ne serait pas ici à lire nos commentaires mutuels et à y répondre par écrit, parce qu'on se serait arrêtés à l'utilisation de livres d'image pour enfants, sans texte, parce que la lecture et l'écriture sont des technologies excellentes qui ne sont ni intuitives, ni faciles à apprendre.

Les explications ne sont pas franchement claires à mon avis, mais voilà ce que j'en ai compris. Il s'agit d'un service de fourniture de courrier électronique, avec un logiciel de messagerie dédié — natif pour iOS et Android, dans un navigateur Web pour les autres, ou sans doute avec n'importe quel logiciel de messagerie compatible pour les motivés — qui applique systématiquement un chiffrement OpenPGP pour les messages envoyés à d'autres utilisateurs du même service, et peut-être à d'autres destinataires connus pour avoir une clef PGP.

Concernant le chiffrement, c'est donc simplement de l'OpenPGP. Concernant la simplicité, c'est apparemment simplement OpenPGP sans validation de l'identité du destinataire : j'ai trouvé un clef avec l'adresse électronique de mon destinataire, je l'utilise sans poser de question. Concernant la sécurité, ce serait donc celle d'un chiffrement sans vérification : vulnérable au MiTM mais pas à l'écoute simple.

Certes, sauf que ça appellerait sl pour toutes les commandes inexistantes, or sl est à la base conçu pour sanctionner les faute de frappe. Par exemple, taper nc sur une machine ou netcat n'est pas installé, ce n'est pas une faute de frappe, contrairement à taper entcat par exemple.

À propos de sl, je trouve dommage que cet outil indispensable ne couvre qu'une erreur courante sur ls. Je me demande s'il serait possible de bricoler un truc pour appeler sl pour toutes les commandes inexistantes mais proches de commandes existantes, comme atp-get par exemple.

Il y a quelques années, on générait couramment des doubles paires de clefs DSA de 1024 bits — pour la certification net la signature — et ElGamal de 2048 bits — pour le chiffrement — à cause me semble-t-il de problèmes de brevets sur RSA. Depuis, cette pratique a été largement découragée, et comme les brevets RSA ont expiré en 2000, on recommande généralement d'utiliser des clefs RSA de 2048 bits ou plus, si possible 4096 bits, avec sous-clefs séparées par rôles.

Je suis donc surpris de lire que RSA ne fait pas partie des algorithmes obligatoires, et qu'il n'est pas envisagé de l'y ajouter.

Puisqu'on parle de filtres, quelqu'un pourrait-il expliciter ce dont on parle ? Parce que bon, dans le domaine du courrier électronique, un filtre, ça peut désigner plusieurs choses :

• des filtres spécifiques au MTA, par exemple un moyen de refuser tout le courrier qui provient de untel ;
• des filtres externes branchés par relais SMTP (MTA → filtre → re-MTA) ;
• des milters standard branchés par socket Unix ou réseau sans réinjection (MTA ↔ milter à un moment de la chaîne de traitement des messages), introduits par Sendmail ;
• des règles définies par les destinataires pour la livraison et le tri de leur courrier, que ce soit par un logiciel externe (procmail, fdm...) ou par un système interne au MDA, et avec un langage spécifique ou standard (sieve).

Arrêtons de nous croire mieux que les autres: la France, c'est un petit pays de merde, point. On a trop peu de connaissances exportables pour se prendre pour les Dieux de l'Europe ou même pour s'imaginer avoir une quelconque place de choix dans le monde.

Ah oui ? Puisqu'on parle d'informatique et de téléphonie, souvenons-nous où a été inventé l'ordinateur personnel et le Groupe Spécial Mobile, quand même.

Quel est le problème avec ce qui existe déjà, et qui peut être combiné ? Genre LZ4 puis AES ?

En francais, je cherche un algorithme de compression qui permet de faire:
[...]
Apres, pour avoir une bonne performance, au lieu d'encrypter[...]

En français, tu cherches un algorithme qui permette de faire... Après, pour avoir une bonne performance, au lieu de chiffrer...

Avertissement : je parle de choses que j'ai seulement entendues ou lues en espérant que cela pourra être utile à d'autres, n'étant personnellement pas du tout concerné par ces sujets.

Il me semble qu'il y a des logiciels pour téléphone portable qui demandent des permissions illégitimes, par exemple l'accès au répertoire téléphonique de l'utilisateur, et qui, si on les bloque a posteriori avec un outil comme Privacy Guard Manager, refusent de fonctionner pour forcer l'utilisateur à rétablir cet accès.

Et donc, il me semble que, pour répondre à ce problème, il existe au moins un logiciel qui permet non seulement de modifier les permissions des autres logiciels, mais également de les lancer en simulant de permissions, et en fournissant en réalité des données bidon. Si quelqu'un se souvient de quoi il s'agit, ça devrait pouvoir être utile aux utilisateurs de logiciels indélicats sur téléphone portable.

On le trouve dans les bombes de chantilly.

Et en cartouches pour les siphons qui servent à faire sa propre crème chantilly. L'intérêt du protoxyde d'azote est qu'il est soluble dans la crème. Par conséquent, en mettant dans le siphon de la crème et du protoxyde d'azote sous pression, puis en remuant un peu, on dissout une bonne quantité de gaz dans la crème. Ensuite, quand on laisse sortir la crème, en retournant à pression ambiante, le protoxyde d'azote ne peut plus être dissous en si grande quantité, et forme des bulles dans la crème, qui devient une chantilly !

Ça ne marcherait pas du tout avec du dioxyde de carbone par exemple.

Justement j'ai une question : c'est quoi les problèmes que ça va résoudre ? Dans PKI, le principal problème à l'origine de beaucoup d'autres c'est que c'est un système centralisé.

Pas tout à fait, ce n'est pas un système avec un centre mais avec plusieurs centres mal contrôlés.

Est-ce que tu n'a pas l'impression que DANE ne fait que déplacer la centralisation du système CA+navigateurs vers le DNS (racines+registrars) ?

C'est un façon de voir les choses, et effectivement la responsabilité est placée sur les registres, la fraude correspondant l'émission d'un faux certificat par une autorité reconnue ayant pour équivalent le transfert illégitime d'un nom de domaine par son registre.

Mais une autre façon de voir les choses est de reconnaître que, de toute façon, on se fie déjà aux registres du DNS. On passe alors d'un système basée sur la confiance en les registres des TLD et les autorités de certification X.509, à un système basé sur la confiance en les seuls registres de TLD.

Par ailleurs, DANE permet d'indiquer des contraintes sur les certificats ou sur les clefs qui peuvent, au choix de l'administrateur, se substituer ou s'ajouter à celles liées à la validation X.509.

Autre question : comment ça va se passer si je veux faire un certif sur une machine sans nom de domaine (juste avec l'IP) ?

Je ne pense pas que tu le puisse en effet.

La solution la plupart des problèmes des chaînes de certification X.509 actuellement utilisées pour TLS existe, c'est DANE. L'ennui, c'est que les fabricants de navigateurs Web n'en ont rien à foutre.

Et les raccourci du Jardin zen est sympa, mais franchement casse-gueule ! Je n'irais pas utiliser ça pour une course sérieuse...

Alors, le raccourci de Banlieue lustrée a un intérêt énorme au contraire : si tu l'explores un peu, tu verras qu'il communique, par un ponton en bois, sur la ligne droite du viaduc, soit bien en arrière, à un endroit caché derrière un tas de caisse. Il faut donc le prendre dans l'autre sens : à la fin du viaduc, sortir de la piste en percutant les caisses situées en bordure droite. Ça donne donc sur ce ponton, qui est plein de pièges : tant pis, ce raccourci fait gagner tellement de temps que cela importe peu.

Ah, une autre piste très pénible : le Minigolf.

Et sinon, ce n'est pas de la nitro(glycérine), qu'on utilise, qui est un explosif instable et dangereux, mais du nitro(méthane), qui est un carburant. Je crois que l'erreur est dans la traduction du jeu.

Oui, avec la 0.8 cette piste est plus facile que dans les version précédentes il me semble. Dans mon souvenir, la montée dans le volcan était vraiment difficile, avec un talus qui devenait de plus en plus étroit, et si on avait le malheur de le prendre sur le côté, on avait toutes les chances de finir dans la lave. Or donc, en 0.8, je n'ai eu aucun problème avec ce passage dans le volcan, donc quelque chose a dû être modifié à ce sujet.

Pour les chewing-gums, curieusement j'avais l'impression qu'on ne pouvait pas les lâcher quand on voulait, mais seulement automatiquement, en se prenant un piège ou un tir adverse, ou quand ils arrivent en fin de vie. Il me semble pourtant avoir essayé, en appuyant sur la touche de tir, et que ça n'avait aucun effet. Il faudra que je réessaie.

C'est ça. Punaise, je viens de comprendre le nom, ça n'aurait pas dû m'échapper ça !

Pour Banlieue lustrée, je me prends aussi pas mal les bords de la piste, qui sont des murs et qui peuvent bien te ralentir, ou pire, t'arrêter net et te mettre dans une situation où il faut utiliser la marche arrière ! Il y a aussi un accélérateur à un endroit, qui si on ne fait pas attention peut t'envoyer derrière une barrière de bord de piste : à ce moment-là, autant appeler directement les secours, ça va plus vite que d'essayer de s'en sortir soi-même, mais quel temps perdu !

Si tu es en première position, par contre, mets-toi bien au centre et balance tes vacheries sur tes poursuivants, c'est l'endroit idéal !

Plus facile à dire qu'à faire : pour balancer des trucs sur ses poursuivants, il faut se retourner, enfin, tourner la tête, regarder derrière quoi, à ma connaissance, et c'est le genre d'endroit où il vaut mieux garer les yeux sur la route qui est devant non ?

Si tu veux dire que toutes les pistes ne sont pas faciles, c'est normal. Il faut prendre en main le véhicule, puis chaque piste. Personnellement, celles qui me donnent le plus de mal sont Banlieue lustrée et Fort magma, ainsi que celle qui est sur une planète bizarre et dont je n'ai pas retenu le nom.

Le principe retenu est que les fichiers livrés par la distribution sont dans /usr et les fichiers locaux (créés de rien ou modifiés de ceux de /usr) sont dans /etc.

C'est sensé, mais les mettre dans /usr/lib est une faute, pour des fichiers indépendants de l'architecture : leur place est dans /usr/share.

Le vénérable Roundcube ? Purée, tu viens de mettre un sacré coup de vieux à pas mal de logiciels, là...

Alors, je viens de me remettre à SuperTuxKart — et de finir le jeu en mode facile du coup — et c'est bien de cette piste dont je parlais. Seulement, j'y avais joué à une époque où les graphismes étaient un peu différents, et où le terrain de sélection de défi du mode histoire n'existait pas encore. Aujourd'hui, eh bien j'ai réussi à bien me débrouiller sur ce dernier niveau, enfin, contre un Nolok pour débutant...