Faut s’démener au FOSDEM !

GNU/Linux Magazine n° 213 | mars 2018 | François Revol - Romain Pelisse - Damien Plard - Jean-Michel Friedt - Cyril Roelandt - Thomas Monjalon - Stéphane Bortzmeyer - Pierre Ficheux
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
Le FOSDEM (Free and OpenSource Developers European Meeting) est tellement incontournable qu’une part non négligeable des auteurs de GLMF s’y rend chaque année. De nombreuses mains et points de vue ont donc participé à ce compte-rendu, pour vous faire part du foisonnement de ce week-end intense.

Comme chaque année, toutes les conférences ont été filmées et sont déjà disponibles en ligne [1]. Heureusement d’ailleurs, car même après avoir fait une première sélection sur le programme en ligne ou dans l’une des nombreuses applis mobiles, aux collisions d’agenda s’ajoutent les discussions sur les stands et les files d’attente à l’entrée des salles… « Sorry we are FULL! ».

1. Les stands

Les stands, lieux de rencontre, de discussion, de collecte de stickers et autres goodies exotiques tels les hand-spinners Kubernetes ou les briques Lego® estampillées bazel.build, se partageaient sur plusieurs bâtiments comme à l’habitude.

Le bâtiment K, le plus récent, regroupait la plus grande partie d’entre eux. Au rez-de-chaussée les tables des « gros » projets comme KDE et GNOME, LibreOffice, Nextcloud (et ownCloud à une distance de sécurité), ainsi que les distributions (CentOS, Debian, Fedora, Gentoo, OpenSUSEUbuntu étant encore absent), mais aussi d’autres OS comme FreeBSD, illumos (fork d’OpenSolaris), ainsi que ReactOS (le clone libre de Windows) et Haiku, qui cette année eurent chacun droit à une table entière. La FSFE occupait plusieurs tables avec leur boutique [2] toujours éclectique (après la layette, la tendance est cette année au bavoir « I am a fork() »). Les projets orientés infrastructure n’étaient pas en reste, avec les stands oVirt, OpenStack, XEN, Gluster et LizardFS, Tor et Nos oignons

À l’étage une vingtaine de tables encore, avec Mozilla, les fondations Apache et Eclipse, une boutique Perl très fournie, MuseScore… et Google pour la promotion du Summer of Code et Code-In. Mais le stand le plus funky était sans conteste celui de VideoLAN, avec une roue à tourner pour gagner un selfie avec ConeMan, un autocollant, poster, t-shirt, ou une « licence physique officielle » numérotée !

Au bâtiment H quelques stands moins connus, dont celui du Software Freedom Conservancy, mais aussi les tables bien pleines du stand O’Reilly, que personne n’a semble-t-il osé troller au sujet de l’ajout de DRM dans leurs prochains ebooks.

Le bâtiment AW regroupait les stands orientés hardware, tels MicroPython, l’OS pour objets connectés RIOT, OpenEmbedded, le routeur tchèque Turris Omnia ou les cartes embarquées PINE64 à base d’ARM, ou les cartes compatibles EOAM68 reprenant le format PCMCIA. Et même des radio-amateurs et un micro-satellite de la Libre Space Foundation !

2. Vie privée & décentralisation

L’une des révélations de l’édition précédente était la devroom « Decentralized Internet », qui pour sa première version avait fait salle comble. Pour cette seconde itération, elle aborde également la vie privée, et déménage pour accueillir 190 personnes. Spoiler : la salle fut pleine toute la journée.

Tristan Nitot ouvrit donc la session par quelques citations, de Lessig à Spiderman, de Snowden à Mitch Kapor.

Le premier sujet abordé fut la mesure du degré de décentralisation du Net à l’aide de sondes RIPE Atlas. L’outil proposé, ixp-country-jedi, permet par exemple de se rendre compte du nombre très faible d’acteurs en France [3]. Suivit un appel à se regrouper pour tenter de récupérer des fonds européens dans le cadre du programme H2020/ICT-28 « Future Hyper-connected Sociality ». Les financements européens sont complexes à décrocher, mais il ne serait que justice qu’ils soutiennent du logiciel libre.

Ensuite, les expériences menées avec MAZI et Openki.net autour de serveurs accessibles uniquement localement par le Wifi dans une résidence ont montré une autre façon de décentraliser l’information. D’autres projets furent également représentés, comme Retroshare, Ring ou Matrix.

