gouttegd a écrit 1805 commentaires

Si tu utilise des tabulation c'est justement pour pouvoir changer sa taille.

Ben oui, c’est justement ça le problème. Si tu indentes ton code à coup de tabulation en partant du principe que, chez toi, 1 tab = 4 espaces (parce que c’est comme ça que tu as réglé ton éditeur), le formatage de ton code ne ressemblera plus à rien quand il sera ouvert dans un éditeur réglé différemment. A fortiori si ton style d’indentation implique de mélanger tabs et espaces, ce qui est semble-t-il assez fréquent (en tout cas j’ai vu ça assez souvent pour m’en tenir désormais au principe énoncé plus haut).

Depuis quand « remplacer 1 caractère \t par 4 caractères  » ne change pas la signification du caractère \t? Il est carrément supprimé !

Ben oui, précisément. Si on veut indenter sur quatre colonnes (ou deux, ou trois, ou ce qu’on veut), au lieu de continuer à utiliser un caractère \t en décrétant qu’il vaut 4 espaces de large, on le remplace par quatre espaces.

(Ce qui n’empêche pas de continuer à utiliser la touche Tabulation si on veut pour indenter, tous les éditeurs de texte dignes de ce nom permettant de changer la signification de cette touche — la touche, pas le caractère ! — pour signifier « indente d’un niveau » au lieu de « insère un caractère \t ».)

Là l'idée c'est de donner une meilleure sémantique à un caractère qui existe, et donc d'avoir un espoir à terme d'un comportement standard, portable

Sachant qu’en quarante ans les différents OS n’ont pas été fichus de se mettre d’accord sur le(s) caractère(s) à utiliser pour représenter une fin de ligne, j’ai beaucoup de doutes sur la possibilité de voir cette proposition devenir un « standard » (officiel ou de facto)…

Et de tous les innombrables débats sur l’indentation et l’usage des tabulations (grand sujet de bikeshedding s’il en est), j’ai pour ma part retenu une règle absolue : quel que soit votre style d’indentation, ne changez jamais la signification du caractère \t.

Autrement dit, si vous choisissez d’indenter sur 4 colonnes au lieu de 8, utilisez 4 espaces au lieu de configurer votre éditeur pour changer la valeur du tab stop de 8 à 4.

La solution proposée ici viole cette règle et conduira donc à un affichage du code variable selon l’éditeur utilisé (selon qu’il possède cette fonctionnalité ou non, selon qu’elle soit implémentée de la même manière que dans l’éditeur d’origine, et selon que les réglages — nombre de lignes considérées pour décider de l’alignement par exemple — soient les mêmes). J’ai beaucoup de mal à voir ça comme une bonne idée.

Il y a quelques mois, j’ai descendu ProtonMail en flèche dans un commentaire d’une dépêche sur OpenPGP.js pour leur « interoperability-washing », le fait qu’en dépit de leurs belles paroles sur l’intérêt d’utiliser un standard (OpenPGP) pour l’interopérabilité, leur solution concrètement ne permettait aux utilisateurs de ProtonMail de communiquer confidentiellement qu’entre eux.

L’annonce dans le lien ci-dessus répond de la meilleure des façons à cette critique en apportant précisément les fonctionnalités qui manquaient à ProtonMail pour permettre à un utilisateur de ProtonMail :

• d’exporter sa clef publique et de la diffuser comme bon lui semble, permettant à n’importe qui (même ceux qui n’utilisent pas ProtonMail) de lui envoyer un mail chiffré ;
• d’importer des clefs publiques de personnes non-utilisatrices de ProtonMail, permettant d’envoyer des mails chiffrés à ces mêmes personnes.

Bref, les bénéfices vantés de l’interopérabilité dont ProtonMail se targuait sont désormais réalité, ce qui vaut le coup je pense d’être souligné.

J’oubliais, il y a au moins une chose que vous pourriez faire pour me donner un minimum confiance dans votre produit : publiez le « Rapport Technique d’Évaluation » (réf. CSPN-RTE-Tixeo-Server, version 1.01 du 27 février 2017) qui a servi de base à la décision de l’ANSSI (pas le « rapport de certification » que vous publiez déjà et qui ne contient pour ainsi dire rien du tout, mais le rapport technique qui contient tous les détails de ce qu’a fait et observé l’auditeur).

