Toolbox: Environnements de développement isolés pour lutter contre les bogues et les logiciels malveillants dans le code en cours de développement

Vous voulez un conteneur d'utilisateurs persistant sans votre /home ? J'essaie juste de mieux comprendre l'exigence/le cas d'utilisation. - Par rapport à la simple utilisation d'un conteneur Fedora jetable standard ?

Considérez un compte Unix qui est utilisé à la fois pour la maison et le travail. Pour un conteneur de travail, je préfère peut-être monter uniquement mon répertoire de travail dans le conteneur.

Considérez une application GUI non fiable. Il peut n'avoir besoin d'accéder qu'à un dossier spécifique pour charger/enregistrer des fichiers. Il n'a pas besoin d'accéder à mon dossier .ssh et à d'autres fichiers sans rapport.

Pour améliorer la sécurité, Chrome OS ne partage pas les dossiers vers les conteneurs par défaut à partir de l'hôte. Là, si vous souhaitez fournir des données aux conteneurs à partir de votre répertoire personnel ou d'une clé USB, vous les partagez explicitement.

La conteneurisation en tant que fonctionnalité de sécurité perd une valeur significative si vous donnez toutes vos données au conteneur non fiable par défaut !

@juhp, je vois que vous travaillez beaucoup avec les packages Haskell. Supposons que l'un des packages Haskell que vous installez à distance a été compromis. Les packages Haskell ont-ils besoin d'accéder à votre dossier .ssh ou à votre portefeuille Bitcoin ? Pourquoi tout partager dans votre environnement de développement Haskell par défaut ?

Assez récemment, il y avait un module NPM qui pouvait toujours local Bitcoin s'il était installé :
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

Le module était populaire et en fait mon équipe l'avait installé dans notre arbre. Nous n'avons pas rempli les autres critères pour déclencher un vol de bitcoin, mais ce risque aurait été complètement atténué si notre environnement de développement n'avait pas un accès complet à nos répertoires personnels par défaut. Aucun employé n'aurait choisi de partager son portefeuille Bitcoin dans cet environnement de développement.

C'est tout à fait valable mais ça va être difficile.

En pratique, je pense que le meilleur moyen est de faciliter l'exécution des boîtes à outils en tant qu'utilisateurs distincts (créer temporairement de nouveaux uid, chacun avec son propre /home ) - nécessite un service système privilégié pour le faire.

Maintenant, si vous souhaitez partager des fichiers, par exemple en lecture seule, cela devient plus compliqué.

Est-il possible d'exclure des fichiers/répertoires d'un répertoire bind-mount ?

Pour m'assurer de bien comprendre le défi, je vois que le montage du répertoire personnel se fait en une seule ligne de code

    --volume "$HOME":"$HOME":rslave

Mais le défi ici est toujours de faire fonctionner les applications GUI et certaines autres fonctionnalités, car ces fonctionnalités s'attendent à ce que l'utilisateur à l'intérieur et à l'extérieur du conteneur soit le même ?

C'est en fait une caractéristique assez importante. Je pense que c'est bien de monter à la maison par défaut, mais il devrait être possible d'utiliser un conteneur d'une manière non fiable. Monter à la maison dans un conteneur suppose que vous faites confiance au conteneur, ce qui n'est souvent pas le cas dans un conteneur jetable. Même dans des cas simples comme le test de certains modules NPM, j'aimerais avoir la tranquillité d'esprit que cela ne va pas détruire mon dossier personnel.

@markstos peut-être pouvez-vous tester ce que vous pouvez faire sans le montage domestique ou si vous montez simplement un répertoire spécifique (cwd) ?

@juhp En fait, c'était le clou du spectacle pour moi - j'ai arrêté d'évaluer Silverblue une fois que j'ai rencontré cette fonctionnalité manquante. Si cela est résolu, je peux donner à Silverblue un deuxième regard. J'ai également été déçu de constater qu'il n'était pas facile de comprendre comment exécuter un conteneur Ubuntu, qui est le système d'exploitation que j'utilisais auparavant.

Si Fedora souhaite accueillir des utilisateurs provenant d'autres distributions Linux, faciliter l'exécution de leur ancienne distribution dans un conteneur serait un bon point de départ.

