Deuxième article d’une série autour de Guix, après une brève introduction générale, voici un article plus programmatique sur le remplacement (ou la cohabitation) de l’outil apt par guix. Je précise qu’il s’agit de dépêches dont l’objectif est de vulgariser les notions phares de Guix et de les illustrer par des cas pratiques.
Sommaire
- Introduction
- Guix pour remplacer APT
- Installation de paquets
- Utilisation des paquets
- Désinstallation des paquets
- Mise à jour des paquets
- Rechercher un paquet
- Mettre à jour Guix
- Revenir en arrière suite à un problème
- Exécuter une application en mode « bac à sable »
- Conclusion
- FAQ
Introduction
Guix étant un gestionnaire de paquets avant tout, il est tout naturel qu’il puisse constituer un remplaçant des autres gestionnaires de paquets existants.
Si, comme moi (ou comme Bryan Lunduke), vous trouviez qu’il y a déjà trop de fragmentation dans le desktop et qu’il faudrait juste choisir une bonne fois pour toutes un format de paquet (par exemple les .deb) et un gestionnaire de paquets (par exemple apt) et ainsi avoir une compatibilité entre les distros, Guix (ou Nix, mais ce n’est pas le sujet de cette dépêche) pourrait être un bon candidat ! En effet, Guix a de nombreux avantages par rapport à ses concurrents :
- il est transactionnel, ce qui signifie que si l’installation des paquets n’aboutit pas pour une raison ou pour une autre (p. ex. coupure d’alimentation), le système n’est pas impacté ;
- il permet d’avoir plusieurs versions d’un même logiciel installées sur la même machine sans aucun conflit ;
- il permet d’installer les paquets sans avoir les droits d’administration (oubliez
sudo) ; - il est possible de revenir, à tout moment, à un état antérieur du système et donc être sûr de retrouver un état fonctionnel si jamais une mise à jour n’a pas fonctionné.
Guix a d’autres avantages, mais déjà ces quatre‑là le rendent important.
Guix pour remplacer APT
Voici par exemple comment je remplace progressivement l’utilisation de apt (et snap par la même occasion) sur mon système Xubuntu 18.04.
Installation
Tout d’abord, j’ai installé Guix très facilement en suivant les instructions et l’installeur officiel.
Avant toute chose : gestion des locales
Comme les paquets Guix ne sont pas forcément compilés avec la même libc que les paquets de notre système d’exploitation, il faut en premier lieu installer le paquet responsable de la gestion des locales de la libc, comme c’est précisé dans la doc :
guix install glibc-locales
Puis rajouter cette variable d’environnement à tous vos fichiers de session (.bashrc, .xsessionrc, etc.) :
export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale
Sans cela, vous risquez d’avoir, comme moi, quelques problèmes.
Installation de paquets
Après avoir installé guix (voir plus haut), installer un paquet avec Guix est une opération très simple. J’ai commencé par remplacer certains paquets de ma distribution par des versions plus à jour. Par exemple (sans avoir les droits administrateur) :
guix install libreoffice
Qui est un alias de :
guix package -i libreoffice
Attention : la première installation de paquet peut prendre du temps (et de la place !) car Guix va chercher toutes les dépendances nécessaires à toutes les dépendances du paquet vu qu’il ne va utiliser aucune dépendance installée sur le système.
Note : Vous verrez, certains paquets (ou correctifs) sont même compilés sur votre machine, mais dans l’ensemble, beaucoup de binaires précompilés (appelé substituts) sont disponibles (voir l’attribut builds dans la description des paquets).
Toutes les dépendances téléchargées se trouvent dans le dossier /gnu/store. Voici un petit bout de mon dossier :
$ ls --group-directories-first /gnu/store | less
01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15
023gvzf7gqbp61jfpc0674krwv7yiyza-mariadb-10.1.38
02iklp4swqs0ipxhg5x9b2shmj6b30h1-binutils-2.31.1
02k245xy33cvcnr8vm3lagm9zmb1s2wa-grep-3.1
03bgmiwcr3v5yh6psgh9dvg4qihb7qa0-xdg-desktop-database
03hd5wljl5yirh33czpi738ckq16zyp5-xdg-mime-database
04h27h0myyksngxx8imv416n4iwsiv8m-hunspell-1.7.0
04vqghzmpqzxpd94h1q931xpmazp5s7g-libgc-7.6.6
057dna3nwy84zdvfqss8vbgx1pzkdc2l-libungif-4.1.4
05zlxc7ckwflz56i6hmlngr86pmccam2-pcre-8.42
09x4p4ywz39xzy42kmscfi2nnhwjgybd-curl-7.64.0
0cnnj7kvggda2p12mlmxawz3ni9w5rwa-xcb-util-0.4.0
0fcp0xw1l1r2v42j4kdmn9ra3r7bd45v-gtk-im-modules
0fnyf3043x767xfm6gski5h1576q8wsn-glib-schemas
0h9x3hqqh4fx52735a7mykqm7mdkqnf4-libgc-7.6.6
0j6sz3bk4chqc8pgfv0fsn6byarwq4df-openldap-2.4.46
0j7xd8b63wv6hfssbacw28bj7rsbx0sk-packages
0ja63438w88gil4lxbpsgc5chmyiqhn6-openldap-2.4.46
0jif6gjzhxcg86q9qb7cjbcxdy8sacsn-python2-pygtk-2.24.0
0k450nckm9yp9vlbykvrb7pqp2njm3c4-libxv-1.0.11
0q9pq9flr76rh4bv2524niknknnl2kvq-glib-2.56.3
0r1ihh22jhbii0n3xa4isgscbrynydfr-module-import
0wqgmqnlpr8pzvx4skqdgczym8384fbb-shishi-1.0.2
Comme vous pouvez le voir, toutes les dépendances se trouvent ici. Et dans chaque dépendance se trouve une arborescence propre.
Par exemple :
$ tree -d /gnu/store/01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15/
/gnu/store/01xnzx1q3k9z3xmhly0fa5ki8hp8l99s-libmwaw-0.3.15/
|-- bin
|-- include
| `-- libmwaw-0.3
| `-- libmwaw
|-- lib
| `-- pkgconfig
`-- share
`-- doc
|-- libmwaw
| `-- html
`-- libmwaw-0.3.15Se trouve aussi maintenant dans mon répertoire personnel un dossier .guix-profile dont voici l’arborescence :
tree -L 1 /home/dede/.guix-profile
~/.guix-profile
|-- bin
|-- etc
|-- include
|-- lib
|-- libexec
|-- manifest
|-- sbin -> /gnu/store/8k4pnixpz73kxvxbjqajgbprjjmmgpxy-util-linux-2.32.1/sbin
`-- shareLe dossier bin contient des liens symboliques vers les binaires présents dans /gnu/store. On a ainsi un fonctionnement très flexible et je peux choisir très facilement à quelle version d’un logiciel attribuer tel ou tel alias.
Le fichier qui nous intéresse est manifest, il décrit toutes les versions des logiciels installés et où ils se trouvent :
(manifest
(version 3)
(packages
(("tree"
"1.8.0"
"out"
"/gnu/store/x5xb40q502s7pnqk9lmsnpc5vpsm1r8r-tree-1.8.0"
(propagated-inputs ())
(search-paths ())
(properties))
("recutils"
"1.8"
"out"
"/gnu/store/wzk023ls4f7dq4mcc3kc86vskhw804n1-recutils-1.8"
(propagated-inputs ())
(search-paths ())
(properties))
("emacs"
"26.2"
"out"
"/gnu/store/b38pn0gnj4jsrf79lg4kr80rn5kaim0q-emacs-26.2"
(propagated-inputs ())
(search-paths
[...]Utilisation des paquets
Pour utiliser les paquets installés par Guix, quand on est en ligne de commande, il suffit de rajouter le dossier bin à notre $PATH :
export PATH="/home/dede/.guix-profile/bin${PATH:+:}$PATH"Pour un usage serein, vous pouvez rajouter cette ligne à votre .bashrc si vous utilisez Bash ou .zshrc si vous êtes sous ZSH :
# Guix
# le fichier profile contient l’ajout de `bin` au `$PATH`
GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$HOME/.guix-profile/etc/profile"Maintenant, quand vous tapez par exemple libreoffice, c’est la version Guix qui se lance et non plus celle installée sur votre système via apt et cela, sans aucune interférence, si ce n’est les fichiers de configuration qui se trouvent dans votre HOME qui seront partagés.
Ici la version 6.1.5.2 de LibreOffice, alors que celle présente dans Xubuntu 18.04 est la 6.0.7. Dans ce cas‑là, Guix n’offre pas de paquet très à jour.
Avec un lanceur graphique
Si vous voulez que les lanceurs graphiques (les raccourcis dans le menu) lancent directement toutes vos applications Guix, vous n’avez qu’à modifier le fichier .xsessionrc en rajoutant la même ligne que dans votre .bashrc :
# Guix
# le fichier profile contient l’ajout de `bin` au `$PATH`
GUIX_PROFILE="$HOME/.guix-profile" ; \
source "$HOME/.guix-profile/etc/profile"Si toutefois vous souhaitez garder vos logiciels installés via apt et ne mettre à jour que quelques lanceurs, il est aussi possible de modifier les lanceurs graphiques en changeant simplement la commande d’exécution.
Exemple, avec LibreOffice Writer, avant j’avais :
libreoffice --writer %U
Et j’ai simplement mis ça à la place :
/home/dede/.guix-profile/bin/libreoffice --writer %U
Après m’être assuré que le paquet Guix fonctionnait bien, j’ai pu faire une désinstallation du paquet installé via apt :
sudo apt remove libreoffice
Je fais ça petit à petit avec tous les logiciels que j’utilise. Ça me permet en quelque sorte d’avoir une « rolling release » tout en gardant le système auquel je suis habitué. C’est une introduction tout en douceur à Guix :).
Désinstallation des paquets
Il est bien sûr possible de désinstaller un paquet très facilement via guix remove libreoffice, alias de guix package -r libreoffice.
Note : après un remove, Guix garde tout de même les fichiers dans /gnu/store mais supprime les liens symboliques dans votre guix-profile.
Pour faire une vraie suppression, il faut faire un guix gc qui supprime tous les paquets inutilisés. Mais après quelques tests, certains paquets supprimés restent quand même, je ne sais pas pourquoi.
Mise à jour des paquets
Pour mettre à jour tous les paquets en même temps, il suffit de taper guix upgrade ou guix package -u. Si je veux simplement mettre à jour LibreOffice, par exemple, je peux faire :
guix upgrade libreoffice
Rechercher un paquet
Pour rechercher un paquet, rien de plus simple, exemple avec libreoffice : guix search libreoffice, alias de guix package -s libreoffice.
Bon, ça renvoie souvent beaucoup de paquets, pas forcément en lien, donc on peut simplifier l’affichage avec un grep :
guix search libreoffice | grep -A 2 'name:' | less
Voir affiner la recherche avec :
guix search libreoffice | grep -A 2 'name: libreoffice' | less
Après je ne suis pas un pro des petits outils en ligne de commande qui se chaînent (je n’ai que les rudiments) et je suis sûr que des personnes plus douées que moi font des merveilles pour avoir une recherche plus aisée.
Bon, je ne vous conseille pas le site listant les paquets Guix, car il est tout bonnement inutilisable. Il ne contient même pas de formulaire de recherche…
Mettre à jour Guix
Vous pouvez aisément mettre à jour le logiciel Guix en tapant la commande suivante :
guix pull
Et si vous souhaitez connaître les dernières nouveautés ajoutées, vous pouvez faire un :
guix pull --news
Revenir en arrière suite à un problème
Avec Guix il est possible de revenir à n’importe quelle « génération » (c’est le nom donné à chaque changement dans l’installation) de paquets sans souci.
Je vais prendre un exemple concret, sous ma Xubuntu, j’ai git installé :
git --version
git version 2.17.1J’aimerais avoir une version plus récente, alors je fais un :
guix install gitJ’ai maintenant un git plus à jour :
git --version
git version 2.21.0Si pour une raison ou une autre je veux revenir en arrière, je peux faire un « rollback » :
guix package --roll-back
git --version
git version 2.17.1Ce qui est intéressant, c’est qu’en réalité, le logiciel reste présent dans le répertoire /gnu/store, il est seulement retiré du profil personnel. Cela rend la « navigation » dans les différentes générations très rapide et aisée.
Exécuter une application en mode « bac à sable »
Il est possible d’utiliser une application dans un espace isolé de l’environnement (appelé « container ») et ainsi protéger au maximum la distribution hôte.
Exemple avec Midnignt Commander où l’on peut voir que les répertoires système et autres répertoires personnels ne sont pas accessibles :
guix environment --ad-hoc --container mc
# Il faut définir la variable TERM
export TERM=xterm-256color
mcNote : en jouant un peu avec cette commande, je me rends compte que ce n’est pas très utilisable pour des applications graphiques, car le conteneur n’a même pas accès au serveur X, donc son usage est un peu limité.
Conclusion
Guix (tout comme Nix) offre une vision novatrice, sécurisée et extrêmement souple de la gestion de paquets. L’installer sur une distribution hôte est très aisé et sans risque. C’est une expérience intéressante pour qui souhaite découvrir cet outil et accessoirement mettre à jour certains paquets.
Si vous avez plus de questions, je vous invite à lire la FAQ ci‑dessous.
FAQ
Pour quoi faire ?
Les PPA c’est pas plus simple ?
Et Snap ?
Snap est un gestionnaire de paquets qui se veut universel, mais qui pour l’instant est porté exclusivement par Canonical. Il offre des caractéristiques assez similaires à Flatpak mais permet aussi d’installer des logiciels sans nécessiter de pile graphique (ce qui n’est pas le cas de Flatpak à ma connaissance).
Comme vu plus haut, Guix peut aussi avoir une exécution en mode bac à sable, avec sans doute moins de granularité possible sur les autorisations. Après, sans vouloir troller, Snap semble avant tout fait pour introduire des logiciels tiers (entendez par la provenant d’entreprises et n’étant pas audités par la communauté) dans la logithèque Ubuntu. Son slogan « _The app store for Linux » » en dit long…
Je ne connais pas cet outil, mais, personnellement, je préfère faire confiance aux serveurs de paquets et à la communauté qui les construit qu’en un logiciel qui me permet d’exécuter des applications en lesquelles je n’ai pas confiance en mode « bac à sable » et me demandant des autorisations que j’accorderai forcément… Puis ça crée des disques virtuels et je n’aime pas ça.
Et Flatpak ?
Je ne peux que vous conseiller la lecture de l’excellente dépêche de nokomprendo qui compare Nix (logiciel très similaire à Guix) et Flatpak. Pour moi, Nix ou Guix sont plus intéressants que Flatpak.
Et Nix alors ?
D’un point de vue pragmatique, Nix est plus abouti (plus ancien) et bénéficie d’une beaucoup plus grosse communauté et donc d’un nombre plus important de paquets, qui sont sans doute plus à jour. Guix et Nix étant très proches dans leur fonctionnement, on est en droit se demander quel est l’intérêt de Guix.
Nous tâcherons d’écrire une dépêche spécifiquement sur ce sujet, mais on peut déjà noter quelques spécificités de Guix par rapport à Nix qui rendent le projet attrayant et non redondant selon nous :
- Guix est un projet GNU et Guix System est une distribution basée exclusivement sur du code libre, cet aspect est très important chez les contributeurs Guix ;
- un énorme effort est fait pour rendre la distribution bootstrapable (désolé pour l’anglicisme) et ainsi pouvoir compiler l’ensemble des sources (même gcc) à partir d’un unique binaire très léger dont le code assembleur est lisible, ceci afin d’éviter les attaques dites de « trusting trust » ;
- dans un but similaire, l’équipe de Guix cherche à avoir des builds reproductibles, c’est‑à‑dire avoir des binaires identiques pour une même entrée (mêmes sources et même fichier de configuration), ceci afin de pouvoir s’assurer que les binaires générés en local sont bien les mêmes que ceux proposés par le serveur, par exemple ;
- Guix utilise GNU Shepherd à la place de systemd ;
- Guix utilise pour la définition de ses paquets et la configuration du système le langage d’extension Guile ; à la différence du langage utilisé par Nix (Nix Expression Langugage), Guile est un langage généraliste s’interfaçant facilement avec des librairies C et étant utilisé dans (quelques) autres projets GNU, comme Shepherd par exemple — à noter qu’ils sont tous les deux des langages fonctionnels.
Installer des paquets sans droits administrateur c’est pas un peu dangereux ?
Non, pas vraiment. Le seul risque est qu’un utilisateur disposant des droits pour installer un paquet via le démon Guix pourra donc installer autant de logiciels qu’il veut et potentiellement remplir le disque dur. J’invite le lecteur à lire cet échange pour plus d’informations.
Aller plus loin
- Site officiel du projet Guix (87 clics)
- Manuel de référence (37 clics)
- Dépêche annonçant la version 1.0 de Guix (33 clics)
- 1ʳᵉ dépêche de cette série sur Guix (35 clics)
# curl … | sudo bash
Posté par vv222 (site web personnel) . Évalué à 10.
Sérieusement ?! Jamais !!
C’est dommage d’ajouter ça dans la dépêche alors que ce n’est pas issu des instructions officielles, contrairement à ce que laisse penser la formulation autour de cette instruction.
[^] # Re: curl … | sudo bash
Posté par Andréas Livet . Évalué à 2.
Citation de la page d'installation officielle :
Ce que fais ma commande télécharge ce script et l'exécute en tant que super utilisateur, c'est ce qui est conseillé non ?
Si par hasard, je me suis trompé ou que vous voyez une méthode plus sécurisée pour faire cela (je ne suis vraiment pas un pro de la sécurité), je veux bien que vous postiez la bonne méthode et on demandera une correction de la dépêche.
Merci
[^] # Re: curl … | sudo bash
Posté par vv222 (site web personnel) . Évalué à 8.
La différence c’est que la commande que tu proposes supprime une étape importante : la vérification du contenu du script, entre son téléchargement et son exécution.
Je n’aurais pas réagi de la même façon si le résumé des instructions avait été :
Même si l’étape de vérification du script n’est pas explicitement citée avec ces deux commandes, elle n’est plus rendue impossible.
Pour bien comprendre le coup de gueule, il faut savoir que de plus en plus de projets "modernes" donnent comme instructions d’installations officielles des variantes autour de ce
curl … | sudo bash, à tel point que cette méthode se banalise et n’est plus considérée comme problématique.C’est d’ailleurs à mon avis une des raisons pour lesquelles aucun des relecteurs de cette dépêche n’a vu de souci avec cette commande.
Alors qu’on parle bien d’exécuter sur notre système avec les accès maximum un script parfaitement inconnu. Sans même un rapide coup d’œil sur ledit script.
Bref, je râle contre cette dépêche parce qu’elle me propose un espace pour m’exprimer, mais le coup de gueule est bien plus global ;)
[^] # Re: curl … | sudo bash
Posté par freem . Évalué à 3.
Du coup, ne serait-il pas intéressant d'avoir une 1ère vérification par checksum, rien que pour réduire le risque?
Accessoirement, à moins qu'il n'installe dans /usr ou pire dans la racine, sous Debian, utiliser un utilisateur appartenant au groupe
staffpermets d'écrire dans /usr/local, lieu de prédilection pour faire du./configure && make && make install.Pour Voidlinux, le groupe
wheelsemble remplacerstaff, pour les autres "distro mères" type gentoo, arch, ou RHEL, je ne sais pas.Installer dans
/usr/localen tant queuser:staffpose aussi des problèmes de sécurité, notamment j'ai découvert a mon grand dam que le$PATHdes scripts d'init de debian mets les dossiers/usr/local/avant(/usr)?/s?bin, ce qui m'a pété un boot (d'une vm, certes) quand j'ai utilisé un script pour mettre les binaires fournis par busybox dans /usr/local.N'empêche, ça reste moins dur a réparer, et ça évite un exécutable troué installé en
root:root+ suid.Bref, même si ça reste troué (rien ne l'est pas, sauf peut-être un hello world compilé en static?), utiliser un groupe adapté permets de réduire les emmerdes. Et si le script ne marche pas dans ce cas, alors c'est peut-être un bug. Surtout quand on parle d'un outil qui est capable d'installer des paquets pour un user sans accès root.
[^] # Re: curl … | sudo bash
Posté par vv222 (site web personnel) . Évalué à 3.
Là à mon avis on commence à aller un peu loin pour le résumé des instructions dans la dépêche.
Tant que la possibilité de vérification du script est possible, à chacun de faire ça comme il le souhaite. Sachant que quelqu’un de pointilleux sera probablement allé lire les instructions officielles détaillées données en lien.
À partir du moment où cette dépêche ne participera plus à la banalisation de
curl … | sudo bash, je n’aurai plus de reproches à faire au résumé de la méthode d’installation ;)[^] # Re: curl … | sudo bash
Posté par barmic 🦦 . Évalué à 1.
C'est donc une question de principe plus qu'autre chose. On a beaucoup dis que
curl … | sh -c'est mal donc, il ne fait pas l'écrire, même si ce ne sont que des circonvolutions autour ?Si le problème c'est de faire la vérification ça ne coûte rien de mettre un :
Soit la question de la vérification est importante et on la met en évidence, soit OSEF.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: curl … | sudo bash
Posté par barmic 🦦 . Évalué à 1.
C'est largement plus compliqué que ça. Si un projet ne te file pas de moyen de vérifier les binaires qu'il te file, un
curl | shou unplouf.<extension_de_paquet_de_ta_distribution_préféré>sera pareil (sauf si ta distribution refuse d'installer des paquets non signés, ce qui n'est pas le cas de Debian, ses dérivées ni d'arch si je ne m'abuse).Bref oui ça pose un problème de sécurité, mais non ça n'est pas une question de commande.
Ici en l'occurrence le projet upstream propose quelque chose qui a l'air propre c'est dommage de l'outrepasser.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: curl … | sudo bash
Posté par Andréas Livet . Évalué à 2.
Je ne comprends pas cette phrase, à quoi faites vous référence ? Comme je l'ai dis dans un commentaire précédent, le projet conseille justement une installation en root via le script mentionné dans l'article, donc en quoi est-ce plus propre ?
[^] # Re: curl … | sudo bash
Posté par barmic 🦦 . Évalué à 1.
Le projet demande à vérifier la signature gpg du fichier que tu as téléchargé. C'est le truc dont on parle.
À noter que ça fait partie de leur procédure de téléchargement. C'est pas une option mise dans un coin comme beaucoup d'autres projets.
Ils sont vraiment propre sur la sécurité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: curl … | sudo bash
Posté par Andréas Livet . Évalué à 1.
Je crois qu'il y a confusion entre ce que fait le script d'installation (en effet, il vérifie la signature gpg du binaire) et les instructions pour lancer ce script.
Cette page d'installation ne précise pas comment télécharger ou vérifier le script d'installation, juste de le lancer en root.
[^] # Re: curl … | sudo bash
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 23 mars 2020 à 10:48.
En effet je me suis laissé avoir par le fait que la solution recommandée n'est qu'un petit encart dans la page que tu pointe. Je trouve vraiment bizarre comme façon de le présenter…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: curl … | sudo bash
Posté par Andréas Livet . Évalué à 2.
Je trouve ça bizarre aussi de mettre juste un petit encart concernant la méthode conseillée et de détaillé longuement ce que fait le script sans que l'utilisateur doivent lui même le faire… Il faudrait selon moi une documentation à part pour cela.
[^] # Re: curl … | sudo bash
Posté par Andréas Livet . Évalué à 2.
J'avoue avoir un peu succombé à cette "mode" car je trouve pratique le fait de pouvoir installer un logiciel en une ligne et sans forcément avoir le fichier d'installation sur son disque après.
Avant, je faisais exactement comme tu l'as montré mais comme je ne faisais pas plus de vérifications de ça, j'ai trouvé que ça revenait au même de passer par des pipes.
[^] # Re: curl … | sudo bash
Posté par seveso . Évalué à 5.
Pas exactement malheureusement. Dans le cas d'un
curl ... | bash, le script peut commencer à être exécuté par bash avant même qu'il ait fini d'être téléchargé par curl. Et ce comportement peut être détecté côté serveur. Et si l'admin du serveur était malveillant, il pourrait faire en sorte que ces 2 commandes se comportent différemment.et
Une démonstration a été faite il y a quelques années sur ce blog :
https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/
Il fournit un script python facile à tester pour se faire peur.
À mon sens c'est une raison suffisante pour arrêter de propager cette mauvaise habitude du
curl ... | bash.[^] # Re: curl … | sudo bash
Posté par barmic 🦦 . Évalué à 1.
Vu qu'il a la main sur un script que tu va exécuter avec les droits root et qu'il n'existe aucun moyen officiel de vérifier ce dis script, pourquoi est-ce qu'il ferrait quelque chose d'aussi complexe alors qu'il suffit de pourrir le script une bonne fois pour toute.
Tant qu'il n'y a pas de validation du script l'un ou l'autre c'est précisément les même dégâts. Note que tu parle de lancer un script qui vient d'un serveur d'on l'admin est malveillant en tant que root. Qu'il détecte tout ce qu'il veut tu as déjà perdu.
Note que ta revue du script est loin d'être suffisante pour parer à une attaque (sans présumer de tes compétences).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: curl … | sudo bash
Posté par Andréas Livet . Évalué à 2.
Merci pour cet apport. Je n'avais jamais pensé à cette problématique.
C'est donc une raison suffisante pour ne pas proposer la solution avec les pipes en effet.
Est-ce que donc la méthode en 2 temps, vous parait ok ? Si c'est le cas, on pourrait modifier la dépêche dans ce sens ?
[^] # Re: curl … | sudo bash
Posté par Benoît Sibaud (site web personnel) . Évalué à 6. Dernière modification le 22 mars 2020 à 21:11.
J'ai retiré la partie
curl https://…|sudo bashvu que le script d'installation du projet fait les choses bien mieux d'un point de vue sécurité, et parce qu'effectivement ça reste une mauvaise pratique à ne pas diffuser.(et merci à l'auteur pour la dépêche en général)
# snap et faltpak : on nous ment sur la marchandise
Posté par mothsART . Évalué à 7. Dernière modification le 21 mars 2020 à 21:46.
Tout d'abord, merci de cet article.
Il n'y a quasiment aucun article francophone sur le sujet donc rien que pour ça, ça nécessite d'être souligné !
Connaissant Nix, je vois bien entendu beaucoup de similitudes.
/gnu/store au lieu de /nix/store mais même principe : des noms de paquet avec des hash.
Même constat que pour Nix : pourquoi diable avoir mis les hash avant les noms…
Pour ce qui est Snap et FlatPak : c'est très orienté user avec des outils graphiques mais dès qu'on regarde un peu de plus prêt… la magie n'opère plus.
Je pense avoir un peu de recul sur la création de paquets : j'ai déjà fait moultes paquets debian, un peu d'archlinux, des paquets Python, Rust et depuis peu Nix et j'ai trouvé (il y a un peu plus d'un an) les tutos et la doc de Snap et Flatpak totalement ridicules.
Dès qu'on sort du hello world avec plus de 2/3 dépendances, ça devient très compliqué à empaqueter et à maintenir.
J'estimes que dans la communauté Linux (tout du moins je l'espère), la qualité technique, la facilité des outils de création, la doc et l'aide ont souvent tout autant voir plus d'importance que l'outil final.
Cqfd : si personne n'est emballé pour empaqueter, le store au final restera vide.
Perso, je préfère engager du temps sur des projets comme apt/nix (guix, je découvre donc j'ai pas encore d'avis) plutôt que perdre mon temps avec snap/flatpak/appimage.
Pour ton comparatif Guix/Nix, 3 points non techniques et totalement subjectifs :
- Le nom Guix est sans doute mieux choisi que Nix car y'a pas d'embrouille pour les moteurs de recherche : point pour Guix.
- Le logo de Nix est une pure merveille d'ingéniosité : des lambdas qui forment un flocon de neige alors que Guix, je cherche toujours (une tête de gnou probablement) : point pour Nix
- les moteurs de recherche web des paquets : point pour Nix même si lent (la requète ajax qui rappatri un gros json avec tous les paquets est juste horrible)
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par Graveen . Évalué à 5.
Qu'en est il de l'espace disque utilisé ? Par rapport à apt par exemple ?
Sur mon SSD 256Go je voudrais bien tester (= faire la substitution comme l'auteur) mais j'ai peur du différentiel de place.
Parce que j'imagine qu'apt se base sur la distribution pour les dépendances (mutualisées).
Et que la structure même de Nix/Guix font qu'ils utilisent de nouvelles lib.
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par mothsART . Évalué à 1.
Alors, j'ai fait la même opération que l'auteur mais avec Nix et j'en suis actuellement à 7.3G (du -sh /nix/store) avec la dernière version de gimp, inkscape, geany, guake, une quinzaine de petits utilitaires et sans doute une bonne cinquantaine de doublons lié aux paquets que j'ai empaqueté.
Je pense, le mieux pour te faire une idée est déjà de faire l'install minimal et de surveiller paquet par paquet.
Tout est mis dans /nix/store (ou /gnu/store si tu pars sur guix) et il t'es donc facile de surveiller l'évolution.
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par Andréas Livet . Évalué à 1.
Je pense que le dossier
storeest plus lourd que les dépendances gérées par apt du fait de la non mutualisation de certaines dépendances.Chez moi, mon répertoire
/gnu/storefait 10.7Go avec quelques "gros" logiciels installés comme scribus et libreoffice entre autre.[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par Andréas Livet . Évalué à 3.
Merci pour le commentaire.
J'ai vu sur une vidéo, un des dev Guix a sans doute une modif dans son bash.rc ou autre qui supprime les hash avant les noms, beaucoup plus lisible !
C'est vrai que c'est pas très commode pour le tri alphabétique et pour la lecture des noms de paquets… la raison est sans doute pragmatique : le hash fait toujours la même taille, le logiciel récupère les premiers caractères du dossier et sait ainsi à quel paquet il a affaire. Dans l'autre sens c'est plus difficile de récupérer le hash.
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 22 mars 2020 à 22:26.
Si tu mets le hash à la fin, donc après le numéro de version ici, tu peux lire de droite à gauche les noms. Ainsi tu sais qu'il faut partir de la fin du nom de fichier et remonter de x caractères pour retrouver le hash.
C'est beaucoup plus propre pour les utilisateurs et je pense que ça ne devrait pas trop impacter les performances.
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par Andréas Livet . Évalué à 1.
Oui c'est vrai avec un hash a taille fixe c'est la même en fait…
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par Andréas Livet . Évalué à 1. Dernière modification le 22 mars 2020 à 14:56.
Je suis de ton avis, j'ai vraiment du mal à comprendre cet engouement autour de snap et flatpak, ce que je vois c'est que les projets galèrent à créer des paquets sur ce genre de technologies. Je mettrai peut-être AppImage à part vu qu'il s'agit d'un format qui embarque tous les dépendances et donc plutôt axé portabilité et diffusion "rapide", contrairement aux deux autres qui se placent comme des gestionnaires de paquets universels et sécurisés.
Pour moi, Guix (ou Nix) sont bien plus universels et sécurisés que snap ou flatpak, mais bon je ne suis pas du tout spécialiste.
C'est pas faux, par contre il y a très peu de ressources sur Guix…
Les goûts et les couleurs… perso je vois pas trop en quoi le logo de Nix est si génial, je le trouve plutôt banal, mais je n'avais pas compris que c'était des lambdas :). Je trouve celui de Guix assez rafraîchissant pour un logo Gnu.
Non mais c'est clair que c'est assez honteux, même l'outil de gestion de projet (savannah) est assez "archaïque" pour les personnes habituées à la méthode GitHub/GitLab…
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par roptat . Évalué à 1.
Côté guix, il y a https://hpc.guix.info/browse qui n'est pas sur le site officiel, mais qui est à jour aussi
# Disques virtuels snap
Posté par contra-sh . Évalué à 6.
Ah ! Content de te l'entendre dire, moi aussi ca me perturbe beaucoup…
Et merci pour cette depeche :)
# Utiliser Guix en arm
Posté par Tjiho . Évalué à 1.
Merci pour cette dépêche. Ça me titille, j'ai vraiment envie d'essayer. Malheureusement je n'ai sous la main que mon pc professionnel et une Raspberry pi 2.
Ma Raspberry manque de certains paquets et ce serait un excellent cobaye. Existe t'il des dépôts compatible ARM ? A moins que les paquets soit compilés sur la machine, mais ça peut prendre du temps sur une Raspberry…
[^] # Re: Utiliser Guix en arm
Posté par Andréas Livet . Évalué à 1.
Pour l'instant il n'y a pas de version officielle de Guix pour ARM.
Après, certains s'amusent à porter la distribution sur ARM mais cela nécessite un gros effort et faut donc avoir beaucoup de temps (et des petites compétences en Scheme) je pense. En ces temps de confinement c'est jouable sans enfant :D !
[^] # Re: Utiliser Guix en arm
Posté par roptat . Évalué à 1.
En fait si, si tu utilises Guix sur une distribution externe, tu peux suivre la procédure d'installation officielle. Les architectures actuellement prises en charge sont i686, x86_64, armv7 et aarch64 (armv8). Le raspi a des problèmes liés aux pilotes graphiques (et au chargeur d'amorçage si je comprends bien) qui ne sont pas libres, ce qui en fait une très mauvaise cible pour le système Guix. Installer guix à côté d'une distribution existante serait plus sage. Ou alors, tu peux utiliser le dépôt non officiel nonguix pour avoir les pilotes non libres, mais ça nécessite la compilation du noyau (guix le fait tout seul, c'est juste très long).
# Question bête
Posté par Bruce Le Nain (site web personnel) . Évalué à 2.
Est-ce que Guix peut être compilé avec LLVM/Clang?
[^] # Re: Question bête
Posté par Andréas Livet . Évalué à 4.
Réponse courte : Non.
Réponse longue : A part le fait que Guix soit un projet Gnu (et donc a priori pas trop enclin à utiliser LLVM), les développeur de Guix sont en train de réaliser la prouesse - qui a ma connaissance n'a encore jamais été faite pour une distribution, de pouvoir compliler Guix uniquement à partir de source.
Un article du blog explique cette démarche et une vidéo du FOSDEM.
C'est vraiment passionnant ! En gros, ils ont codé un petit compilateur en assembleur qui est capable de compiler Gnu Mes qui est un mini compilateur C et interpréteur Scheme permettant ensuite de compiler une ancienne version de GCC et lire les scripts Scheme, qui permet ensuite de compiler d'autres versions de GCC et ainsi démarrer (bootstraper en franglais) la compilation de la distro.
Il y a donc une grosse dépendance à tout l'outillage GCC et je ne pense pas que cet effort soit reproduit pour LLVM…
# Quid de la portabilite de Guix et des paquets?
Posté par gurumekun . Évalué à 1.
Important, est-ce que Guix marche sous:
- Mac OS X
- FreeBSD
- NetBSD
- OpenBSD
[^] # Re: Quid de la portabilite de Guix et des paquets?
Posté par roptat . Évalué à 1.
Pas encore, mais à part pour Mac OS, il n'y a pas de raison que ça ne puisse pas fonctionner, ça demande "juste" beaucoup d'efforts. Actuellement il semblerait que certains développeurs soient motivés par le Hurd, donc on aura peut-être ça bientôt :)
# Et Arch Linux ?
Posté par Jeff . Évalué à -1.
Remarque : sur Arch Linux les paquets sont à jour. Pour LibreOffice par exemple j'ai la version 6.3.5.2. Donc cette solution c'est pour les autres distributions ? Quel serait l'intérêt d'utiliser Guix sur Arch Linux ?
[^] # Re: Et Arch Linux ?
Posté par Faya . Évalué à 7.
[^] # Re: Et Arch Linux ?
Posté par Andréas Livet . Évalué à 1.
Arch est en effet très à jour donc l'apport de Guix sera totalement négligeable de ce côté là. Nix bénéficie quant à lui de beaucoup plus de paquets et souvent bien à jour.
L'intérêt peut se trouver dans l'utilisation des environnements virtuels si tu fais du dev par exemple. Je pense écrire un article sur ce sujet prochainement.
Après, sans vouloir rentrer dans un débat stérile, j'aime beaucoup l'idée de distribution à intégration continue (et oui je me sers des traductions du wiki que je ne connaissais pas, merci barmic) et c'est ce qui me plaisait dans Arch.
Mais, j'ai vu plusieurs fois un de mes collègues passer parfois des heures entières à tenter de réparer des configs de sa machine qui ne fonctionnait plus après une mise à jour. Et pourtant, c'était un vétéran de Linux !
Pour moi, Nix (puis par la suite Guix) à proposer un concept vraiment novateur et rend possible le fait d'avoir une distribution à intégration continue fiable ou facile à gérer en cas de pépins.
Théoriquement, je trouve donc ces 2 distributions supérieures à Arch. Dans la pratique Arch a sans doute une plus grosse communauté, donc plus facile de trouver des ressources de l'aide, etc.
Après, c'est aussi la curiosité de découvrir un fonctionnement de distribution tout autre.
# trusting trust
Posté par barmic 🦦 . Évalué à 1. Dernière modification le 23 mars 2020 à 10:54.
Le code assembleur lisible avec quoi est-ce qu'on le lit ?
Sinon amorçable c'est bien, si tu ne voulais pas faire d'anglicisme (il y avait déjà boot dans les traductions classiques j'ai ajouté bootstrap si c'est utile).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: trusting trust
Posté par Andréas Livet . Évalué à 1.
Bah tu le lis sur une autre distribution. Je pense qu'on peut quand même faire confiance dans le fait qu'un éditeur de texte, même compilé sur une distribution non amorçable, reste fiable dans sa manière de retranscrire du texte à l'écran :).
Après, ce n'était peut-être pas le sens de ta remarque ?
Merci, je l'avais sur le bout
de la languedes doigts ![^] # Re: trusting trust
Posté par barmic 🦦 . Évalué à 1.
L'objectif du trusting trust c'est de ne pas accorder sa confiance, donc la donner comme ça a un quelconque éditeur de texte et à un assembleur (le logiciel qui compile ton code ascii/unicode en binaire) et une limite forte. D'autant que ça leur met une pression particulière.
Tu aura compris autant je trouve l'exercice intéressant, autant c'est une façon très très obtus de comprendre la conférence de Ken Thompson. D'autant qu'une fois que tu as fait tout ça tu n'a pas vérifier le matériel (le CPU, mais pas que).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: trusting trust
Posté par Andréas Livet . Évalué à 1.
J'avoue ne pas avoir lu/vu la conférence de Ken Thomson, mais je crois que faire confiance à son éditeur de texte c'est pas trop fou tout de même, surtout qu'on peut le lire sur plusieurs distro avec plusieurs outils différents, donc ça augmente grandement la confiance que l'on peut accorder au contenu du fichier texte.
Pour l'assembleur, je n'ai pas creusé assez mais peut-être ont-ils codé aussi leur assembleur ?
Pour ce qui est du matériel, je dirai que c'est un autre sujet qui ne concerne pas la distribution. Eux ils font leur part, ensuite c'est aux personnes à qui appartient le matériel sur lequel la distribution est compilée de faire le travail de vérification de son matériel.
[^] # Re: trusting trust
Posté par barmic 🦦 . Évalué à 1.
Tout comme il existe plusieurs compilateurs C, si tu désactive les optimisation et que le code produit est équivalent avec gcc, clang, tcc et icc est-ce que ça n'est pas suffisant du coup ? Voir plus intéressant et utile pour l'utilisateur final ?
Reste qu'il faut le valider.
Tout comme faire l'amorce d'un compilateur n'est pas le boulot d'une distribution, mais d'un compilateur.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: trusting trust
Posté par Andréas Livet . Évalué à 1.
Je n'avais pas vu ce commentaire :
C'est pas faux et justement c'est ce qu'ils font avec Mes qui est un projet à part. Il faudrait plutôt dire alors que les développeurs de Guix s'intéresse aussi au trusting trust et développe à côté des solutions qui vont dans ce sens ?
[^] # Re: trusting trust
Posté par yabb85 . Évalué à 0.
Heu je ne sais pas si c'est moi qui déconne, mais tu choisis pas ton langage assembleur. C'est la machine sur laquelle tu es qui définit ce que tu dois utiliser.
Ensuite pour relire l'assembleur effectivement, je ne vois pas le souci car même pour lire un script il faut un outil (soit faire confiance à cat soit un éditeur).
J'ai l'impression d'avoir loupé des subtilités.
[^] # Re: trusting trust
Posté par barmic 🦦 . Évalué à 1.
Tu confond le langage assembleur (défini par une architecture matériel) et le logiciel assembleur qui prends une représentation textuelle du langage d'assemblage et en produit un binaire. On parle ici de logiciels comme nasm ou yasm par exemple.
Trusting trust tel que pris par les puriste. Consiste en un modèle d'attaque assez large qui prendrait pour cible ce en quoi tu as confiance avant la cible finale. C'est pour cela qu'ils veulent pas faire confiance à un compilateur au cas où le compilateur serais lui-même corrompu. Mon point c'est que c'est un modèle d'attaque qui n'est que théorique parce qu'extrêmement compliqué et de mettre en évidence aux jusque boutistes que c'est impossible avec des architectures modernes et la complexité mise en branle. Parce qu'on en revient toujours à 2 points :
C'est pas un travaille inintéressant. C'est même assez important mais faut d'après moi, le prendre comme un travaille de recherche en informatique plus que comme un travaille de sécurité.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: trusting trust
Posté par Andréas Livet . Évalué à 1.
Je rejoins ton avis barmic sur cette problématique de la confiance.
Tout à fait d'accord avec toi aussi, c'est pour ça que je dis bien dans mes articles que Guix est assez orienté recherche en informatique et est sans aucun doute moins grand public que Nix à qui il a emprunté les grands concepts.
# MAJ de bibliothèques et dépendances systèmes
Posté par Vincent Danjean . Évalué à 3.
Je suis curieux de savoir comment Guix/nix gère les transitions de bibliothèques.
Debian a tout un ensemble de procédures pour gérer cela et relancer la construction des paquets binaires quand cela est nécessaire (sans toucher aux paquets sources), mais ça reste lourd et il y a souvent quelques patches à faire. Avec Guix/nix, c'est l'utilisateur qui décide des versions de ses logiciels : comment lui assure-t'on que c'est cohérent globalement ? Comment gère-t-on ces patches pour toutes les combinaisons possibles ?
Autrement dit, comment Guix/nix assure-t-il l'intégration globale de tous les logiciels choisis si c'est l'utilisateur qui choisi les versions qu'il souhaite ? (pour moi, l'intégration globale, ie le fait que tout marche bien tout ensemble) est la grosse force d'une distribution linux)
Et comment Guix/nix gère-t-il les dépendances vers les composants unique du système/de la session (systemd, pulseaudio, dbus, …) ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.