Il n’est apparemment pas dans la politique de l’ANSSI de publier ce type de rapport, mais je suppose que vous devez en avoir obtenu une copie (j’espère, d’ailleurs, sinon comment êtes-vous supposés corriger les « manques ou incohérences » auxquelles il est fait allusion dans le rapport de certification ?).

Y a-t-il quelque chose qui vous empêche de le rendre public (est-ce explicitement interdit par l’ANSSI par exemple) ? Si non, alors pourquoi ne pas le publier ?

Mais nous avons vraiment l’impression que quel que soit le niveau de détails techniques que nous vous fournirons, vous nous accuserez de « snakeoil » ou de « name dropping » tant que vous n’aurez pas vu les sources…

Disclaimer : je ne parle pas au nom de la communauté LinuxFR.org, qui est diverse et dont les membres n’ont pas tous les mêmes sensibilités. Il n’y a pas que des libristes sur DLFP, loin de là (même si ce sont peut-être les plus voyants).

En ce qui me concerne, je considère qu’en matière de sécurité, la disponibilité des sources (sous une licence libre, pas seulement une mise à disposition en lecture seule sans les libertés qui font le logiciel libre) est une condition nécessaire. Pas suffisante (ce n’est pas parce qu’un produit est libre qu’il est forcément bon), mais absolument nécessaire. Donc en effet, vous aurez du mal à me convaincre de la sécurité de votre solution, encore plus à me convaincre qu’elle est plus sécurisée que toutes les autres. Si vous trouvez ça injuste, pas la peine de vous en prendre à moi. C’est vous qui avez choisi de faire du propriétaire.

Le problème avec les produits liés à la sécurité, c’est qu’un produit qui fait de l’excellent travail est indistinguable d’un produit moyen voire même d’un produit qui fait franchement de la merde. Et le fait est que nombre d’éditeurs ont largement profité (et profitent encore) de ce fait pour vendre à leurs clients ce qui n’est rien d’autre que de la poudre de perlimpinpin (snake oil) — après tout pourquoi se casser la tête à faire un produit vraiment sécurisé quand on peut juste prétendre qu’il l’est ?

Je ne dis pas que c’est votre cas, seulement voilà, chat échaudé craint l’eau froide. Encore une fois, pas la peine de vous en prendre à moi. Prenez-vous en à tous les éditeurs qui refourguent de la merde à leurs clients, et constatez au passage que ces éditeurs ont tous un point commun : leurs produits sont propriétaires…

Cela étant dit, je répète que je ne parle pas pour tout le monde ici. Plusieurs utilisateurs de DLFP n’ont aucun soucis avec les logiciels propriétaires (à la manière d’un Torvalds justifiant l’utilisation de BitKeeper, ils utilisent ce qu’ils estiment être les meilleurs outils pour une tâche donnée, et si ce doit être des logiciels proprios, so be it), donc libre à vous d’essayer de les convaincre. Par contre, même ces utilisateurs-là sont en général friands de technique et peu tolérants au discours marketing…

lors des question, ils ont apportés de vrais arguments techniques

Où ça ?

Ils ont apporté des liens vers leur site (riche en marketspeak mais très pauvre en explications techniques, comme noté plus haut), suggéré de consulter leur « livre blanc » (idem), se sont vantés de leur succès (« fiers du chemin accompli etc. ») ou de leur spécifité (« notre techo n’a rien à voir avec les technos traditionnelles »), se sont exclamés que leur « techno est bien une réalité et certainement pas un snakeoil! »… mais des arguments techniques, et a fortiori des arguments techniques qui soutiendraient leur thèse selon laquelle leur solution fournit « un niveau de sécurité encore jamais atteint », désolé je n’en vois aucun.

Ils ne prétendent pas le contraire d’ailleurs puisque leur dernier message mentionne « nous comprenons que vous vouliez plus d’informations technique et allons voir ce que nous pouvons faire ». OK, mais pour l’instant on attend de voir, justement.

(Et non, parler de « AES256 end-to-end » ou « échange Diffie-Hellman » comme ils le font sur le site ou leur livre blanc n’est pas de l’argumentation technique, c’est du name-dropping.)