Pas de pause à midi, mais du framapain sur la planche. En effet, la présentation de Peertube était très attendue. Cette prometteuse alternative à YouTube basée sur le même principe de fédération que Mastodon et interagissant avec lui grâce à ActivityPub [4] utilise également le P2P pour la distribution des vidéos, ce qui réduit la charge des serveurs, les plus demandées étant aussi les plus seedées. Et bien sûr, Framasoft se devait de présenter sa campagne Contributopia, mais vous la connaissez déjà !

L’après-midi fut consacrée à la vie privée avec une explication du fonctionnement de Tor, SecureDrop ou encore CryptPad, une sorte d’etherpad chiffré empêchant le serveur de connaître son contenu.

L’organisation d’une telle devroom est un gros travail, en témoigne par exemple Loic Dachary [5], partagé heureusement par une dizaine de personnes. Un grand merci et datalove à eux !

3. Retro-computing ?

Une nouvelle devroom cette année était consacrée aux antiquités, une conférence « Retro desktops for retro computers » l’an dernier ayant motivé l’organisateur à franchir le pas. Si vous avez apprécié le hors-série Linux Pratique n°41 sur le rétrogaming, c’est l’occasion d’aller plus loin, dépoussiérer vos ordinosaures, et cross-compiler ! … et pourquoi pas demander un HS rétro-coding ;-)

La première conférence abordait l’histoire de DOSEMU et FreeDOS, le premier étant intimement lié à l’histoire de Linux, avec l’introduction très tôt de l’appel système vm86() remplacé depuis par d’autres solutions telles KVM, de même que les raccourcis alors nécessaires à l’accès au matériel. DOSEMU est toujours utilisé, par exemple avec un logiciel de contrôle d’antenne de réception d’images satellite utilisant un matériel ancien sur bus ISA. Un dos-extender (HX extender) lui permet même de lancer des binaires console win32. FreeDOS quant à lui a connu plusieurs compilateurs plus ou moins libres (de Borland C à Open Watcom) avant de pouvoir être enfin compilé avec GCC grâce à plusieurs patches supportant une architecture IA16.

Suivirent des présentations d’un SDK pour micro-ordinateurs ORIC créé par un démomaker ; de Retro-uC, un projet combinant des cœurs open source de 6502, Z80 et 68000 dans FPGA, et peut-être un jour un ASIC ; de NetBSD sur des machines d’au moins 10 ans d’âge, du VAX connecté en Wifi par USB aux consoles Sega Dreamcast boostées aux cartes Compact-Flash, en passant par le compatible Atari Milan… (« of course, it runs NetBSD! ») ; d’un SDK pour Z80 permettant un certain niveau de portabilité entre ColecoVision et Sega, utilisant SDCC ; et enfin une cartouche d’extension flash de 512Kio pour ZX-Spectrum et les explications sur la bidouille permettant d’en paginer l’accès et d’y écrire depuis un port sans les signaux nécessaires.

À côté de la session retro-computing, l’introduction plénière en amphi (Keynote) s’est conclue par 4 présentations historiques. La première a proposé de rappeler les évolutions d’Unix, de sa genèse dans les Bell Labs avant de migrer vers Berkeley et de devenir les *BSD actuels, et toutes les innovations qu’on lui doit, du shell comme processus régulier aux pages de manuel bien rédigées. Autant l’absence de mention de Linux comme nouvel arrivant sur la scène des Unix est compréhensible, car il ne descend pas du code original, autant les faits marquants attribués à chaque mise à jour était quelque peu biaisés, avec par exemple l’absence de mention de l’introduction de l’appel système ioctl() passé sous silence. Ce point de rupture avec la philosophie de « tout est fichier » a pourtant marqué la scission des auteurs d’Unix avec leur œuvre pour se tourner vers Plan9 et Inferno, qui auront été cités lors de la présentation suivante, qui rappelait que seuls les vainqueurs avaient le droit d’écrire l’Histoire. Ainsi, les défenseurs des alternatives à Unix – AmigaOS, BeOS, Plan9 déjà cité ou TOS, voire même les programmeurs sous LISP – ont eu droit à une séance de nostalgie de toutes les opportunités ratées par des environnements de travail prometteurs, mais qui n’ont su s’imposer face à la flexibilité, la portabilité et la légèreté d’Unix qui en font encore ses attraits à l’heure actuelle. Et pourtant le concept même de fichier a émergé de la nécessité d’une abstraction pour différents types de mémoires plus ou moins permanentes, et d’autres systèmes comme SmallTalk travaillant uniquement sur des mémoires non-volatiles pourraient revenir au goût du jour si l’on en croit l’article sur le sujet dans GLMF N°212

