Du coup on lie les applis à un gestionnaire de paquet ... ça me
paraît un peu douteuse comme approche.
Sinon, il y a packagekit, qui faisait exactement ça. Mais de toute façon, les applis vont être liés au nommage des paquets d'une façon ou d'une autre, et les efforts d'uniformisation avant d'avoir le code, ça ne marche pas.
Ensuite, il y a pas trop de choix. Soit tu fais un truc qui valide l'approche pour 1 gestionnaire de paquet avant d'essayer de convaincre le reste du monde (ce qui est fait en ce moment), soit tu fait un truc qui a pour vocation d'aller partout (et je pense que vu la violence des réactions sur systemd, personne ne va tenter ça), soit tu fais rien.
Si l'approche est bonne et apporte un plus pour la distribution, le code est libre, quelqu'un de motivé l'adapteras.
Puis pour ce qui est de réduire la surface d'attaque ... un
demon qui tourne en permanence c peut-être pas une bonne idée.
Par rapport à un demon qui va se lancer à la demande ? Par rapport à ne pas avoir de demon, donc lancer un shell complet avec des droits étendus au lieu d'un logiciel qu'on peut confiner un peu plus ?
La surface d'attaque, elle va pas venir du fait que ça tourne tout le temps, mais des possibilités d'interactions. Et je pense que remplacer un shell root par un demon, c'est une bonne base pour permettre plus de sécurisation.
[^] # Re: Lorsque je lis l'article ...
Posté par Misc (site web personnel) . En réponse au lien DNF => MicroDNF. Évalué à 2.
Sinon, il y a packagekit, qui faisait exactement ça. Mais de toute façon, les applis vont être liés au nommage des paquets d'une façon ou d'une autre, et les efforts d'uniformisation avant d'avoir le code, ça ne marche pas.
Ensuite, il y a pas trop de choix. Soit tu fais un truc qui valide l'approche pour 1 gestionnaire de paquet avant d'essayer de convaincre le reste du monde (ce qui est fait en ce moment), soit tu fait un truc qui a pour vocation d'aller partout (et je pense que vu la violence des réactions sur systemd, personne ne va tenter ça), soit tu fais rien.
Si l'approche est bonne et apporte un plus pour la distribution, le code est libre, quelqu'un de motivé l'adapteras.
Par rapport à un demon qui va se lancer à la demande ? Par rapport à ne pas avoir de demon, donc lancer un shell complet avec des droits étendus au lieu d'un logiciel qu'on peut confiner un peu plus ?
La surface d'attaque, elle va pas venir du fait que ça tourne tout le temps, mais des possibilités d'interactions. Et je pense que remplacer un shell root par un demon, c'est une bonne base pour permettre plus de sécurisation.