Ça ne justifie pas de les insulter, on est d’accord. Mais pas de raison non plus de les accueillir avec des fleurs quand ils viennent juste déverser leurs discours marketing. Indépendamment du fait que leur solution soit propriétaire d’ailleurs, on a déjà vu passer sur ce site des annonces de projets libres qui se sont fait descendre faute de détails techniques…

Alors, dig, host et delv sont trois programmes fournis avec le serveur DNS BIND, qui remplissent à peu près le même rôle.

Je ne connais pas l’étendue exacte des différences entre les trois (jamais vraiment eu la curiosité de regarder à vrai dire, j’ai pris l’habitude d’utiliser quasi-exclusivement delv), mais a priori :

• host est le plus simple des trois, utile quand on veut juste résoudre un nom sans chercher trop loin ;
• dig et delv sont des outils plus avancés, qu’on utilisera typiquement pour investiguer un problème DNS par exemple.

Concernant les deux derniers, l’intérêt de delv par rapport à dig, surtout quand on veut faire du diagnostic DNS, est qu’il utilise exactement le même code de résolution que celui du serveur BIND lui-même, contrairement à dig qui a une implémentation différente. Du coup, ce que l’on voit avec delv est normalement exactement la même chose que ce verrait et répondrait BIND.

Ce qui est cocasse, c’est qu’apparemment elysee.fr est hébergée sur les serveurs de… Level 3 (maintenant CenturyLink), un opérateur américain.

$ delv www.elysee.fr
; unsigned answer
www.elysee.fr.      586 IN  CNAME   cdn.cdn-tech.com.c.footprint.net.
cdn.cdn-tech.com.c.footprint.net. 216 IN A  4.26.226.126
cdn.cdn-tech.com.c.footprint.net. 216 IN A  4.26.233.254
cdn.cdn-tech.com.c.footprint.net. 216 IN A  8.254.119.126
cdn.cdn-tech.com.c.footprint.net. 216 IN A  208.178.167.254

$ whois 4.26.226.126
[…]
OrgName:        Level 3 Parent, LLC
Address:        100 CenturyLink Drive
City:           Monroe
StateProv:      LA
Country:        US
[…]

Les autres adresses (qui changent d’une interrogation à l’autre, s’agissant d’un CDN) donnent la même réponse.

À la décharge de la présidence : ça ne semble pas être directement de leur fait, apparemment ils ont bien confié l’hébergement à une boîte française (CDN Tech / Écritel)), c’est juste que cette boîte se trouve avoir pour partenaire Level 3…

Mais quand même, je maintiens que c’est cocasse que le site de l’Élysée soit in fine hébergé aux States, même si ça ne me choque pas outre-mesure.

Sur l’inaccessibilité en HTTPS, là en revanche, pour moi en 2018 c’est inexcusable.

Est-ce que j'ai mal regardé, ou le lien a disparu ?

Apparemment les dons n’étaient pas versés à Patrick directement mais passaient par la même société qui gère la boutique Slackware. Patrick a fait retirer la page de don après avoir constaté qu’il ne recevait rien des dons en question.

Et même avant cela la différence entre les recettes des ventes et son bénéfice était faible.

Tu veux dire que la différence était grande (et donc que le bénéfice pour Pat était faible), non ? (Exemple pour la version 14.2 : $100K de recettes générées par la boutique, dont $15K de bénéfices reversés à Pat)

Ce ne sont pas des informations, mais de la pure communication.

Et pour information leur « livre blanc » (qu’ils fournissent contre une adresse e-mail) est du même acabit. Il contient à peine plus d’infos que le site lui-même.

Sur l’absence de portes dérobées par exemple, l’argument se limite au fait que Tixeo étant une société française, elle n’est pas sujette au Patriot Act américain. Ben voilà, je suis rassuré, c’est bien une preuve qu’il ne peut pas y avoir de portes dérobées ⸮

Ah, et ils ont aussi une super technique pour éviter les vulnérabilités : il suffit d’éviter les bugs. Comment personne n’y avait jamais pensé avant ?

Bref, si ce sont des détails techniques que vous voulez, le « livre blanc » n’est pas pour vous, pas la peine de leur filer une adresse e-mail…

Pour effectuer la CSPN il est obligatoire que les auditeurs aient accès au code source

En parlant de source, tu en as une pour cette affirmation ?

Parce que d’après les propres documents de l’ANSSI, c’est totalement faux.