Plus consensuelle, la troisième conférence abordait l’archéologie numérique et la préservation du patrimoine matériel et logiciel. La dernière détaillait la réimplémentation d’un ordinateur à tubes de 1948 à l’aide de FPGA, d’Arduinos et d’impression 3D.

4. Free Java

Sans surprise, le projet OpenJDK [6] et ses projets annexes étaient au centre des discussions de la salle. La première présentation, et probablement la plus intéressante de la journée était justement celle de Mark Rheinhold, sur l’état du projet et les travaux en cours. Il était certainement agréable pour lui, mais aussi pour son audience, que la modularisation de la JVM, qui était le point central de ses présentations depuis plusieurs années, ait enfin été adressée par la publication de Jigsaw avec la JDK 9. Mark a donc enfin pu aborder d’autres aspects du projet et surtout évoquer quelle vision, pour la JVM, est envisagée sur le long terme. 

Un point important sur ce sujet a été l’engagement d’Oracle. En effet, depuis que le géant américain a racheté Sun (et donc « Java » en quelque sorte), son manque d’engagement sur de nombreux projets a été problématique, pour dire le moins, pour le monde « Java ». Néanmoins, Oracle a clairement défini son engagement sur le projet, tant en fréquence de publication que de durée de support. Un autre aspect de cet engagement avec la communauté est l’annonce de la mise en open source de nombreux outils, encore propriétaires, tel que le fameux Mission Control [7].

Les autres présentations qui suivirent évoquèrent également, pour la plupart, les différents aspects évoqués par Mark Rheinhold. On ne reprendra ici que deux points susceptibles de séduire le lecteur de GNU/Linux Magazine : l’évolution de la syntaxe Java avec l’introduction du mot-clé var et les travaux pour intégrer la JVM à Alpine

L’un des projets associés à OpenJDK, Amber, se concentre sur les améliorations à apporter au langage en tant que tel. Dans le cadre de la prochaine publication de la machine virtuelle, c’est la JEP-286 [8] qui apportera les premiers fruits de ce labeur en introduisant le mot-clé var au langage ! Celui-ci devrait agréablement alléger la syntaxe Java, spécialement dans les déclarations de variables :

var stream = list.stream();          // déduit le typage (Stream<String>)

List<String> list = new ArrayList<>(); // plus besoin d’indiquer le type associé ArrayList!

var reader = new BufferedReader( new InputStreamReader(connection.getInputStream())); 

En offrant aussi une intégration avec le projet Alpine [9], Java tente de suivre les bonnes pratiques de Docker, en minimisant autant que possible la taille des images. Il sera donc prochainement possible d’utiliser Alpine comme distribution de base d’une image « Java ». D’après la présentation, nous pourrions donc avoir une taille minimale de 50Mio (5Mio d’alpine, 45Mio pour une JRE réduite au strict nécessaire). À titre de comparaison, une simple image CentOS seule demande 200Mio et autant pour y ajouter une JRE standard. Néanmoins, la principale difficulté d’utilisation d’Alpine est liée à l’absence de glibc, présente dans la plupart des distributions Linux et remplacée ici par musl libc [10] (comme sur Buzybox).

Pour conclure la journée, Romain Pelisse et Damien Plard ont détaillé, sur un ton décalé, les nombreuses menaces auxquelles une appli web Java doit faire face dans leur conférence intitulée « Hairy Security ».

Note

Coup de cœur : Morbig et l’analyse de script Shell

Une autre conférence hors Java dont le sujet m’a [RP] beaucoup séduit portait sur le projet Morbig [11]. Ce dernier vise à réaliser un analyseur syntaxique pour les [S]hells de type Posix. La conférence en tant que telle évoquait la complexité de la tâche, le langage du Shell ne respectant pas la plupart des contraintes usuelles des langages de programmation, mais c’est surtout le potentiel de l’outil qui m’a séduit. 

En effet, à l’issue de l’analyse, Morbig produit une sorte d’arbre syntaxique (ou assez proche du concept en tout cas) au format JSON. Il est donc très facile d’envisager d’intégrer, par le biais de ce format « pivot », les données dans la plupart des outils d’analyse de code tels que Checkstyle, PMD et autres lint [12]. Ceci permet (enfin) de disposer d’outils pour vérifier la qualité et le respect des bonnes pratiques des scripts Shell (et dérivés).