@markstos merci - je ne suis qu'un autre utilisateur de Toolbox. :-)
Je suis tout à fait d'accord pour dire que l'extension de Toolbox pour prendre en charge plus de systèmes d'exploitation serait en effet très utile.
Notez que Toolbox fonctionne également sans Silverblue (c'est-à-dire sur d'autres éditions de Fedora).

@juhp En fait, c'était le clou du spectacle pour moi - j'ai arrêté d'évaluer Silverblue une fois que j'ai rencontré cette fonctionnalité manquante

Qu'avez-vous fait avant? Y a-t-il un autre outil/approche que vous utilisiez qui ne fonctionnait pas sur Silverblue ?

Rien ne vous empêche, par exemple, d'utiliser une machine virtuelle jetable (comme QubesOS), ou d'ailleurs d'avoir un script personnalisé qui implémente certaines des suggestions de ce fil. Sans doute, nous devrions être plus avisés et intégrer des fonctionnalités de type QubesOS dans Silverblue.

Mais de toute façon, la technologie de VM et de conteneur existante est là. En fait, toolbox aujourd'hui est vraiment un tas de scripts qui brouillent intentionnellement podman avec l'hôte. Si vous ne voulez pas l'intégration, vous pouvez commencer par podman run ... puisque c'est la valeur par défaut.

@cgwalters J'ai commencé à utiliser Chrome OS sur mon ordinateur portable personnel et j'ai Crostini . J'aime le fait qu'il prenne en charge les applications GUI ainsi que les applications de ligne de commande. J'aime aussi que les conteneurs soient privés par défaut. Je dois explicitement partager des dossiers de données ou des clés USB avec eux. D'autre part, la prise en charge du son et du wayland est automatiquement configurée dans ces conteneurs.
URL
J'ai évalué des solutions similaires à utiliser sur mon ordinateur portable de travail à la place. Une option serait Cloudready de Neverware, un système d'exploitation Chrome open source pour le matériel PC. Parfois, Crostini plante des ports, des données sont perdues et il est nécessaire de recommencer. Pour cette raison, j'hésite à doubler ChromeOS / Crostini maintenant.

Silverblue avait également l'air convaincant jusqu'à ce que je découvre qu'il ne semble pas prendre en charge les conteneurs Ubuntu prêts à l'emploi et qu'il partage trop mes données personnelles avec des conteneurs auxquels je n'ai pas l'intention de faire confiance. J'ai aussi regardé Clear Linux. Il a le même concept d'exécution de presque tout dans des conteneurs. Je ne suis pas ravi des liens étroits avec Intel et x86. Ce n'est pas non plus principalement un système d'exploitation de bureau. Une dernière option (par défaut ?) serait de s'en tenir à Ubuntu en tant que bureau et de déplacer davantage mon travail de développement dans des conteneurs LXD, que Crostini de Chrome utilise. Je devrais pouvoir copier des conteneurs LXD entre mes ordinateurs portables professionnels et personnels, même si le système d'exploitation hôte est différent. En utilisant des modèles LXD, je devrais pouvoir configurer un modèle partageant suffisamment de montures dans les conteneurs pour la prise en charge de Wayland.

note latérale : Merci pour toutes les années passées à maintenir Rhythmbox !

Peut-être que je comprends mal la mission de toolbox . Dans le fichier README :

.. L'intention de ces systèmes est de décourager l'installation de logiciels sur l'hôte

Pourquoi? Avec le partage par défaut de toutes vos données personnelles dans le conteneur, je ne pense pas qu'une sécurité améliorée puisse être réclamée.

L'avantage potentiel restant serait l'isolement, de sorte que vous pourriez installer des versions conflictuelles de logiciels côte à côte.

Si le comportement de partage permanent persiste, il pourrait être utile de mettre à jour la documentation en précisant que le toolbox partage l'intégralité de votre répertoire personnel dans les conteneurs, que le comportement ne peut pas être désactivé et qu'il ne doit pas être utilisé avec des informations non fiables. conteneurs.

Je comprends que je peux utiliser podman directement, mais j'étais intéressé par une solution de conteneur avec intégration de l'interface graphique. Lorsque vous cherchez comment accomplir cela avec podman , l'approche recommandée est l'utilisation de toolbox :

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos Si vous êtes intéressé, j'ai créé PR #298 qui crée une image Ubuntu 19.04.

Je pense qu'il y a une certaine confusion ici.