• Certification de sécurité de premier niveau des produits des technologies de l’information, ANSSI-CSPN-CER-P-0/1.1 :

Le déroulement de l’évaluation repose sur :

• la documentation fournie ;
• au minimum, les bases publiques de vulnérabilités pour l’analyse du produit par rapport aux vulnérabilités connues pour le type de produit analysé ;
• le produit lui-même, installé sur une plate-forme de test aussi représentative que possible de son environnement prévu d’utilisation

Il n’est fait nulle mention du code source dans ce document.

• Critères pour l’évaluation en vue d’une certification de sécurité de premier niveau, ANSSI-CSPN-CER-I-02/1.1

4.4 Phase 4 – Analyse de la conformité – revue du code source (si disponible)

Donc l’évaluateur peut procéder à une revue du code source si l’éditeur du produit le lui fournit, mais ce dernier n’a aucune obligation de le faire.

Et l’ANSSI n’attend de la revue de code qu’elle ne porte que sur

la lisibilité et la structuration du code source (exemples de critères : existence de commentaires, découpage en modules, typage des données, portabilité, etc.), en précisant les modules qui ont été regardés.

Donc, on n’attend de la revue de code (quand elle a lieu) ni qu’elle soit exhaustive (l’évaluateur peut ne regarder qu’une partie des modules), ni qu’elle ne cherche des failles ou des vulnérabilités.

Ah, et j’adore aussi le fait que le Rapport Technique d’Évaluation (RTE), référencé dans le rapport de certification (et qui j’imagine contient les détails qui ne figurent pas dans ce dernier) ne semble disponible nulle part.

Mais pourquoi voudriez-vous vous embêter avec un « rapport technique » alors qu’on vous dit que c’est secure ?

’tain, la prochaine que je rédigerai une dépêche sur GnuPG ou assimilé, je me casserai moins la tête. Une phrase et ce sera bouclé : « C’est secure parce que je le dis, biatch ! »

une revue sérieuse de la sécurité du produit (et indique y compris que la partie propriétaire du code source a été expertisée)

Oui, et voilà la tronche de l’expertise dans toute sa splendeur :

2.3.3. Revue du code source (facultative)

L’évaluateur a effectué une revue de la partie propriétaire du code source et estime que le code est lisible et correctement documenté.

Circulez, le code est lisible et documenté, y a rien à voir.

Je n'ai pas de raison de penser que ce n'est pas effectivement une solution de vidéo-conférence sécurisée.

Moi j’ai toutes les raisons de le penser. On a suffisamment d’exemples de fournisseurs de « solutions de sécurité » qui vendent de la merde en boîte pour discréditer automatiquement quiconque fournit aussi peu d’information sur sa solution miracle. Sur un produit de sécurité il ne peut pas y avoir de présomption de fiabilité. Ou le fournisseur démontre que sa solution est fiable ou c’est un vendeur d’huile de serpent.

Certifiée ou pas, la sécurité par l’obscurité reste de la sécurité par l’obscurité.

Et je ne dis pas ça à la légère; je suis conscient du travail de rédiger une dépêche

Oh ben là tu n’as pas de soucis à te faire ou de scrupules à avoir, cette « dépêche » n’a pas demandé de gros efforts à son auteur vu que c’est une reprise intégrale d’une annonce déjà publiée sur le site de Tixeo… annonce rédigée par la même personne très probablement (Olivier Azan).

(Ah si, il y a quand même du travail derrière : dans l’antépénultième paragraphe, l’auteur a remplacé « politique de sécurité réseau des organisations » par « politique de sécurité réseau des entreprises ». On applaudit l’effort pour s’adapter au public du site, SVP.)

Et sur le fond, que ce soit en lisant cette dépêche ou en cherchant sur le site de Tixeo, mon détecteur de snake-oil a explosé (fait chier, c’était un modèle Schneier de 1999). Le seul détail technique est, je cite, « End-to-End encryption AES 256 ».

Ainsi pour installer/mettre à jour toutes les bibliothèques fournies par Slackware il suffit d'installer la série l (comme library)

# upgradepkg --install-new /path/to/slackware64/l/*.t?z

Ça ne mettra sûrement pas à jour toutes les bibliothèques, non…