5. Package Management

Andrew Lee a présenté Open Build Service, un système de gestion de paquets permettant aux empaqueteurs de construire facilement des paquets pour plusieurs distributions GNU/Linux. Il est utilisable via une interface web développée en Ruby on Rails et également au travers de la ligne de commandes. Il peut également publier les paquets créés automatiquement.

Son collègue de Collabora, Simon McVittie, a quant à lui préféré expliquer en quoi Flatpak pouvait être une solution intéressante pour distribuer une application. Il a commencé par rappeler que Flatpak ne convenait pas à tous les programmes : les outils de développement, les services système ou encore les logiciels de bas niveau ne sont pas la cible. Flatpak vise plutôt les applications « de bureau », avec une interface graphique, qui ont besoin d’utiliser X11 ou encore PulseAudio, ce qui est généralement un peu difficile avec des solutions de conteneurisation telles que Docker.

Il a ensuite rappelé la difficulté qu’ont les vendeurs de logiciels non libres à distribuer leurs applications sur « le bureau Linux » : les distributions ne proposent pas toutes le même environnement (version des bibliothèques, environnements de bureau…) et la LSB (Linux Standard Base) n’est, selon lui, pas très utile. Les vendeurs ont donc tendance à voir Red Hat ou Ubuntu comme un standard de fait : ainsi, Steam se base sur Ubuntu 12.04.

La fin de la présentation a été consacrée à des aspects plus techniques : les fichiers peuvent être « partagés » par plusieurs supports d’exécution, des permissions comparables à celles utilisées sur Android permettent d’exposer des sockets (pour D-Bus ou PulseAudio, par exemple) et les données des utilisateurs peuvent être invisibles pour l’application lancée dans un Flatpak.

Todd Gamblin, du Lawrence Livermore National Laboratory, a ensuite présenté Spack, un gestionnaire de paquets utilisé principalement sur des super-calculateurs destinés au calcul scientifique et haute performance (HPC), mais qui convient également aux machines plus traditionnelles. Le projet fournit un langage dédié (basé sur Python) permettant aux utilisateurs de définir facilement leurs paquets. Ils peuvent également indiquer une dépendance spécifique (une implémentation particulière du standard MPI, très utilisé en HPC), une option de compilation, etc.

Spack veut laisser les utilisateurs choisir leur compilateur : il n’est pas rare que le compilateur C d’Intel soit préféré à GCC dans le monde du HPC. Ce n’est toutefois pas chose facile, car les projets libres sont en général testés principalement avec des compilateurs courants, tels que GCC et Clang, et peuvent ne pas fonctionner avec d’autres. Autre difficulté : on ne peut pas toujours compiler directement sur les machines de calcul (elles n’ont pas toujours de disque dur, leurs cœurs sont nombreux, mais peu puissants, le compilateur n’est pas toujours disponible sur l’architecture qu’elles utilisent). La compilation croisée est donc bien souvent nécessaire.

Alexander Nasonov nous a ensuite fait prendre conscience de certains enjeux de sécurité liés à l’installation de paquets. Plus précisément, selon lui, les paquets que nous installons sur nos distributions peuvent être observés par des attaquants potentiels, qui peuvent ainsi recueillir des informations utiles pour une attaque (une machine donnée a installé un paquet contenant une faille de sécurité, par exemple). L’utilisation de https ne suffit pas à se protéger complètement d’une attaque man in the middle, c’est pourquoi il recommande d’utiliser Tor. La fin de la présentation était constituée d’informations techniques permettant d’utiliser apt et pkgsrc avec Tor.

GNU/Linux Magazine a déjà parlé de GNU Guix (voir les numéros 194 et 195), un gestionnaire de paquets fonctionnel. Christopher Baines a rappelé que GNU Guix était très fiable, tout comme GuixSD, la distribution GNU/Linux basée sur GNU Guix. Il a ensuite fait un rappel concernant les concepts empruntés à Nix (le système de liens symboliques dans /gnu/store) et a fait une démonstration des commandes guix environment, qui permet de construire un « environnement de développement », et guix pack, qui crée un tarball ou un conteneur Docker empaquetant les paquets spécifiés par l’utilisateur.