Notre README.md a grandi et s'est un peu transformé au fil des mois, et est probablement un peu plus difficile à saisir. Auparavant, il disait simplement Piratage sur les Fedoras basées sur OSTree .

Si vous installez Silverblue (ou tout autre système d'exploitation basé sur OSTree d'ailleurs), la difficulté de déboguer le système d'exploitation ou de configurer un environnement de développement devient immédiatement évidente. Toolbox existe pour résoudre ce problème.

.. L'intention de ces systèmes est de décourager l'installation de logiciels sur l'hôte

Pourquoi? Avec la valeur par défaut est de partager toutes vos données personnelles dans le conteneur par défaut, je
ne pensez pas qu'une sécurité améliorée puisse être réclamée.

La sécurité est un mot surchargé. Toolbox ne fait aucune réclamation à ce sujet.

Pendant de nombreuses décennies, tout processus exécuté en tant que votre UID pourrait examiner vos clés cryptographiques privées, vos documents, vos photos, etc. et même les transmettre à l'autre bout de la planète sans que vous le sachiez jamais. C'est le statu quo des systèmes d'exploitation clients logiciels libres.

Flatpak change cela en séparant chaque application graphique et le système d'exploitation dans leurs propres domaines de sécurité. Silverblue renforce cette séparation en rendant difficile l'installation de logiciels directement dans l'image du système d'exploitation hôte. Ainsi, pour une expérience utilisateur fluide, vous devez vraiment utiliser des applications livrées sous forme de Flatpaks.

Cependant, comme je l'ai mentionné en haut, cette image de système d'exploitation verrouillée présente son propre ensemble de problèmes. La façon dont nous les résolvons est un compromis entre commodité et sécurité. Plus la solution est radicale, plus il serait difficile pour les utilisateurs Linux existants d'adopter Silverblue.

À l'heure actuelle, Toolbox penche pour l'adoption plutôt que pour la sécurité ; car, que vous utilisiez ou non Toolbox, Silverblue apporte une amélioration considérable à l'état des systèmes d'exploitation clients de logiciels libres et mettre cela entre les mains de l'utilisateur serait une étape positive.

De plus, il ne s'agit pas seulement de sécurité. C'est aussi une question de stabilité.

Il est très difficile de tester une distribution Linux conventionnelle. Les packages et les miroirs sont toujours mis à jour par des contributeurs aléatoires sur des miroirs aléatoires partout dans le monde - l'explosion combinatoire ne peut être gérée que par un système élaboré de gels. Lorsque les choses tournent mal, et c'est le cas, il est également très difficile pour un utilisateur d'annuler une mise à jour, et des choses comme des coupures de courant au milieu d'une mise à jour peuvent irrémédiablement casser le système.

Un système d'exploitation basé sur OSTree change tout cela.

Je comprends que je peux utiliser podman directement, mais j'étais intéressé par une solution de conteneur avec interface graphique
l'intégration. Lorsque vous cherchez comment accomplir cela avec podman, l'utilisation de la boîte à outils est
l'approche recommandée :

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

La question est pourquoi voulez-vous utiliser Podman pour exécuter des applications graphiques ? :)

En général, Podman (ou un conteneur OCI) est une mauvaise option pour exécuter des applications GUI. C'est la seule raison pour laquelle Flatpak existe et Toolbox n'est pas en concurrence avec cela.

Cependant, il existe un chevauchement, dans le sens où les conteneurs Toolbox ont une certaine intégration au bureau, et il existe des cas où la possibilité d'exécuter une application GUI non Flatpaked est extrêmement utile dans l'immédiat à court terme. Il se peut que l'application que vous souhaitez n'ait pas encore été Flatpaked, ou peut-être que la version Flatpaked manque de certaines fonctionnalités. Il se peut que vous travailliez sur une bibliothèque utilisée par des applications graphiques et que vous souhaitiez exécuter rapidement un programme de test unique pour voir si votre bibliothèque fonctionne comme prévu.

Toolbox peut, en effet, aider dans de tels cas, mais c'est différent de dire que l'objectif principal de Toolbox est de conteneuriser des applications graphiques. L'objectif principal de Toolbox est de vous permettre de faire votre piratage sur un système d'exploitation basé sur OSTree.