Ça ne mettra pas à jour la bonne quarantaine de bibliothèques partagées fournies par le paquet aaa_elflibs (qui se trouve dans a/), ni les bibliothèques partagées de la glibc et d’OpenSSL (paquets glibc-solibs et openssl-solibs, qui se trouvent dans a/).

Ça ne mettra pas à jour toutes les bibliothèques qui, parce qu’elle font partie d’un projet plus large, sont inclues dans un paquet situé ailleurs que dans l/.¹ Par exemple et pour n’en citer que quelques-unes : libcryptsetup (dans a/cryptsetup), libFLAC (dans ap/flac), libmysqld (dans ap/mariadb)…

Ça ne mettra pas à jour non plus certaines bibliothèques qui ont pourtant leur propre archive source indépendante, mais qui pour diverses raisons ont été classées ailleurs que dans l/. Par exemple gpgme, libgpg-error ou encore cyrus-sasl, qui se trouvent toutes dans n/.

Ça ne mettra pas à jour la quasi-totalité des bibliothèques de X.org, qui se trouvent pour la plupart dans x/.

Ça ne mettra pas à jour la quasi-totalité des bibliothèques de KDE, qui se trouvent pour la plupart dans kde/.

J’aime beaucoup Slackware et je n’utiliserai une autre distribution pour rien au monde, mais sur ce point-là il faut regarder la réalité en face : la répartition des paquets en « séries » est purement un héritage de l’époque des disquettes. On fait très bien avec et il n’y a pas de quoi s’en plaindre, mais prétendre y trouver des avantages, c’est pousser le bouchon un peu loin à mon avis.

---

¹ Rappel : Slackware ne décompose pas les projets upstream en multiples paquets. Sous Slackware, à de rares exceptions près, une archive source upstream = un paquet Slackware. Contrairement à Debian par exemple, où à partir d’une seule archive source foo-X.Y.Z.tar.gz on génère des paquets foo-bin pour le programme foo proprement dit, foo-libs pour les bibliothèques, foo-dev pour les fichiers d’en-tête, foo-doc pour la documentation, etc.

Tous les bugs qui pourraient être inclus dans Slackware sont des bugs "genuine", liés à l'upstream

Bémol : on n’est jamais à l’abri d’introduire un bug lors de l’empaquetage, même quand on utilise les sources telles que fournies par l’upstream, sans patch intempestif.

Slackware a connu un bug de ce genre dans le paquet python-2.7.13 il y a quelques années. Le module multiprocessing.synchronize fournit par ce paquet ne fonctionnait pas, apparemment parce que le paquet avait été compilé par Pat sur une machine où /dev/shm n’était, pour quelque raison que ce soit, pas monté, et que le système de build de Python avait détecté l’absence de /dev/shm et avait conséquemment désactivé certaines fonctionnalités du module multiprocessing.synchronize (qui a besoin de /dev/shm pour fonctionner correctement).

Pat a corrigé le problème quelques jours plus tard, simplement en recompilant le paquet Python après s’être assuré que /dev/shm était monté sur sa machine de build.

Morale de l’histoire, à garder en tête pour tous ceux qui construisent des paquets pour quelque système que ce soit : un paquet n’est jamais construit dans le vide — le système sur lequel vous compilez vos paquets a une influence sur le paquet résultant.

Je ne suis pas sûr de comprendre ce besoin d’inventer un nouveau mot ou de surcharger le sens du mot « simple ». On a déjà « simple » vs « complexe » d’un côté et « facile » vs « difficile » de l’autre.

De ce que je comprends de la « simplexité », c’est en gros rendre « facile » (à comprendre ou à utiliser) un système complexe (certainement en le rendant encore plus complexe…). Faut-il vraiment un nouveau mot pour ça ?

Attention de ne pas confondre simplicité et facilité (d’utilisation).

Slackware est simple. Et c’est peut-être justement pour ça qu’elle peut apparaître difficile d’utilisation (notamment pour les débutants), parce que la distribution ne fait pas grand’chose pour prendre en main le nouveau-venu (e.g. pas d’installateur en mode graphique, pas d’outil de configuration spécifique à la distribution, etc.).

À l’inverse, une distribution comme Ubuntu peut être plus facile à prendre en main pour certains, mais au prix d’une plus grande complexité.

Et entre les courbes Brainpool P-* et Curve 25519, quelles sont les différences