Philippe Ombredanne nous a expliqué qu’il nous manquait une façon unifiée de parler d’un paquet : il a pris l’exemple du nom « file », qui renvoie à des logiciels différents dans des gestionnaires de paquets différents (Debian, PyPI, NPM). Il propose de résoudre ce problème grâce à « purl » (Package URL), une spécification pour une URL désignant un paquet.

Enfin, Kenneth Hoste a fait pleurer de rire l’assemblée dans une « anti-conférence » dont le but était de lister toutes les façons de rendre le travail des empaqueteurs plus difficile. Cette présentation était hilarante et doit impérativement être regardée par tous les développeurs impliqués dans la gestion des paquets d’une distribution !

6. EDA

La session de conception de circuits électroniques assistée par ordinateurs (EDA) est chaque année animée par Javier Serrano, chercheur au CERN et fondateur de la CERN Open Hardware License [13] bien connue dans la communauté du temps-fréquence pour son utilisation dans le système White Rabbit de transfert de temps. Cet institut de recherche a en particulier pris en main le développement de KiCAD, un outil de conception de circuits électroniques incluant un aspect simulation par l’intégration de ngspice dans son outil de tracé de schémas. La domination de cet outil libre se confirme, suite au changement de licence de Eagle après son rachat par Autodesk et le passage à une licence annuelle. Alors que Farnell avait fait le pari (malheureux ?) de fournir des empreintes de composants pour le logiciel propriétaire, DigiKey contre-attaque en supportant officiellement l’alternative libre.

Les études pour libérer les outils de configuration des matrices de portes logiques (FPGA), après le succès de l’ICE40, ont attiré une population démesurée face à l’espace disponible dans la salle de présentation laissant de nombreux déçus dans le couloir, lors de l’introduction au public d’une méthode de conception de son premier circuit sur ce type de composant. Hors de cette session, le premier processeur qualifié de libre, RISC V, malgré ses éléments encore propriétaires (contrôleurs de RAM DDR, PLL, composants à latences contraintes définies par la technologie du fondeur dont les bibliothèques restent propriétaires) a été montré pour la première fois, avec en plus d’une présentation d’une interface X et un afficheur PDF fonctionnels, une démonstration de Quake avec une accélération graphique externe tout à fait convaincante.

Fig. 1 : Javier Serrano introduit la présentation de KiCAD5, pendant laquelle le soutien formel de DigiKey est officialisé, aux côtés des nombreuses améliorations amenées au logiciel de conception de circuits électroniques, incluant l’importation des circuits conçus sous Eagle et la simulation par ngspice depuis le schéma.

7. Software Defined Radio

Chaque année la session SDR se tient en dépassement de capacité de la salle, et cette année n’a pas fait défaut à sa réputation. Quelques présentations ressortent du lot, avec en particulier l’introduction du PlutoSDR par Analog Devices, une radio logicielle à mois de 100 euros (en deçà du coût de production) couvrant la gamme 70-4000MHz et une bande passante de 10 MHz, avec schémas open-hardware, distribution Linux sur Zynq documentée dans un buildroot sur GitHub et un firmware du FPGA publié : Analog Devices a bien compris qu’en tant que fondeur de silicium, libérer le logiciel est à son avantage compétitif pour attirer les développeurs. La démonstration a été impressionnante (voir figure 2). Plus confidentiel, nous avons appris que gnuradio-companion serait bientôt capable de générer du code C++ en plus de Python, évitant l’interpréteur du second langage dans une application embarquée. Parmi les applications hallucinantes de l’implémentation logicielle de traitement de signaux radio-fréquences, la cartographie pour moins de 100 euros de la distribution de l’hydrogène neutre dans les bras des galaxies (1,4 GHz), dans le projet Open Source Radio Telescope utilisant un récepteur de télévision numérique terrestre pour recevoir des signaux radio-fréquences de l’espace : quelle consécration pour des composants initialement conçus pour lobotomiser la population avec les bêtises diffusées par les chaînes de télévision. Les attaques sur LoRa par les signaux diffusés par effet de bord (side channel attacks) ont rappelé que retirer la première couche de sécurité physique en replaçant le câble par l’onde radio ouvre le signal à toute étude de vulnérabilité, incluant la puissance émise en fonction du nombre de bits à 1 ou à 0, sans nécessairement nécessiter de cracker le code cryptographique.

