2 évolutions s'opèrent en parallèle en matière de logiciels :
- de plus en plus de logiciels promettent le chiffrement de bout en bout, rendant le fournisseur incapable d'accéder aux données de l'utilisateur (exemple: signal, réseau Matrix, Nextcloud avec chiffrement de bout en bout, etesync)
- de plus en plus de logiciels sont développés comme "applications web", servies depuis un site internet (exemple: le client Matrix element.io, Microsoft Office365, ...)
En l'état actuel des technologies, les deux objectifs ne sont pas totalement compatibles. Une application qui fait du chiffrement de bout en bout, si on y accède via le navigateur depuis un site internet tiers, sera vulnérable à une attaque sur ce site internet : un intrus peut modifier l'application de sorte à faire fuiter les clés de chiffrement de ceux qui l'exécutent dans l'intervalle, ou trouver une faille (type XSS) de façon à exfiltrer les clés de certain.e.s utilisateurs ou utilisatrices. À l'inverse, une application "desktop" sera moins rapidement attaquable : il faut que l'attaquant publie une version vérolée, puis que les utilisateurs mettent à jour, avant que l'attaque soit effective. Si la validité des mises à jour est contrôlée à l'aide d'un mécanisme de signature cryptographique (comme c'est le cas des mises à jour logicielles des distributions Linux), l'attaque est rendue encore plus compliquée.
Pour les applications web, l'équipe derrière eteSync propose une solution sous forme d'extension de navigateur qui vérifie la signature GPG des pages renvoyées par le serveur.
PyPI, le point central de distribution de paquets Python, demande aux mainteneurs des paquets les plus populaires de sécuriser leur compte avec un second facteur d'authentification, afin de limiter le risque que le compte soit compromis et tous les utilisateurs du paquet par ricochet.
Armin Ronacher s'élève vivement contre cette nouvelle exigence, trouvant gonflé de demander à celui qui a gentiment et gratuitement partagé son travail de supporter la charge de la sécurité des utilisateurs de son travail. Après tour, ça n'est pas "sa faute" si son travail devient populaire.
Dans Yes, I have opinions on your open source contributions, James Bennett lui répond que nous sommes tous et toutes utilisatrices des paquets Python (et pas seulement les grosses entreprises qui ont de l'argent), et que si la communauté propose de fixer des règles pour nous protéger tous, c'est être singulièrement asocial de les refuser.
Le premier commentateur sur Linux Weekly News remarque avec malice que les obligations qu'Armin Ronacher craint de voir imposées ensuite par PyPI (signature cryprographique, standard de qualité, traitement diligent des problèmes de sécurité, mesures en cas de défaillance du mainteneur) sont précisément les garanties apportées par les dépôts des distributions Linux. Ce sont les attentes des utilisateurs, y compris (à tort) quand ils utilisent PyPI, npm, cargo ou autre dépôt lié à un langage de programmation.
Points relatifs à la sécurité:
✅ stabilité du langage (mais il manque encore des choses indispensables)
✅ la doc indique clairement de séparer la résolution des dépendances par projet
⛔ installer une dépendance passer par l'exécution de code provenant de celle-ci
Arnaud Rebillot rend compte des efforts fructueux pour "debianiser" Docker-ce (sous le nom de docker.io). Le problème principal réside dans le fort couplage en go entre un projet et ses dépendances : il faut alors séparer en plusieurs paquets indépendants lorsque les dépendances peuvent être utilisées ailleurs et maintenues séparément, mais sans séparer les composants d'un même logiciel.
Il est ironique de déployer tout cet effort pour "débundler" (définitions) un outil destiné à faire tourner des applications qui le sont au plus haut point (les conteneurs).
L'attaque solarwinds révèle l'importance de contrôler la chaîne d'approvisionnement de nos logiciels et systèmes. Les logiciels libres et la compilation reproductible apportent des garanties de transparence, évitant cette classe d'attaques.