L'auteur est la personne qui a reviewé le patch du kernel Linux mergé par torvalds.
La faille semble en effet liée à l'exécution spéculative de certaines instructions. En juillet, celui-ci a réalisé que les données de l'espace noyau pouvaient se retrouver en cache en éxecution non privilégiée, alors que l'accès devrait lever une faute de protection. Il ne peut en revanche pas lire le contenu de la mémoire. Entre ce moment et aujourd'hui, je pense que ce qui a été trouvé est une façon de lire cette mémoire (les détails viendront sûrement dans les jours à venir).
Visiblement, seuls les processeurs Intel sont concernés, les AMD implémentant correctement cette vérification dans le cadre de l'exécution spéculative.
Le fix implémenté par les OS, si j'ai bien compris, est ainsi de complètement séparer les espaces kernel et user (alors que jusqu'à présent, pour des raisons de perf (éviter un flush de TLB lors du passage en noyau), l'espace kernel était mappé en haut de l'espace user (d'où les 3GB de mémoire utilisable seulement sur un processeur 32 bits). Évidemment, l'accès aux pages du kernel est protégé via un bit d'accès User/Supervisor (http://wiki.osdev.org/Paging, section Page Directory). C'est visiblement ce bit qui n'est pas respecté dans le cadre de l'exécution spéculative.
J'imagine que le plus gros bazar dans cela, en plus de forcer un flush de la TLB (ce qui explique la chute des perfs dans les benchmarks), est de pouvoir toujours lire la mémoire user depuis le kernel, ce qui demande de jongler entre les 2 espaces. Je pense que c'est ce qui fait le plus gros du patch intégré au noyau. Et si torvalds l'a mergé sans broncher en insistant, c'est car c'est grave, et qu'il est encore impossible de divulguer cette faille.
Ce bug est donc assez exceptionnel dans le sens où aucune mise à jour côté microcode du cpu ne peut venir corriger ce problème (sur certains CPU avec des bugs hardware, c'est aux compilos de s'adapter). Il reste donc aux OS à corriger ce souci (Linux, Windows, FreeBSD, MacOS, et tous les autres). La question du parano en suspens est: cette faille était-elle connue avant par certains gouvernements et l'ont ils utilisé?
Ce projet, pour ce que j'en ai compris, vise à répondre à la problématique "Comment obtenir la clé publique de mon correspondant?", ce qui, à mes yeux, est le plus gros frein à l'adoption massive du chiffrement pour le grand public. Et avec une volonté de faire collaborer les services de mails existants.
C'est donc un annuaire de clés, comme il peut déjà en exister (http://pgp.mit.edu/) mais à plus grande échelle, et avec plusieurs acteurs.
L'initiative est louable, cependant, je ne connais pas les détails techniques, notamment la grande question: Comment garantir que la clé de X que le service m'a donné est bien la bonne? À l'heure actuelle, on répond à cela en la transmettant via un canal secondaire (une page web le plus souvent).
Les applications sont multiples, et pas que pour les webmails. Il faut le voir comme un DNS pour le chiffrement, à la différence qu'on associe une clé à une adresse mail plutôt qu'une IP à un nom de domaine.
Que ce soit ce projet ou un autre, je suis convaincu que c'est cette avancée qui démocratisera le chiffrement des mails à grande échelle.
À coup de ZwCreateProcess (API NT non documenté), la chose semble possible. Cygwin ne l'a pas exploré pour des raisons de rétro compatibilité avec Windows 9x. C'est sûrement sur ça que se base ce nouveau projet. On peut le voir comme un successeur de SFU en quelque sorte, du côté programmeur en tout cas.
Je ne connaissais pas ce projet (qui a l'air tout neuf).
En gros, ils ne se basent pas sur la WinAPI mais directement sur l'API NT (accès au noyau). En théorie ça a l'air beau et génial, en pratique, même s'ils feront mieux que cygwin dans leur design/perf, ils ne pourront pas ajouter une feature au noyau NT qui n'existe purement et simplement pas. À surveiller…
La grosse avancée sera le jour où Windows fournira une couche POSIX complète sous windows.
Cygwin émule celle-ci, en l'implémentant complètement. Le gros hic vient du support de certaines fonctionnalités telles que le changement d'id user ou encore fork. Ces deux points ne sont absolument pas fournis par la WinAPI et les devs de Cygwin ont trouvé des moyens très astucieux de les émuler. C'est ainsi qu'on peut avoir le serveur openssh sous windows ou encore forker à souhait (avec une sacré pénalité, vu que la librairie cygwin recopie tout l'espace d'adressage du processus parent à la mano!). Le pire reste qu'implémenter ces deux syscalls dans NT ne doit vraiment pas être compliqué, c'est vraiment une question de politique…
J'ose croire que ça avance dans le bon sens vu les dernières annonces faites par Crosoft. Après, restera plus que le support de X11 ou Wayland, la possibilité d'ajouter un shell graphique custom, et on pourra ptet enfin faire quelque chose de supportable sous cet OS. Après, ok, c'est pas libre, et ça ne justifie en rien la politique scandaleuse de cette boîte, mais ça me permettrait au moins de rebosser sans avoir peur de refoutre les pieds sous explorer.exe.
Je comprends tout à fait la problématique de bloquer un domaine au delà du navigateur. Pour cette question, l'application Adaway (sous Android - dispo sur F-droid) et https://github.com/sedrubal/adaway-linux répondent au besoin en patchant le fichier /etc/hosts.
Ça a le bon goût d'être léger et efficace, multiplateforme (même Windows le respecte!). Cependant, ça demande un accès root (ce que demandera aussi ton serveur de toute façon pour binder le port 53).
Du coup, je me demande les avantages d'un DNS custom (en dehors de l'intérêt technique de le faire bien sûr) par rapport à cela.
Je suis ce développement de très près qui permettrait enfin de s'affranchir de visual pour compiler sérieusement des projets sous windows. Reste à voir si les perfs suivront (comme souvent avec clang). De ce côté, le compilateur de Microsoft se débrouille plutôt très bien, malgré de nombreux autres défauts.
C'est une problématique très intéressante que tu soulèves ici.
Malheureusement, les gens soucieux de ces problèmes se soucient en général simplement des versions de librairies utilisées (que ce soit en C/C++ ou même d'autres langages). Alors qu'en pratique, ton compilateur et tous les outils de ta toolchain sont aussi importants. Pour moi la reproductibilité implique de recréer le même binaire au bit près, pas de s'assurer des dépendances sur des librairies.
Dans ma dernière expérience professionnelle sur le sujet, j'avais mis en place une forme de conteneur léger (à coup de chroot) basée sur debian testing, avec génération automatique chaque semaine ou quand besoin d'une nouvelle lib/version de compilo. Le tout rapatrié avec rsync via ssh. Sinon possib de monter tout le bouzin via NFS mais c'était trop chiant en infra pour nous. Ça offrait une belle portabilité peu importe la distribution linux utilisée par les collègues (et simplifie l'intégration continue accessoirement). Quant à l'arrivée d'un nouveau, il suffit de faire: git clone && get_env.sh && make. Simple et efficace au possible. Il me restait, mais je ne l'ai pas fait, à "versionner" cet environnement de build (qui est une chose très importante aussi). Pour cela, un montage BtrFS avec snapshots permet de faire un stockage incrémental (on ne stocke que les diffs) et adapté. Reste à ajouter un hash quelque part et pointer sur le bon dans ton code, et tu as un environnement de build complètement déterministe, mais pour Linux uniquement. Un jour si je me motive, faudrait que je package et publie le tout, je suis sûr que ça pourrait attirer du monde. Bien plus qu'une solution bricolage comme Biicode (c'est mon humble avis).
Il reste le problème de la cross compilation. MacOS ne m'intéresse pas d'un iota. Pour les BSDs un cross compilo fait le taff. Quant à Windows, soit tu peux cross compiler un gcc, soit, une autre approche que j'avais tenté sur mon temps libre, c'est d'utiliser le compilo de visual (cl.exe) via wine (et pas visual lui même). Ça fonctionne rudement bien (modulo des variables d'env à setter) et si je devais m'occuper de ça un jour, ce serait ma voie d'approche. Avec le wine dans l'env de build décrit au-dessus, tu obtiens une solution déterministe pour le build Linux/Windows depuis toute version/distrib de Linux.
Une fois cela fait, un travail important reste de packager toi-même toutes les librairies dont tu dépends. Chez nous, on s'en était assez facilement sorti avec un peu de script.
Cette façon d'approcher, reste, je pense, la plus simple et efficace. Des collègues plutôt orientés Java m'ont montré Nexus et le concept d'artifact repository. Pour moi, ça revient à de la gestion de libs, le tout dans une belle usine à gaz webistique. J'imagine que ça dépend des goûts de chacun, moi je n'ai pas accroché en tout cas…
Je passerai sur le ton plainte associé à la forme de ton journal (si tu veux un beau bureau qui marche tout seul, t'as qu'à aller chez la pomme… ou au moins sous Debian stable), pour me concentrer sur certains éléments de fond.
Ce que tu décris, à savoir refaire du neuf moins bien que le vieux, n'est, à mes yeux pas l'apanage de l'écosystème Linux. On peut le voir sur les nouvelles versions d'Android (Lollipop, je trouve l'ergonomie moins pratique que kitkat, sans parler du style et des couleurs), de Windows (le 7 était franchement bien, mais depuis…) et ptet même chez Apple (je connais pas).
Le truc bien sous Linux, c'est que tu as le choix. C'est cela qui fait que je ne pourrai plus retourner sous un autre OS (en dehors des BSD). Il existe encore XFCE (si tu veux un vrai environnement) ou bien les tiling window manager (Awesome pour ma part) qui répondent complètement à mes besoins de barbu, ce que Madame Michu n'appréciera pas, j'en ai conscience. Quant à systemd, il y a eu pire, et malgré tout le mal que j'en pense, aujourd'hui sur ma Jessie ça marche et j'ai appris les 3 commandes qu'il fallait pour l'administrer.
Mais le grand public ne cherche pas ça, et c'est bien là l'origine du problème. J'ai montré Linux à un ami qui voulait s'y mettre, et il a rêvé devant KDE et ses effets kikoolol, là où la légèreté de XFCE ne l'a pas fait bronché. C'est assez caractéristique de ce qui se passe dans l'informatique aujourd'hui. Autant à une époque cela me gênait, autant aujourd'hui je m'en fous. Que ceux qui aiment les usines à gaz développent/utilisent Gnome/KDE et se touchent la nouille, et pour les autres, restons libres en choississant nos programmes individuellement plutôt que faisant partie d'un environnement de bureau (en vrac: awesome, cmus, thunderbird, firefox, mplayer, …).
Et pour finir sur un troll, je me demande si c'est pas mieux que le desktop Linux n'ait jamais percé au grand public. Quant on voit le scandale systemd, ça aurait sûrement fini avec une migration des projets intéressants pour bosser sous BSD.
J'ai pas mal utilisé Magic Lantern sur mon 650D et ils ont vraiment fait un travail admirable.
En revanche, je suis un peu plus sceptique sur le fait de faire tourner un autre OS complet sur un reflex. En dehors de la réutilisation de code existant (et encore… on ne fera pas tourner gimp sur l'écran), la plupart des fonctionnalités d'un reflex restent limitées. Et le scripting Lua ajouté par ces braves gens de chez ML permet déjà de faire un peu ce qu'on veut. Sans compter que la plupart des limites dans lesquelles les devs butent aujourd'hui sont plutôt d'ordre matériel (comme comment utiliser le DMA pour balancer de la vidéo en RAW sur la carte SD) que logiciel.
Sincèrement, il n'existe pas de secret. On n'entre pas dans le top 3 mondial des entreprises en aidant l'humanité ou en faisant simplement des produits cools avec des bords arrondis.
Et encore, simplement chouiner sur une différence de comportement entre navigateur me semble le dernier cadet des soucis avec la situation actuelle.
Et ne parlons même pas des problématiques de vie privée…
A propos de tout ça, je me demande ce qu'ils en pensent les employés "connus" de google ou bien s'ils s'en tapent étant donné qu'ils ont 2 jours de boulot payé pour hacker sur un truc cool en open source.
On peut aussi tout faire dans le .bashrc, question d'éviter de s'emmerder avec encore un autre fichier en utilisant la command "bind"…
J'en profite pour poster ma partie, avec notamment des trucs sur l'autocompletion (pas de hidden files sans ., cacher le préfixe commun entre plusieurs fichiers, …)
# readline settings
# ignore case for auto completion
bind "set completion-ignore-case on"
# ignore diff between - and _
bind "set completion-map-case on"
# show directly completion results after first TAB
bind "set show-all-if-unmodified on"
# limit what is shown for completion (hide prefix bigger than 2 char)
bind "set completion-prefix-display-length 2"
# do not complete hidden files
bind "set match-hidden-files off"
En gros, CT maintient le concept de CA mais leur demande de vérifier le contenu du log émis (pour voir qu'aucun nouveau certificat n'a été émis). Cela rejette donc la sécurité sur eux et permet une détection de problèmes seulement après une brèche. C'est donc moyen.
DNSChain offre de son côté de plus solides garanties. C'est le même algo que Bitcoin qui est utilisée, sauf que la monnaie a été modifiée pour attacher des données sur chaque noeud: Namecoin. On associe donc une monnaie virtuelle à un système de gestion de noms de domaines.
Tout comme Bitcoin, la sécurité est offerte par le fait qu'un attaquant doit disposer d'une puissance de calcul colossal pour dépasser celle de tous les autres noeuds du réseau. De plus, chacun peut créer gratuitement son identité, plus besoin d'avoir des CA ou un provider de mail qui fait ce boulot contre rémunération.
Merci beaucoup pour ce lien. J'ai pris le temps de creuser un peu le sujet et voici un résumé de ce que j'ai compris. Si j'ai écrite une bêtise, merci de me corriger.
Le problème de la distribution de clés revient exactement au même problème des certificats pour l'accès sécurisé à certains sites/services (SSL). C'est très logique mais sincèrement je n'avais pas fait le rapprochement. De là, on peut regarder les solutions à ce souci.
Parmi celles-ci, on compte:
- Convergence
- Certificate Transparency (CT)
- DNSChain
Convergence, proposé par Moxie, l'auteur de TextSecure, propose en gros de remplacer les CA par un ensemble de pairs qui valident un certificat. En gros, plusieurs identités doivent répondre oui à la question "Mon certificat est-il le bon?".
Certificate Transparency, tout comme DNSChain, prone l'emploi d'hash tree, ou Merkle tree, utilisé entre autres dans Git ou encore Bitcoin. En gros, on crée une chaîne de blocs communes pour tout le monde, dont chaque noeud est un hash de ses fils. Cela résout le problème élégamment mais pose celui de la réconciliation, c'est à dire d'obtenir le même arbre pour plusieurs opérations se déroulant sur différentes machines. Et de ce côté là, les 2 diffèrent:
Certificate Transparency propose de centraliser, et accessoirement que des moniteurs doivent être en place pour vérifier le contenu de l'arbre.
DNSChain quant à lui propose une réconciliation différente (plutôt dans l'esprit de Bitcoin) pour que la vérif puisse se faire directement depuis les valeurs de l'arbre.
Moralité, tout n'est pas clair dans mon esprit mais une fois le problème sécurisé de l'accès à des sites résolus, on pourra utiliser cette solution pour la diffusion de clés publiques pour les adresses mails.
Quant aux clés privées, un simple stockage temporaire chiffré avec de l'AES-256 et une passphrase d'au moins 25 caractères devrait permettre la synchro facile entre devices. Bon ça c'est mon idée.
Je ne parlais pas de transmettre la clé pour chaque échange, j'ai du mal m'exprimer.
Je précisais l'échange initial de clés publiques, nécessaire avant le premier mail. Aujourd'hui tu récupères la clé à la mano de ton correspondant et tu la rentres dans ton mailer. Pour le grand public, c'est trop complexe. Si cela était automatisé (via ton navigateur par exemple), comme une requête DNS pour récupérer l'IP, ce serait bien plus simple et ce serait un premier vrai pas vers le chiffrement grand public.
Reste la possibilité de vérifier après coup le fingerprint, comme tu le dis, mais qui te dis que ton message ne sera pas modifié en cours (principe du MITM)? Quant au concept du "C'est trop lourd pour le faire à grande échelle", j'ai ravalé cela il y a un petit moment déjà…
ton projet est une bonne initiative même si je pense que la création d'un nouveau canal de discussion (il y en a tellement) pose problème. À l'heure actuelle et à ma connaissance, seul TextSecure (https://whispersystems.org/) permet une discussion asynchrone, chffrée, avec garantie de PFS. WhatsApp a déclaré qu'ils s'en étaient inspirés, mais sérieusement, quel utilisateur de WhatsApp croit au respect de sa vie privée?
Je ne suis pas utilisateur de messagerie instantanée, car soit les garanties en termes de sécurité sont absentes, soit (comme pour XMPP), cela demande aux deux parties d'être connectées. Et cela est un souci. Je n'utilise pas non plus TextSecure car, pour l'instant, il repose encore sur le framework GCM de Google pour le Push de messages. En attendant l'implem à base de Websockets, je n'utilise rien d'autre.
Reste donc les bons vieux mails, que j'utilise de façon non chiffrée car de toute façon, presque aucun de mes contacts ne connait tout cela. Mais je pense qu'à terme, un chiffrement massif des mails (il faudrait convaincre les gros providers de s'y mettre, et là c'est dur) serait une bonne chose. Reste le souci de gestion des clés. Autant pour la privée, je pense qu'il est possible de faire un truc bien, facilement déployable sur plusieurs devices, autant vérifier sa clé publique avec un autre canal de communication que celui qu'on utilise me semble lourd. Trop de gens accepteront la clé qu'ils voient sans réfléchir, ouvrant la porte à un MITM massif sur ces échanges.
D'où ma question, connaissez vous des recherches ou des papiers parlant du problème de la distribution des clés publiques via un annuaire (comme une sorte de DNS de la crypto), de façon sécurisée? De sorte que si l'annuaire tombe entre les mains du vilain, les utilisateurs le voit. Et le tout, sans contrainte de connexion des deux parties simultanément (Diffie-Hellman).
Je ne suis pas expat, mais voyageant depuis quelques mois dans divers pays dont l'accès à Internet reste variable, j'ai eu ce souci de communication.
Je n'utilise plus skype car je trouve leur version Linux à chier, sans compter les problèmes de vie privée associés (mais bon, le réseau téléphonique est probablement surveillé de la même façon). Et enfin, la plupart des gens de ma famille ne sont pas très branchés informatique.
N'utilisant pas de sim locale, impossible pour moi de faire du callback comme tu le décris. En revanche, après avoir gratté à propos des appels en VoIP, je suis tombé sur https://www.powervoip.com/dashboard qui propose (je pense), les prix les plus bas du marché.
Derrière, c'est une société luxembourgeoise, Dellmont, à la réputation plus que mauvaise, mais pour mon expérience, tout fonctionne parfaitement, avec un léger délai de latence (variable selon ma connexion Wifi pour l'appel).
Le cout de connexion est de 4 centimes (de dollars) puis la minute est à 0,1 centime. Cela donne l'heure d'appel à 10 centimes de dollars… Difficile de faire mieux je pense.
Alors bien sûr on ne peut pas appeler depuis la rue, mais pour appeler posé sur le wifi, c'est bien moins cher que skype (la partie VoIP). Pas d'image bien sûr mais ça je m'en fous.
Niveau client de VoIP, j'utilise Linphone sous Linux et CsipSimple sous Android. J'utilise ILBC à 8Khz en codec, qui consomme peu (20ko d'après mes tests) et offre une qualité acceptable.
# Les prémisses de cette faille
Posté par Pierrick Bouvier . En réponse au journal Ça sent pas bon chez Intel ?. Évalué à 10.
En cherchant un peu plus sur cette faille, je suis tombé sur l'article suivant datant du mois de juillet dernier.
https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/
L'auteur est la personne qui a reviewé le patch du kernel Linux mergé par torvalds.
La faille semble en effet liée à l'exécution spéculative de certaines instructions. En juillet, celui-ci a réalisé que les données de l'espace noyau pouvaient se retrouver en cache en éxecution non privilégiée, alors que l'accès devrait lever une faute de protection. Il ne peut en revanche pas lire le contenu de la mémoire. Entre ce moment et aujourd'hui, je pense que ce qui a été trouvé est une façon de lire cette mémoire (les détails viendront sûrement dans les jours à venir).
Visiblement, seuls les processeurs Intel sont concernés, les AMD implémentant correctement cette vérification dans le cadre de l'exécution spéculative.
Le fix implémenté par les OS, si j'ai bien compris, est ainsi de complètement séparer les espaces kernel et user (alors que jusqu'à présent, pour des raisons de perf (éviter un flush de TLB lors du passage en noyau), l'espace kernel était mappé en haut de l'espace user (d'où les 3GB de mémoire utilisable seulement sur un processeur 32 bits). Évidemment, l'accès aux pages du kernel est protégé via un bit d'accès User/Supervisor (http://wiki.osdev.org/Paging, section Page Directory). C'est visiblement ce bit qui n'est pas respecté dans le cadre de l'exécution spéculative.
J'imagine que le plus gros bazar dans cela, en plus de forcer un flush de la TLB (ce qui explique la chute des perfs dans les benchmarks), est de pouvoir toujours lire la mémoire user depuis le kernel, ce qui demande de jongler entre les 2 espaces. Je pense que c'est ce qui fait le plus gros du patch intégré au noyau. Et si torvalds l'a mergé sans broncher en insistant, c'est car c'est grave, et qu'il est encore impossible de divulguer cette faille.
Ce bug est donc assez exceptionnel dans le sens où aucune mise à jour côté microcode du cpu ne peut venir corriger ce problème (sur certains CPU avec des bugs hardware, c'est aux compilos de s'adapter). Il reste donc aux OS à corriger ce souci (Linux, Windows, FreeBSD, MacOS, et tous les autres). La question du parano en suspens est: cette faille était-elle connue avant par certains gouvernements et l'ont ils utilisé?
# Une avancée
Posté par Pierrick Bouvier . En réponse au journal Google chiffrement de mail end to end . Évalué à 0. Dernière modification le 21 janvier 2017 à 10:09.
Ce projet, pour ce que j'en ai compris, vise à répondre à la problématique "Comment obtenir la clé publique de mon correspondant?", ce qui, à mes yeux, est le plus gros frein à l'adoption massive du chiffrement pour le grand public. Et avec une volonté de faire collaborer les services de mails existants.
C'est donc un annuaire de clés, comme il peut déjà en exister (http://pgp.mit.edu/) mais à plus grande échelle, et avec plusieurs acteurs.
L'initiative est louable, cependant, je ne connais pas les détails techniques, notamment la grande question: Comment garantir que la clé de X que le service m'a donné est bien la bonne? À l'heure actuelle, on répond à cela en la transmettant via un canal secondaire (une page web le plus souvent).
Les applications sont multiples, et pas que pour les webmails. Il faut le voir comme un DNS pour le chiffrement, à la différence qu'on associe une clé à une adresse mail plutôt qu'une IP à un nom de domaine.
Que ce soit ce projet ou un autre, je suis convaincu que c'est cette avancée qui démocratisera le chiffrement des mails à grande échelle.
[^] # Re: À quand POSIX sous windows?
Posté par Pierrick Bouvier . En réponse au journal Bash dans Windows. Évalué à 1. Dernière modification le 31 mars 2016 à 12:57.
Intéressant…
En effet, SFU le fourni(ssai)t.
À coup de ZwCreateProcess (API NT non documenté), la chose semble possible. Cygwin ne l'a pas exploré pour des raisons de rétro compatibilité avec Windows 9x. C'est sûrement sur ça que se base ce nouveau projet. On peut le voir comme un successeur de SFU en quelque sorte, du côté programmeur en tout cas.
http://stackoverflow.com/questions/985281/what-is-the-closest-thing-windows-has-to-fork
[^] # Re: À quand POSIX sous windows?
Posté par Pierrick Bouvier . En réponse au journal Bash dans Windows. Évalué à 1.
Je ne connaissais pas ce projet (qui a l'air tout neuf).
En gros, ils ne se basent pas sur la WinAPI mais directement sur l'API NT (accès au noyau). En théorie ça a l'air beau et génial, en pratique, même s'ils feront mieux que cygwin dans leur design/perf, ils ne pourront pas ajouter une feature au noyau NT qui n'existe purement et simplement pas. À surveiller…
# À quand POSIX sous windows?
Posté par Pierrick Bouvier . En réponse au journal Bash dans Windows. Évalué à 3.
La grosse avancée sera le jour où Windows fournira une couche POSIX complète sous windows.
Cygwin émule celle-ci, en l'implémentant complètement. Le gros hic vient du support de certaines fonctionnalités telles que le changement d'id user ou encore fork. Ces deux points ne sont absolument pas fournis par la WinAPI et les devs de Cygwin ont trouvé des moyens très astucieux de les émuler. C'est ainsi qu'on peut avoir le serveur openssh sous windows ou encore forker à souhait (avec une sacré pénalité, vu que la librairie cygwin recopie tout l'espace d'adressage du processus parent à la mano!). Le pire reste qu'implémenter ces deux syscalls dans NT ne doit vraiment pas être compliqué, c'est vraiment une question de politique…
J'ose croire que ça avance dans le bon sens vu les dernières annonces faites par Crosoft. Après, restera plus que le support de X11 ou Wayland, la possibilité d'ajouter un shell graphique custom, et on pourra ptet enfin faire quelque chose de supportable sous cet OS. Après, ok, c'est pas libre, et ça ne justifie en rien la politique scandaleuse de cette boîte, mais ça me permettrait au moins de rebosser sans avoir peur de refoutre les pieds sous explorer.exe.
# /etc/hosts
Posté par Pierrick Bouvier . En réponse au journal Un outil pour gérer une blacklist DNS. Évalué à 3.
Je comprends tout à fait la problématique de bloquer un domaine au delà du navigateur. Pour cette question, l'application Adaway (sous Android - dispo sur F-droid) et https://github.com/sedrubal/adaway-linux répondent au besoin en patchant le fichier /etc/hosts.
Ça a le bon goût d'être léger et efficace, multiplateforme (même Windows le respecte!). Cependant, ça demande un accès root (ce que demandera aussi ton serveur de toute façon pour binder le port 53).
Du coup, je me demande les avantages d'un DNS custom (en dehors de l'intérêt technique de le faire bien sûr) par rapport à cela.
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par Pierrick Bouvier . En réponse au journal Adieu Biicode, bonjour Conan. Évalué à 1. Dernière modification le 07 janvier 2016 à 15:15.
Je suis ce développement de très près qui permettrait enfin de s'affranchir de visual pour compiler sérieusement des projets sous windows. Reste à voir si les perfs suivront (comme souvent avec clang). De ce côté, le compilateur de Microsoft se débrouille plutôt très bien, malgré de nombreux autres défauts.
[^] # Re: Sa conclusion : on a besoin d'un gestionnaire de dépendance pour C/C++
Posté par Pierrick Bouvier . En réponse au journal Adieu Biicode, bonjour Conan. Évalué à 3.
C'est une problématique très intéressante que tu soulèves ici.
Malheureusement, les gens soucieux de ces problèmes se soucient en général simplement des versions de librairies utilisées (que ce soit en C/C++ ou même d'autres langages). Alors qu'en pratique, ton compilateur et tous les outils de ta toolchain sont aussi importants. Pour moi la reproductibilité implique de recréer le même binaire au bit près, pas de s'assurer des dépendances sur des librairies.
Dans ma dernière expérience professionnelle sur le sujet, j'avais mis en place une forme de conteneur léger (à coup de chroot) basée sur debian testing, avec génération automatique chaque semaine ou quand besoin d'une nouvelle lib/version de compilo. Le tout rapatrié avec rsync via ssh. Sinon possib de monter tout le bouzin via NFS mais c'était trop chiant en infra pour nous. Ça offrait une belle portabilité peu importe la distribution linux utilisée par les collègues (et simplifie l'intégration continue accessoirement). Quant à l'arrivée d'un nouveau, il suffit de faire: git clone && get_env.sh && make. Simple et efficace au possible. Il me restait, mais je ne l'ai pas fait, à "versionner" cet environnement de build (qui est une chose très importante aussi). Pour cela, un montage BtrFS avec snapshots permet de faire un stockage incrémental (on ne stocke que les diffs) et adapté. Reste à ajouter un hash quelque part et pointer sur le bon dans ton code, et tu as un environnement de build complètement déterministe, mais pour Linux uniquement. Un jour si je me motive, faudrait que je package et publie le tout, je suis sûr que ça pourrait attirer du monde. Bien plus qu'une solution bricolage comme Biicode (c'est mon humble avis).
Il reste le problème de la cross compilation. MacOS ne m'intéresse pas d'un iota. Pour les BSDs un cross compilo fait le taff. Quant à Windows, soit tu peux cross compiler un gcc, soit, une autre approche que j'avais tenté sur mon temps libre, c'est d'utiliser le compilo de visual (cl.exe) via wine (et pas visual lui même). Ça fonctionne rudement bien (modulo des variables d'env à setter) et si je devais m'occuper de ça un jour, ce serait ma voie d'approche. Avec le wine dans l'env de build décrit au-dessus, tu obtiens une solution déterministe pour le build Linux/Windows depuis toute version/distrib de Linux.
Une fois cela fait, un travail important reste de packager toi-même toutes les librairies dont tu dépends. Chez nous, on s'en était assez facilement sorti avec un peu de script.
Cette façon d'approcher, reste, je pense, la plus simple et efficace. Des collègues plutôt orientés Java m'ont montré Nexus et le concept d'artifact repository. Pour moi, ça revient à de la gestion de libs, le tout dans une belle usine à gaz webistique. J'imagine que ça dépend des goûts de chacun, moi je n'ai pas accroché en tout cas…
# La nouveauté ce n'est pas toujours mieux?
Posté par Pierrick Bouvier . En réponse au journal Comment mon expérience Linux est en train de tourner au fiasco. Évalué à 0.
Je passerai sur le ton plainte associé à la forme de ton journal (si tu veux un beau bureau qui marche tout seul, t'as qu'à aller chez la pomme… ou au moins sous Debian stable), pour me concentrer sur certains éléments de fond.
Ce que tu décris, à savoir refaire du neuf moins bien que le vieux, n'est, à mes yeux pas l'apanage de l'écosystème Linux. On peut le voir sur les nouvelles versions d'Android (Lollipop, je trouve l'ergonomie moins pratique que kitkat, sans parler du style et des couleurs), de Windows (le 7 était franchement bien, mais depuis…) et ptet même chez Apple (je connais pas).
Le truc bien sous Linux, c'est que tu as le choix. C'est cela qui fait que je ne pourrai plus retourner sous un autre OS (en dehors des BSD). Il existe encore XFCE (si tu veux un vrai environnement) ou bien les tiling window manager (Awesome pour ma part) qui répondent complètement à mes besoins de barbu, ce que Madame Michu n'appréciera pas, j'en ai conscience. Quant à systemd, il y a eu pire, et malgré tout le mal que j'en pense, aujourd'hui sur ma Jessie ça marche et j'ai appris les 3 commandes qu'il fallait pour l'administrer.
Mais le grand public ne cherche pas ça, et c'est bien là l'origine du problème. J'ai montré Linux à un ami qui voulait s'y mettre, et il a rêvé devant KDE et ses effets kikoolol, là où la légèreté de XFCE ne l'a pas fait bronché. C'est assez caractéristique de ce qui se passe dans l'informatique aujourd'hui. Autant à une époque cela me gênait, autant aujourd'hui je m'en fous. Que ceux qui aiment les usines à gaz développent/utilisent Gnome/KDE et se touchent la nouille, et pour les autres, restons libres en choississant nos programmes individuellement plutôt que faisant partie d'un environnement de bureau (en vrac: awesome, cmus, thunderbird, firefox, mplayer, …).
Et pour finir sur un troll, je me demande si c'est pas mieux que le desktop Linux n'ait jamais percé au grand public. Quant on voit le scandale systemd, ça aurait sûrement fini avec une migration des projets intéressants pour bosser sous BSD.
# This is a matter of life and death
Posté par Pierrick Bouvier . En réponse au journal Un nouveau CMS avec Raptor Editor. Évalué à 7.
Strictement sans aucun rapport, mais ça me fait toujours penser à cette planche de Xkcd ces histoires de dinosaures…
# For the win
Posté par Pierrick Bouvier . En réponse au journal L'équipe Magic Lantern embarque Linux sur les boitier Canon EOS. Évalué à 2.
J'ai pas mal utilisé Magic Lantern sur mon 650D et ils ont vraiment fait un travail admirable.
En revanche, je suis un peu plus sceptique sur le fait de faire tourner un autre OS complet sur un reflex. En dehors de la réutilisation de code existant (et encore… on ne fera pas tourner gimp sur l'écran), la plupart des fonctionnalités d'un reflex restent limitées. Et le scripting Lua ajouté par ces braves gens de chez ML permet déjà de faire un peu ce qu'on veut. Sans compter que la plupart des limites dans lesquelles les devs butent aujourd'hui sont plutôt d'ordre matériel (comme comment utiliser le DMA pour balancer de la vidéo en RAW sur la carte SD) que logiciel.
Mais joli exploit tout de même :).
# C'est le jeu ma pauvre lucette!
Posté par Pierrick Bouvier . En réponse au journal Google: je sais, je sais... mais tout de même, j'ai les boules !. Évalué à 4.
Sincèrement, il n'existe pas de secret. On n'entre pas dans le top 3 mondial des entreprises en aidant l'humanité ou en faisant simplement des produits cools avec des bords arrondis.
Et encore, simplement chouiner sur une différence de comportement entre navigateur me semble le dernier cadet des soucis avec la situation actuelle.
Naivement, j'avais pensé que Google proposait Android pour simplement apporter la publicité sur le monde mobile. En réalité c'est bien pire, puisque l'écosystème se resserer doucement mais sûrement (voici un excellent article à ce sujet: http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/ ).
Et ne parlons même pas des problématiques de vie privée…
A propos de tout ça, je me demande ce qu'ils en pensent les employés "connus" de google ou bien s'ils s'en tapent étant donné qu'ils ont 2 jours de boulot payé pour hacker sur un truc cool en open source.
# Modifier readline via .bashrc
Posté par Pierrick Bouvier . En réponse au journal Faire de la magie avec son .inputrc. Évalué à 4.
On peut aussi tout faire dans le .bashrc, question d'éviter de s'emmerder avec encore un autre fichier en utilisant la command "bind"…
J'en profite pour poster ma partie, avec notamment des trucs sur l'autocompletion (pas de hidden files sans ., cacher le préfixe commun entre plusieurs fichiers, …)
[^] # Re: Annuaire clés publiques
Posté par Pierrick Bouvier . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 1.
Pour approfondir un peu: https://github.com/okTurtles/dnschain/blob/master/docs/Comparison.md
En gros, CT maintient le concept de CA mais leur demande de vérifier le contenu du log émis (pour voir qu'aucun nouveau certificat n'a été émis). Cela rejette donc la sécurité sur eux et permet une détection de problèmes seulement après une brèche. C'est donc moyen.
DNSChain offre de son côté de plus solides garanties. C'est le même algo que Bitcoin qui est utilisée, sauf que la monnaie a été modifiée pour attacher des données sur chaque noeud: Namecoin. On associe donc une monnaie virtuelle à un système de gestion de noms de domaines.
Tout comme Bitcoin, la sécurité est offerte par le fait qu'un attaquant doit disposer d'une puissance de calcul colossal pour dépasser celle de tous les autres noeuds du réseau. De plus, chacun peut créer gratuitement son identité, plus besoin d'avoir des CA ou un provider de mail qui fait ce boulot contre rémunération.
Et apparement, Namecoin gére déjà la gestion d'identité (et c'est même implémenté dans certains outils): https://wiki.namecoin.info/?title=Identity
[^] # Re: Annuaire clés publiques
Posté par Pierrick Bouvier . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 1.
Merci beaucoup pour ce lien. J'ai pris le temps de creuser un peu le sujet et voici un résumé de ce que j'ai compris. Si j'ai écrite une bêtise, merci de me corriger.
Le problème de la distribution de clés revient exactement au même problème des certificats pour l'accès sécurisé à certains sites/services (SSL). C'est très logique mais sincèrement je n'avais pas fait le rapprochement. De là, on peut regarder les solutions à ce souci.
Parmi celles-ci, on compte:
- Convergence
- Certificate Transparency (CT)
- DNSChain
Convergence, proposé par Moxie, l'auteur de TextSecure, propose en gros de remplacer les CA par un ensemble de pairs qui valident un certificat. En gros, plusieurs identités doivent répondre oui à la question "Mon certificat est-il le bon?".
Certificate Transparency, tout comme DNSChain, prone l'emploi d'hash tree, ou Merkle tree, utilisé entre autres dans Git ou encore Bitcoin. En gros, on crée une chaîne de blocs communes pour tout le monde, dont chaque noeud est un hash de ses fils. Cela résout le problème élégamment mais pose celui de la réconciliation, c'est à dire d'obtenir le même arbre pour plusieurs opérations se déroulant sur différentes machines. Et de ce côté là, les 2 diffèrent:
Vous l'aurez compris, la diff entre les 2 me semble encore un peu mystérieuse…
En tout cas, une personne de DNSChain a répondu à CT pour contredire certains points: http://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/
Moralité, tout n'est pas clair dans mon esprit mais une fois le problème sécurisé de l'accès à des sites résolus, on pourra utiliser cette solution pour la diffusion de clés publiques pour les adresses mails.
Quant aux clés privées, un simple stockage temporaire chiffré avec de l'AES-256 et une passphrase d'au moins 25 caractères devrait permettre la synchro facile entre devices. Bon ça c'est mon idée.
[^] # Re: Annuaire clés publiques
Posté par Pierrick Bouvier . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 1.
Je ne parlais pas de transmettre la clé pour chaque échange, j'ai du mal m'exprimer.
Je précisais l'échange initial de clés publiques, nécessaire avant le premier mail. Aujourd'hui tu récupères la clé à la mano de ton correspondant et tu la rentres dans ton mailer. Pour le grand public, c'est trop complexe. Si cela était automatisé (via ton navigateur par exemple), comme une requête DNS pour récupérer l'IP, ce serait bien plus simple et ce serait un premier vrai pas vers le chiffrement grand public.
Reste la possibilité de vérifier après coup le fingerprint, comme tu le dis, mais qui te dis que ton message ne sera pas modifié en cours (principe du MITM)? Quant au concept du "C'est trop lourd pour le faire à grande échelle", j'ai ravalé cela il y a un petit moment déjà…
# Annuaire clés publiques
Posté par Pierrick Bouvier . En réponse au journal Try To Listen Me, nouveau site Open Source de communication chiffrée. Évalué à 3.
Bonjour,
ton projet est une bonne initiative même si je pense que la création d'un nouveau canal de discussion (il y en a tellement) pose problème. À l'heure actuelle et à ma connaissance, seul TextSecure (https://whispersystems.org/) permet une discussion asynchrone, chffrée, avec garantie de PFS. WhatsApp a déclaré qu'ils s'en étaient inspirés, mais sérieusement, quel utilisateur de WhatsApp croit au respect de sa vie privée?
Je ne suis pas utilisateur de messagerie instantanée, car soit les garanties en termes de sécurité sont absentes, soit (comme pour XMPP), cela demande aux deux parties d'être connectées. Et cela est un souci. Je n'utilise pas non plus TextSecure car, pour l'instant, il repose encore sur le framework GCM de Google pour le Push de messages. En attendant l'implem à base de Websockets, je n'utilise rien d'autre.
Reste donc les bons vieux mails, que j'utilise de façon non chiffrée car de toute façon, presque aucun de mes contacts ne connait tout cela. Mais je pense qu'à terme, un chiffrement massif des mails (il faudrait convaincre les gros providers de s'y mettre, et là c'est dur) serait une bonne chose. Reste le souci de gestion des clés. Autant pour la privée, je pense qu'il est possible de faire un truc bien, facilement déployable sur plusieurs devices, autant vérifier sa clé publique avec un autre canal de communication que celui qu'on utilise me semble lourd. Trop de gens accepteront la clé qu'ils voient sans réfléchir, ouvrant la porte à un MITM massif sur ces échanges.
D'où ma question, connaissez vous des recherches ou des papiers parlant du problème de la distribution des clés publiques via un annuaire (comme une sorte de DNS de la crypto), de façon sécurisée? De sorte que si l'annuaire tombe entre les mains du vilain, les utilisateurs le voit. Et le tout, sans contrainte de connexion des deux parties simultanément (Diffie-Hellman).
# VoIP à pas cher
Posté par Pierrick Bouvier . En réponse au journal Pour les expats. Évalué à 1.
Je ne suis pas expat, mais voyageant depuis quelques mois dans divers pays dont l'accès à Internet reste variable, j'ai eu ce souci de communication.
Je n'utilise plus skype car je trouve leur version Linux à chier, sans compter les problèmes de vie privée associés (mais bon, le réseau téléphonique est probablement surveillé de la même façon). Et enfin, la plupart des gens de ma famille ne sont pas très branchés informatique.
N'utilisant pas de sim locale, impossible pour moi de faire du callback comme tu le décris. En revanche, après avoir gratté à propos des appels en VoIP, je suis tombé sur https://www.powervoip.com/dashboard qui propose (je pense), les prix les plus bas du marché.
Derrière, c'est une société luxembourgeoise, Dellmont, à la réputation plus que mauvaise, mais pour mon expérience, tout fonctionne parfaitement, avec un léger délai de latence (variable selon ma connexion Wifi pour l'appel).
Le cout de connexion est de 4 centimes (de dollars) puis la minute est à 0,1 centime. Cela donne l'heure d'appel à 10 centimes de dollars… Difficile de faire mieux je pense.
Alors bien sûr on ne peut pas appeler depuis la rue, mais pour appeler posé sur le wifi, c'est bien moins cher que skype (la partie VoIP). Pas d'image bien sûr mais ça je m'en fous.
Niveau client de VoIP, j'utilise Linphone sous Linux et CsipSimple sous Android. J'utilise ILBC à 8Khz en codec, qui consomme peu (20ko d'après mes tests) et offre une qualité acceptable.