Fig. 2 : Gauche : un ingénieur de Analog Devices présente la PlutoSDR, un processeur Zynq couplé à un transceiver de Analog Devices ADF4363, capables à eux deux de décoder tout signal occupant moins de 10 MHz de bande passante pour toute porteuse comprise dans la gamme 70-4000 MHz, pour un coût inférieur à 100 euros. Presque toute la bande FM est ainsi accessible par ce montage ! Droite : une modulation FSK encodant le logo de Analog Devices est observé lors de l’affichage en waterfall (affichage des composantes spectrales en fonction du temps) du message émis par la radio.

Un aspect fascinant de ces développements est que, tout comme le développement sur systèmes embarqués à base de microcontrôleurs, l’aspect financier devient négligeable, et tout l’investissement pour aborder le domaine du traitement logiciel de signaux radio-fréquences est presque exclusivement intellectuel. Les outils matériels (plateformes SDR) et logiciels (e.g. GNURadio) ne font que simplifier l’expérimentation, sans retirer les fondements physiques du traitement du signal qui doivent encore être maîtrisés pour aborder ces sujets. Cependant, d’un domaine aride et sans grand intérêt pratique pour le commun des mortels, le traitement du signal devient un domaine d’étude fascinant et pratique compte tenu de la multitude de signaux électromagnétiques qui nous entourent. Tel que l’a mentionné Tom Rondeau dans la seconde présentation, GNURadio n’est pas l’outil complet pour intégrer l’ensemble des couches OSI du traitement d’un signal, mais se contente d’appréhender uniquement les couches les plus basses, en fournissant les mécanismes de communication (e.g. ZeroMQ) vers des couches d’abstraction plus élevées (e.g. multimon-ng ou GNU/Octave) pour les étapes d’analyse de la couche applicative, une fois que GNURadio a fini de prendre en charge les couches de liaison de données et de réseau. Même un concept aussi abstrait que les couches OSI devient limpide à la lecture des documentations des normes RDS [14] (couche numérique annonçant les informations transmises dans la bande FM commerciale) ou LRPT [15] des satellites en orbite basse communiquant en mode numérique. 

8. Réseau

Depuis 3 ans, une session du nom barbare de SDN/NFV regroupe ceux qui veulent échanger au sujet des nouvelles techniques de gestion des gros réseaux. La particularité de ce domaine en effervescence se situe surtout dans ses acteurs qui sont en grande partie les principaux industriels des télécoms, hébergements et autres gros systèmes. Le public est donc très « professionnel ». On y retrouve notamment des contributeurs Cisco, Intel ou Red Hat.

Cette année, outre les habituelles présentations de contrôleurs réseau, micro-services et switches virtuels, il a également été question d’évolutions dans la conception des drivers.

Le fabricant de cartes Netronome utilise le nouveau langage BPF de Linux pour configurer les traitements spécifiques effectués sur la carte pour décharger la lourde tâche du noyau.

Intel surfe également sur la vague BPF et la couche driver XDP en proposant une nouvelle interface AF_XDP (différente de AF_PACKET) pour les applications voulant traiter les paquets bruts à vive allure. Il sera possible de sélectionner les flux sortant du kernel par cette interface bas niveau, et ceux continuant d’être traités par la pile TCP du noyau avant de sortir par AF_INET.

Linaro travaille sur net-mdev qui serait une nouvelle interface Linux pour écrire des drivers réseau en espace utilisateur, tout en étant protégé par IOMMU au travers de VFIO.

Red Hat continue de faire évoluer virtio en version 1.1 pour atteindre de meilleures performances. Le design interne change, et il est question de décharger une partie du traitement à la carte sans perdre en abstraction.

Nous avons également eu un appel aux fabricants pour libérer plus de documentations, plus claires et plus courtes afin d’aider les développeurs de drivers comme ceux en Lua de Snabb.

9. DNS

Une petite salle, un peu à l’écart, pour ce track, clairement un sujet moins populaire que les langages de programmation. On y retrouvait les suspects habituels (dont trois employés de PowerDNS, cette boîte grossit !). Mais plus tard, quand tous les autres tracks étaient pleins, nous avons accueilli pas mal de réfugiés et, à la fin, la salle était pleine et des dizaines de personnes attendaient dans l’escalier.

Sandoche Balakrichenan a fait un exposé sur Zonemaster. D’habitude, l’orateur fait la démo avec le domaine de la conférence, pour montrer les problèmes DNS, mais, ici, la zone FOSDEM était parfaite [16], donc il a fallu se rabattre sur une autre, rmll.info