Maintenant, si vous utilisiez un IDE natif de conteneur comme GNOME Builder , qui est livré sous forme de Flatpak, et configure automatiquement un conteneur pour créer et exécuter le logiciel sur lequel vous travaillez, alors vous n'auriez pas du tout besoin de Toolbox.

Cependant, tout le monde n'utilise pas GNOME Builder, et les IDE les plus populaires comme Visual Studio Code ne sont pas natifs du conteneur comme ça. Par conséquent, Toolbox.

@debarshiray Merci pour la réponse réfléchie et approfondie. L'exemple que j'ai donné ci-dessus n'était pas pour une application graphique qui pourrait être couverte par Flatpak. J'ai donné l'exemple du développement de Node.js. Il y avait récemment de vrais malwares dans la chaîne de dépendances Node.js qui pouvaient voler dans un portefeuille crypto local. Les clés SSH pourraient être volées tout aussi facilement. Alors que le README indique que le projet cible les développeurs, le partage avec les conteneurs par défaut ne protège pas les développeurs de ce type d'attaque.

Toolbox ne protège pas contre le vol de fichiers personnels lors du développement de CLI avec des dépendances non fiables. Compte tenu de la complexité des logiciels open source modernes, certaines parties de l'arbre de dépendance ne doivent pas être fiables.

Je trouve que le fichier README actuel est trompeur : exécuter "sans privilèges dans un conteneur" ressemble à de la sécurité, mais ce n'est qu'un théâtre de sécurité - tous les fichiers personnels sont accessibles dans le conteneur. Ci-dessus, vous clarifiez que Toolbox n'a pas l'intention de prétendre à la sécurité. Je pense que ce serait une déclaration utile à inclure dans le fichier README pour clarifier que malgré l'utilisation de conteneurs, il s'agit d'un outil de commodité et non de sécurité.

@debarshiray Merci pour la réponse réfléchie et approfondie. L'exemple que j'ai donné
ci-dessus n'était pas pour une application graphique qui pourrait être couverte par Flatpak. j'ai donné le
exemple de développement Node.js. Il y avait récemment de vrais malwares dans le Node.js
chaîne de dépendance qui pourrait voler dans un portefeuille crypto local. Les clés SSH pourraient être volées
tout aussi facilement. Alors que le README dit que le projet cible les développeurs, le
share-with-containers-by-default ne protège en rien les développeurs de ce type d'attaque.

Oui, pour le moment, Toolbox essaie simplement de reproduire l'environnement traditionnel basé sur des packages dans un système d'exploitation basé sur des images.

Je trouve que le README actuel est trompeur : Exécuter "entièrement sans privilège dans un conteneur"
ressemble à de la sécurité, mais ce n'est qu'un théâtre de sécurité - tous les fichiers personnels sont accessibles dans
le conteneur. Ci-dessus, vous clarifiez que Toolbox n'a pas l'intention de prétendre à la sécurité.
Je pense que ce serait une déclaration utile à inclure dans le fichier README pour clarifier que malgré
l'utilisation de conteneurs, il s'agit d'un outil de commodité et non de sécurité.

Commit c047659c1d85ca982374da5c58ee7a24ba3847bd est l'endroit où cette ligne a été ajoutée. Je crois que @cgwalters voulait dire que vous n'avez accès qu'à votre propre UID à l'intérieur d'un conteneur de boîte à outils et que la vraie racine (c'est-à-dire l'UID 0 sur l'hôte) n'est ni impliquée ni disponible pour vous.

J'ai également le même problème. J'ai installé Silverblue dans l'espoir de pouvoir exécuter un logiciel auquel je ne peux pas faire entièrement confiance sans avoir à craindre qu'il ne vole mes clés SSH et d'autres informations sensibles.

La réalisation que la boîte à outils ne me permet pas de faire cela a été une énorme déception et m'a amené à reconsidérer l'utilisation de Silverblue pour commencer. Personnellement, je ne me soucie pas de l'installation du système d'exploitation principal. Je peux toujours le réinstaller. Les informations que je veux vraiment garder séparées se trouvent dans mon répertoire personnel.

Serait-il possible de spécifier avec une plus grande granularité précisément quelles parties du répertoire personnel sont partagées ? Si l'on pouvait mettre en liste blanche uniquement les répertoires nécessaires à la boîte à outils (probablement ceux liés à la configuration du bureau, etc.), cela résoudrait de nombreux problèmes.

