Réunion Dev@LAL 52
166
LAL
Du dialogue "À propos" à la qualité logicielle
Dans le cadre du développement de PSPA, Marc Nicolas s'interrogeait sur la meilleure manière de gérer une fenêtre "À propos de..." en Wt. La principale difficulté envisagée était la mise à jour du numéro de version de l'application.
En soi, ce problème technique est courant, ce qui amenait Hadrien à se demander si le framework GUI ne peut pas le gérer nativement (la réponse est non). En gros, il faut interfacer le système de build avec le gestionnaire de version, et de lui faire générer des constantes accessibles au programme contenant le numéro de version. Les systèmes de build supportent ces deux points plus ou moins bien, mais c'est toujours possible à renfort de scripts et d'astuce.
Mais la discussion s'est aussi étendue vers une réflexion sur l'utilité d'un numéro de version, ce qui nous a conduits à des questions de qualité logicielle.
Fournir à l'utilisateur un accès facile au numéro de version d'un programme lui permet en effet de mieux signaler des bugs. Or, si on peut essayer d'automatiser un tel signalement (comme dans Eclipse, Windows et OSX), force est de constater que l'expérience utilisateur où on se retrouve avec une corvée à faire alors même qu'on vient d'essuyer un crash est souvent peu agréable.
Si on admet que le signalement d'un bug devrait être une procédure manuelle, comment faudrait-il procéder ? Donner un moyen de signaler le bug au sein de l'appli, comme dans Atrium et les betas de Windows ? Ou juste donner un lien vers le site de l'appli, et rendre le bugtracker facilement accessible à partir de là ?
Qui plus est, veut-on donner accès au bugtracker interne de l'équipe de développement à l'utilisateur, comme le font la plupart des projets open-source hébergés sur Github, ou bien veut-on comme Trello monter une équipe support qui est chargée de récupérer des signalements "bruts" (~ email), aider l'utilisateur à les préciser, et les intégrer dans le bugtracker interne comme il se doit? La dernière option est évidemment préférable, mais elle nécessite aussi plus de personnel...
Dans tous les cas, il semble pertinent de séparer les canaux de communication dévolus au signalement de bugs de ceux dédiés aux demandes de fonctionnalités. Plusieurs canaux sont possibles :
- L'e-mail aux auteurs, éventuellement par l'intermédiaire d'une mailing-list (indiqué dans la boîte "À propos", ou en ligne de commande dans le --help)
- Les applications web, comme Confluence dans LSST
- Le chat, comme dans ATLAS
Comme alternative au "A propos", le gestionnaire de paquet non officiel pour OSX (home)brew fournit un accès direct au site d'un paquet logiciel.
Blockchains
Oleg s'est rendu à un meetup sur les blockchains, ce qui a suscité un grand nombre de discussions sur ces dernières.
Besoins en formation et vulgarisation
Christian souhaiterait qu'on fasse un séminaire de vulgarisation dans l'esprit "La blockchain pour les nuls". Après discussion avec Oleg et David, il serait aussi utile de précéder ce séminaire par un prérequis, "La cryptographie pour les nuls".
LoOPS, quant à eux, seraient intéressés par une discussion plus approfondie.
La question de l'anonymat
Dans une discussion DEVLOG récente sur le vote électronique, quelqu'un a proposé la blockchain comme solution en invoquant comme bénéfices leur caractère distribué, résilient face aux attaques, et anonyme.
Hadrien était un peu surpris qu'on puisse réunir ces trois propriétés en un seul produit, et n'était pas au courant qu'une blockchain permettait l'anonymat, il a donc demandé confirmation de ce dernier point.
Après discussion avec Oleg, il semble qu'une blockchain ne soit pas anonyme, et ne puisse pas facilement le devenir. En effet, ce qui rend les blockchain résilientes face aux attaques, c'est l'existence d'un registre public, vérifiable par tous, qui décrit toutes les transactions survenues de façon nominative (les utilisateurs étant identifiés par leur clé publique).
Pour anonymiser une blockchain, la seule solution serait donc à première vue d'utiliser des techniques similaires à celles qu'on utilise pour anonymiser les communications sur internet ou les transactions bancaires, basée sur l'utilisation d'identités multiples par les utilisateurs et sur une complexification artificielle du flux de données.
Sécurité d'une blockchain
Christian s'intéressait à la sécurité cryptographique d'une blockchain. La principale faille conceptuelle de cette technologie, qui ne sera sans doute jamais surmontée, est que le système cesse d'être fiable dès lors qu'un attaquant possède une certaine proportion des ressources utilisées pour valider les transactions (puissance de calcul, interconnections réseau...). On parle de "Majority Attack".
Dans le cas du protocole Bitcoin, la borne supérieure théorique pour cette proportion est de 50% (si la majorité de l'infrastructure s'accorde sur une vision des faits, on considère que la minorité restante a tort). Des failles au niveau du protocole permettent de diminuer cette proportion, mais elles sont basées sur des scénarios d'attaque peu réalistes et peuvent être corrigées par une modification du protocole de communication si nécessaire.
Il est arrivé plusieurs fois par le passé qu'un grand groupe de mineurs comme GHash parvienne à contrôler 50% des ressources de calcul de la communauté bitcoin, mais à chaque fois la situation s'est résolue pacifiquement par une redistribution des ressources de calcul vers d'autres groupes.
Une autre faille de Bitcoin est que comme le protocole récompense de moins en moins les mineurs au fil du temps, de nombreuses personnes pourraient être tentées de cesser de contribuer à l'infrastructure du réseau. Cela concentrerait la puissance de calcul en un nombre réduit de mains, et diminuerait donc la robustesse du système.
A priori, ces deux problèmes seraient moins présents dans une utilisation non financière des blockchains. Restent alors les failles des techniques cryptographiques sous-jacentes et de leur implémentation logicielle, qui n'ont pour l'instant pas été mises en défaut.
Bilan du meetup blockchain
Face à l'épuisement susmentionné du Bitcoin, de nombreux mineurs se demandent quoi faire des formidables ressources de calcul qu'ils ont accumulées. C'est peut-être une bonne occasion pour récupérer des fermes de GPUs et de FPGAs bon marché !
Antoine s'étonne de l'effort humain important que mettent les banques dans un système visant à la suppression des banquiers centralisés, ce qui peut sembler paradoxal. Selon Oleg, il s'agit en réalité d'un exemple typique de la pensée à court terme des milieux financiers : actuellement, il y a beaucoup d'argent à se faire dans la communauté Bitcoin, et les institutions financières traditionnelles veulent leur part de ce gâteau.
EDF se montre aussi très intéressée par les blockchains, car ces dernières pourraient être appliquées dans le contexte actuel de libéralisation des marchés locaux de l'énergie, où il devient plus facile d'échanger directement de l'énergie à petite échelle sans passer par un comptage centralisé. Ils voient dans les blockchains un moyen de stocker et contrôler localement l'historique des transactions énergétiques.
Le prototype d'Oleg
Oleg travaille actuellement sur la notion de Smart Contract, où une blockchain est utilisée pour valider des transactions non financières de manière décentralisée. Son projet est de montrer qu'on peut, sur une grille de calcul, s'authentifier et réserver des ressources par le biais d'une blockchain.
En effet, les serveurs centralisés qui sont habituellement utilisés dans ce but sont une vulnérabilité évidente, tant d'un point de vue de sécurité que de fiabilité du système. Conscient de cela, de nombreux administrateurs système tentent de sous-traiter leur authentification à des entreprises comme Google et Facebook, mais ne font ce faisant que renforcer la vulnérabilité du service de ces dernières. Les pannes des serveurs SSO Google et Facebook ont ainsi un impact très important sur l'intégralité du Web, et le pouvoir de nuisance qu'on met ce faisant entre les mains de ces entreprises est aussi très inquiétant.
Dans ce contexte, une blockchain "locale" pourrait être un moyen de renforcer le système d'authentification et le rendre plus fiable. C'est cette question qu'Oleg tente d'étudier.
Digression sur la consommation d'énergie
La blockchain la plus connue, Bitcoin, est basée sur un système de preuve de travail ("Proof-of-Work") : pour insérer des données de transaction dans la blockchain, un mineur doit prouver qu'il a effectué un calcul complexe. Avec ce système, il est beaucoup plus rapide de diffuser et vérifier un bloc de transactions que de le générer, c'est ce qui permet de protéger le système contre les fraudeurs et de garantir une bonne consistance de sa base de données distribuée.
Cependant, ces calculs ont un coût énergétique certain, bien supérieur à celui nécessaire à la maintenance d'un datacenter bancaire par exemple, puisqu'au lieu de "juste" enregistrer des transactions dans une base de données, on doit au passage effectuer des calculs énergivores. Pour certains, c'est le prix à payer pour des données distribuées fiables, pour d'autres c'est un gaspillage d'énergie inacceptable. La recherche d'algorithmes moins énergivores est un axe de recherche majeur de la communauté blockchain.
Retour divers
Globalement, les participants de l'action LoOPS/DEVLOG sur la validation logicielle étaient satisfaits, bien que certains déplorent l'usage de technologies Java pas toujours évidentes à appréhender. Malheureusement, ce problème semble insoluble : il n'est pas raisonnable de demander aux intervenants d'adapter leurs tutoriels à tous les langages de programmation possibles, et si l'on fait des tutoriels en Python, les non Pythonistes seront lésés, etc...
Les commandes de livres de fin d'années sont ouvertes à la bibliothèque, et ceux qui ont des besoins dans ce domaine sont priés de contacter rapidement Sabine au bureau 110.
Enfin, il y a eu quelques discussions sur les évolutions pas toujours bien connues ni bien supportées par les implémentations de standards anciens comme SQL, C++, ou Fortran.