Ondřej Surý (ISC) a présenté l’avenir de BIND. Depuis l’échec du projet BIND 10, c’est BIND 9 qui est la seule version maintenue. La dernière version est la 9.12 : NSEC aggressive use (RFC 8198) (mais toujours pas de NXDOMAIN cut (RFC 8020)). Il y a désormais EdDSA pour DNSSEC (RFC 8080), et la capacité à servir des données périmées (RFC pas encore publié). Par contre, toujours rien sur la protection de la vie privée : pas de DNS sur TLS (RFC 7858), pas de QNAME minimisation (RFC 7816[17]. Ça se voit quand un logiciel est développé aux USA et pas en Europe.

Traditionnellement, le développement de BIND était ultra-fermé. Mais l’ISC s’ouvre petit à petit. Il y a désormais un dépôt git public [18], avec un suivi des tâches et des bogues.

Petr Černohouz (CZ NIC, ceux qui programment, Knot, Bird, Turris Omnia, etc.) a parlé des vérifications techniques de zones DNS, pour lesquelles ils utilisent Zonemaster. Cela a entraîné une bonne discussion sur le thème « OK, on détecte les erreurs, mais comment faire pour que les gens les réparent ? ». 

Petr Špaček a fait un exposé niveau débutant (la plupart des talks étaient plus avancés) sur le déboguage de problèmes DNS. Très intéressant. Plein de punchlines « expect unexpected » « don’t panic » « use dnsviz, dig and common sense ». Ondřej Surý a rappelé l’existence du projet DNS violations [19].

Dans un autre exposé, le même Petr Špaček a parlé de sécurité et de robustesse, par exemple contre les attaques « random QNAMEs ». Elles sont triviales à faire : on met du JavaScript qui génère plein de noms et les résout dans une page web, on la fait charger par des complices innocents (par exemple via une pub). Solutions possibles : NXDOMAIN cut, NSEC aggressive use. Knot met en œuvre le second (mais seulement pour NSEC, alors que le RFC prévoit NSEC et NSEC3). 

Willem Toorop (NLnetLabs) a présenté getdns [20] (si vous programmez en C, c’est vraiment bien). Il a insisté sur l’importance de valider DNSSEC localement (sur la machine de l’utilisateur). TLS n’est pas suffisant (trop d’AC pour être fiable). Notez que cela laisse ouverte la question d’où le placer avec Linux : libc ? systemd-resolved ? stubby ? Il a aussi insisté sur le problème des middleboxes qui cassaient les requêtes DNSSEC. Un résolveur doit mettre en œuvre plein de solutions de repli. Peut-être que DNS-sur-HTTPS résoudra le problème (le port 443 passe presque partout), mais il n’est pas encore dans getdns (on y travaillera au hackathon IETF). 

Marcos Sanz (DENIC) a présenté son draft [21] sur la découverte du fournisseur OpenID (pour éviter le manuel « si vous êtes sur Facebook, cliquez ici »). 

Olivier van der Toorn a présenté un algorithme pour détecter si un nom de domaine est utilisé pour le spam. En gros, il mesure tout un tas de choses, de la longueur du nom au pourcentage de voyelles, passe ça au système d’apprentissage, qui peut ensuite dire si le domaine est spamophile ou pas. Je [SB] me suis dit que ce serait un ajout rigolo à Zonemaster : faire tourner un algorithme de ce genre et prévenir l’utilisateur « votre domaine sent le spam, votre e-réputation va en souffrir ». 

Stéphane Bortzmeyer a fait un exposé sur l’état du projet « DNS et vie privée ». Dans la séance de questions, Bert Hubert (PowerDNS) a fait une diatribe contre Google, rappelant que sécuriser le lien avec Google Public DNS était peu utile, et qu’il fallait qu’on déploie nos propres services. 

10. Embedded

Comme tous les ans le track « embedded, mobile and automotive » a attiré beaucoup de monde, l'amphi étant quasiment plein pour la plupart des conférences. Étrangement les « build systems » (Buildroot et Yocto) étaient assez absents cette année mis à part l'intégration de Xenomai et PREEMP_RT dans Yocto. Plusieurs conférences évoquaient les problèmes de mise à jour et maintenance d'un système embarqué, ce qui montre (si c'était nécessaire) l'utilisation croissante de Linux dans l'embarqué et l'industrie en général.

11. Debugging tools

Le track « debugging tools » a présenté un bon échantillon des outils de mise au point et profiling (GDB, strace, Ftrace, Dtrace). 