Maintenant, je suis parfaitement conscient des problèmes de sécurité. Comme j'utilise Qubes OS depuis plusieurs années, le problème de l'isolement est difficile. Même si vous protégez le répertoire personnel, cela ne suffira pas car un programme exécuté à l'intérieur d'un conteneur peut toujours tirer parti d'autres moyens de communication entre les conteneurs, tels que le presse-papiers. J'en suis conscient et je suis prêt à accepter certains de ces risques en échange de la commodité de quelque chose comme une boîte à outils par rapport à une installation complète de Qubes.

Une solution de contournement est publiée ici .

La solution de contournement exploite le fait que toolbox est implémenté en tant que script bash qui référence la variable d'environnement $HOME dans tous les cas où le chemin de /home/user doit être recherché. Ainsi, en définissant la variable d'environnement $HOME pour un appel particulier sur toolbox , un répertoire autre que votre répertoire personnel complet rempli de fichiers personnels précieux sera partagé avec un conteneur potentiellement non fiable.

Sur cette base, il semble que vous puissiez partager un répertoire vide contenant uniquement la configuration de la boîte à outils en lançant la boîte à outils avec un wrapper comme celui-ci :

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

Si ce script était nommé toolbox et mis dans votre $PATH avant le système toolbox , alors il semble que cela résoudrait ce problème. Cette solution n'a pas été testée.

Cette fonctionnalité fonctionne désormais dans le fork tlbx : https://gitlab.com/uppercat/tlbx/issues/3

J'ai également le même problème. J'ai installé Silverblue dans l'espoir de pouvoir
exécuter un logiciel auquel je ne fais peut-être pas entièrement confiance sans avoir à craindre qu'il ne vole mon SSH
clés et autres informations sensibles.

Euh... cela semble trompeur. Si vous souhaitez exécuter un logiciel non fiable en tant qu'utilisateur, Flatpak réduit déjà vos craintes de perdre des informations sensibles. Si vous voulez des environnements de développement isolés, c'est autre chose.

De plus, rien de tout cela n'est spécifique à Silverblue. Les problèmes existent depuis des décennies et les solutions ne sont pas spécifiques à Silverblue - elles fonctionnent également sur les systèmes d'exploitation traditionnels basés sur des packages.

La solution de contournement exploite le fait que toolbox est implémenté en tant que script bash qui
référence la variable d'environnement $HOME dans tous les cas où le chemin de /home/user
doit être recherché. Ainsi, en définissant la variable d'environnement $HOME pour un
appel à toolbox provoque un répertoire autre que votre répertoire personnel complet plein de précieux
fichiers personnels à partager avec un conteneur potentiellement non fiable.

Oui, c'est un bon hack. :)

Cependant, l'objectif principal du projet Toolbox est de permettre la configuration d'une grande variété d'environnements de développement sur des systèmes d'exploitation basés sur des images (en particulier basés sur OSTree) avec à peu près le même effort que leurs homologues basés sur des packages. Rendre ces environnements de développement plus sûrs est certainement un souhait valable, mais ce n'est pas quelque chose qui figure sur la liste des tâches immédiates, car le problème n'est pas nouveau et existe depuis toujours.

De plus, Silverblue n'est pas nécessairement une question de sécurité. Je le vois plutôt comme une amélioration de la stabilité et de la robustesse du système d'exploitation. Cependant, cela encourage l'utilisation de Flatpaks, donc en ce sens, cela améliore indirectement la sécurité.

Par conséquent, il est utile de garantir la parité des fonctionnalités avec les distributions Linux basées sur des packages, même si elles conservent certains de leurs problèmes existants. Résoudre certains problèmes et rendre les solutions accessibles à la base d'utilisateurs existante vaut mieux que de ne rien résoudre. :)

Je vais clore ce problème afin que la liste des problèmes ouverts ne devienne pas incontrôlable et continue de refléter approximativement les éléments qui figurent sur la liste de tâches actuelle. Cependant, il sera toujours là pour référence future.

Je suis d'accord pour dire que notre README.md devrait être plus facile à lire, cependant.

Hum, je ne comprends pas cet argument. Juste parce qu'un problème est ancien et existe depuis toujours, ne le résolvez pas ? Ce n'est pas un bon point de vue, à mon humble avis.
Et comme vous le dites, flatpak fait cela : il améliore progressivement la sécurité et isole les applications. Ils n'ont pas non plus dit "hmm, nous avons expédié des applications sous forme de packages rpm pour toujours, pourquoi devrions-nous résoudre ce problème ?", ils l'ont simplement résolu.