Grosso modo les mêmes qu’entre la NIST P-256 et la Curve25519.

Les courbes du NIST et les courbes Brainpool sont similaires. Elles sont décrites par une équation de Weierstrass dans les deux cas, seuls les paramètres étant différent :

• NIST P-256: y² = x³ − 3x + 41058363725152142129326129780047268409114441015993725554835256314039467401291
• BrainpoolP256: y² = x³ − 3x + 46214326585032579593829631435610129746736367449296220983687490401182983727876

La vraie différence entre les deux réside dans la méthode utilisée pour générer les paramètres de la courbe. Le NIST a généré ses paramètres en condensant une graine sortie de nulle part (d’où les soupçons de manipulation évoqués plus haut : et si le NIST avait choisi cette graine en sachant que la courbe résultante était vulnérable à une attaque connue seulement de la NSA ?), alors que la graine utilisée pour la courbe Brainpool a été choisie selon une procédure décrite en annexe du RFC 5639.

Personnellement, je ne vois pas vraiment d’intérêt aux courbes Brainpool. Mise à part le fait que leur génération est plus transparente, elles souffrent a priori des mêmes défaut que celles du NIST.

La courbe 25519, elle, est décrite par une équation de Montgomery (y² = x³ + 486662x² + x). Entre autres avantages, cette forme permet de réaliser des opérations sur la courbe en temps constant, éliminant une source d’attaques par canaux cachés.

Oui mais non. Si il y autant de protection dans une carte à puce, ce n'est pas pour faire joli. D'ailleurs, si un secret est unique à une puce, à moins d'un bug, il est impossible de sortir le secret

Oui mais non. Je ne suis pas spécialiste de la question, mais tous les papiers que j’ai eu l’occasion de lire sont d’accord pour dire que les protections des cartes à puce compliquent l’extraction des données et peuvent la rendre très chère (peut-être suffisamment pour la rendre hors de portée de la plupart des attaquants à part les « attaquants de classe III », i.e. les well-funded organisations), mais personne ne prétend que ça rend l’extraction impossible (à part peut-être les constructeurs de cartes à puce).

Au final, c’est juste de la sécurité par l’obscurité.

Ben non l'alternative c'est gépégé

Ça fait plusieurs fois que j’entends parler de ce truc, faudrait vraiment que je me renseigne à ce sujet. Ce serait bien s’il y avait des moules sur DLFP qui connaissent un peu et qui seraient prêtes à écrire des journaux là-dessus.

---

Plaisanterie mise à part, le chiffrement de bout en bout, c’est bien mais il faut rester conscient que ça n’empêche pas les fournisseurs de messagerie d’avoir connaissance de plusieurs choses :

• Qui parle à qui ?
• À quel moment ?
• Quel est le « volume » des communications (nombre de messages échangés + la taille de chaque message) ?
• De quoi parlent-ils (le sujet des messages) ?

Ça n’a rien de spécifique à Google, c’est inhérent au courrier électronique : tes mails passent par ton fournisseur et par le fournisseur de ton interlocuteur. (Et on ne me fera pas croire que Google est le seul fournisseur de messagerie à « lire » les mails de ses utilisateurs.)

C’est mal ? Peut-être mais c’est grâce à ça que nous avons une interopérabilité, que les utilisateurs de Google peuvent échanger des mails avec les utilisateurs de Yahoo qui peuvent échanger des mails avec les utilisateurs du service de messagerie de l’université du coin qui peuvent échanger des mails avec les auto-hébergés.

L’alternative serait un système en vase clos où les utilisateurs de Google ne peuvent communiquer qu’avec les utilisateurs de Google, les utilisateurs de Yahoo ne peuvent communiquer qu’avec les utilisateurs de Yahoo et ainsi de suite… Certes, ça résoud le problème des conditions d’utilisation (toutes les parties à une communication sont chez le même fournisseur dont ils ont tous accepté les conditions). Mais ça ne me fait pas envie, perso… Le courrier électronique est l’un des derniers bastions de l’interopérabilité et même avec tous les défauts que ça engendre (complexité, spam, + le problème mentionné ici) j’apprécierai qu’il le reste.

J’ai foiré ma troncation de la citation au point d’en changer complètement le sens, il faut lire

Une autre alternative […] est l'applet Javacard publié par l'ANSSI

Toutes mes confuses.