Plusieurs conférences abordaient les formats de stockage des informations de debug. Alors que DWARF5 standardise nombre d’extensions GNU, Rust nécessite encore de nouvelles extensions à DWARF et LLVM pour exprimer ses propres concepts.

Conclusion

Bien sûr, ceci n’est qu’une partie de l’histoire de la quarantaine de devrooms, d’autres comptes-rendus sont à lire [22] [23] [24] [25], et il nous reste encore assez de vidéos à regarder pour occuper tous nos week-ends jusqu’aux RMLL.

Vaut-il la peine de se déplacer au FOSDEM pour apprendre un sujet spécifique ? Probablement pas, mieux vaut rester chez soi à perdre son temps à se promener sur le Web. Tout comme l’intérêt d’un journal papier – GLMF pour ne pas le citer – qui aborde des sujets que nous n’avions pas prévu d’étudier en allant chez son marchand de journaux, la vraie plus-value d’aller à une conférence est de découvrir des sujets imprévus, des interlocuteurs que nous n’aurions pas rencontré par les interfaces virtuelles ou lors de recherches spécifiques des problèmes qui nous concernent à un instant donné. Pour aller à plusieurs conférences qualifiées de scientifiques chaque année, je [JMF] ne retrouve le vrai sens des conférences comme réunion de gens désireux d’apprendre et d’échanger qu’au FOSDEM, où l’audience participe par sa propre motivation et sans arrière-pensée de récompense (carriériste ou de reconnaissance de la communauté) aussi futile qu’inutile. Un week-end de réel plaisir à retrouver les membres d’une communauté de libristes désireux d’échanger sur les développements de l’année écoulée et sur les futures améliorations à amener aux outils que nous utilisons au quotidien.

Références

[1] Site officiel du FOSDEM : https://fosdem.org/2018/ 

[2] Boutique FSFE : https://fsfe.org/order/order.html 

[3] Graphique d’interconnexion français (AS3215 = Orange) : http://sg-pub.ripe.net/ixp-country-jedi/fr/2018/01/01 

[4] Démo interaction Peertube et Mastodon : https://frama.link/peertube-mastodon 

[5] Compte-rendu de Loïc Dachary : https://blog.dachary.org/2018/02/06/from-a-securedrop-talk-to-the-first-edition-of-the-privacy-devroom-at-fosdem/ 

[6] OpenJDK : http://openjdk.java.net/projects/ 

[7] Java Mission Control : http://www.oracle.com/technetwork/java/javaseproducts/mission-cjontrol/java-mission-control-1998576.html/

[8] JEP-286 : http://openjdk.java.net/jeps/286/ 

[9] Alpine : https://hub.docker.com/_/alpine/

[10] musl libc : https://www.musl-libc.org/faq.html/  

[11] Morbig : https://github.com/colis-anr/morbig/ 

[12] Checkstyle, PMD et autres outils dans le même genre : https://jenkins-le-guide-complet.github.io/html/sect-code-quality-tools.html/ 

[13] CERN Open Hardware License : https://kt.cern/open 

[14] Specification of the radio data system (RDS) for VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz, CENELEC (1998) : http://www.interactive-radio-system.com/docs/EN50067_RDS_Standard.pdf 

[15] METOP Space to Ground Specification, EADS/Astrium (2004) : http://www.meteor.robonuka.ru/wp-content/uploads/2014/08/pdf_ten_eps-metop-sp2gr.pdf 

[16] Zone DNS du FOSDEM : https://zonemaster.net/test/5226dfb8c8eced03 

[17] Commentaires des RFC ${RFCNUM} : http://www.bortzmeyer.org/${RFCNUM} 

[18] Dépôt git de BIND : https://gitlab.isc.org/isc-projects/bind9 

[19] DNS Violations : https://github.com/dns-violations/dns-violations 

[20] getdns : https://getdnsapi.net/ 

[21] OpenID Connect DNS-based Discovery draft : https://datatracker.ietf.org/doc/draft-sanz-openid-dns-discovery/ 

[22] Compte-rendu d’AmarOk : https://enconn.fr/dev/fosdem/ 

[23] Compte-rendu de Vesna Manojlovic : https://labs.ripe.net/Members/becha/fosdem-2018-what-happens-in-brussels-ends-up-on-the-internet 

[24] Compte-rendu de Zoffix Znet : https://p6weekly.wordpress.com/2018/02/05/whatever-fosdem-squashed/