Je ne vois aucune raison pour laquelle la boîte à outils ne devrait pas au moins isoler également le répertoire d'accueil. Je suppose donc que la discussion peut se poursuivre sur https://github.com/containers/toolbox/issues/348 de toute façon.

Je pense que les contributeurs et les responsables de la boîte à outils considèrent ce fil comme une critique de l'idée et du travail qui est mis dans le projet. Je pense que cela devrait être considéré comme une fonctionnalité requise par de nombreuses personnes enthousiasmées par l'idée. Je n'ai pas de résistance à travailler sur une fonctionnalité qui vous permet de monter un répertoire de travail autre que $HOME. C'est une fonctionnalité qui pourrait grandement améliorer la fonctionnalité et le cas d'utilisation, ce qui améliorera également l'adoption et l'intérêt.

C'est moi qui ai suggéré de changer la variable $HOME dans #348 . C'est une solution bidon car elle pose des problèmes lorsque vous souhaitez travailler avec deux conteneurs multiples avec des répertoires $HOME différents. Ma crainte est même que cela ne fonctionnera pas lorsque la boîte à outils sera réécrite avec go.

Beaucoup de gens demandent cette fonctionnalité et c'est devenu une barrière à l'entrée pour de nombreuses personnes d'adopter les boîtes à outils, rpm-ostree et silverblue. Même s'il ne s'agit pas de sécurité, c'est une fonctionnalité qui va ouvrir de nombreuses possibilités pour travailler avec des boîtes à outils.

Je suis prêt à aider sur la question si je le peux et je pense que d'autres le seront aussi. J'espère que cette fonctionnalité ne deviendra pas un point de discorde et ne sera pas exclue des futures versions de la boîte à outils. C'est à mon avis la seule chose qui manque actuellement dedans. Ce serait comme obtenir un DNF dans un marathon en abandonnant les 10 derniers mètres. (jeu de mots volontaire :) )

C'était une rupture d'accord pour moi. J'ai abandonné la boîte à outils et Silverblue après
trouver ce défaut.

Juste parce qu'un problème est ancien et existe depuis toujours,
ne le résolvez tout simplement pas ?? Ce n'est pas un bon point de vue, à mon humble avis.

Ne pas avoir quelque chose sur la liste de choses à faire immédiate n'est pas la même chose que ne pas le résoudre . La priorité existe.

Et comme vous le dites, flatpak fait cela : il améliore étape par étape la sécurité et
isole les applications. Ils n'ont pas non plus dit "hmm, nous avons expédié des applications comme
rpm packages pour toujours, pourquoi devrions-nous résoudre ce problème ?", ils viennent de le faire
résoudre.

J'aime votre utilisation du mot ils .

D'accord, sympa, donc si j'interprète ça correctement, c'est peut-être encore une idée pour l'avenir, mais pas sur votre « liste de choses à faire immédiate » ? (même si je suppose que c'est facile à mettre en œuvre, surtout si vous pouvez simplement choisir quelques correctifs à partir d'un fork )*

Si c'est le cas, gardez peut-être ce problème ouvert et étiquetez-le comme « aide recherchée » – bien que vous n'ayez pas vraiment besoin d'aide, je ne sais pas… qu'est-ce qui vous empêche de l'implémenter ? Je suppose que vous avez juste besoin de dire que vous acceptez les relations publiques sur ce sujet et que cela sera mis en œuvre.
Je ne vois rien qui vous en empêche – et vous pouvez toujours atteindre la parité des fonctionnalités, peu importe… ce n'est vraiment qu'une fonctionnalité mineure. :pensée:

* Oui, je vois et je sais que cela a été réécrit dans Go maintenant, mais peut-être que cela aide encore ou presque – je ne sais pas. Au moins, cela démontre qu'il est facile à mettre en œuvre.

Détourner un peu ce problème ici au cas où l'un des participants voudrait vérifier et donner son avis sur mon prototype à https://gitlab.com/bkhl/etui

Il s'agit d'une alternative à Toolbox lorsque vous souhaitez un conteneur de développement plus strict.

@bkhl Merci ! Mis en signet.