oula la grosse bétise que j’ai dite.
Pas plus tard qu’il y a récemment, j’ai cherché à installer OpenVino pour Audacity.
Et c’est via snap, et ça m’a bien fait ch.
Donc je me suis tourné vers un W11 …
Tu peux développer ? je comprends pas où tu veux en venir
flatpak le permet : flatpak install flathub --user com.discordapp.Discord
à voir pour snap et pas trop de questions à se poser pour appimages
De mon utilisation très limité, je me limite aux dépôts debian sans mélange de version. si besoin, je regarde si le développeur fournit et maintient correctement un paquet sous snap, flatpak ou appimage.
j’ai un nextcloud qui tourne sur un rpi depuis une éternité et j’ai rarement eu des problèmes mais des limitations liées à snap.
pour moi c’est la confiance dans la source qui compte. un vieux paquet sous debian plus maintenu n’est pas un gage de sécurité et il suffit de lire la section concernant les navigateurs, en gros c’est firefox esr ou chromium, le reste c’est maintenu comme possible mais c’est pas prioritaire pour les patchs de sécurité alors qu’on en trouve beaucoup de mon point de vue.
Je dirai, dans la mesure du possible, évite autant que possible sinon pose toi la question des alternatives sous debian. Si Flatpak est maintenu sérieusement par le projet, je tolère.
Que le snap inclut des librairies, des exécutables, et des paramétrages qui pourraient ne pas être fiables (vulnérables) et passer à travers les mesures déjà prises sur une machine. C’est d’ailleurs un poitn commun avec Flatpak, Appimage, et les conteneurs en général. D’autant que chaque paquet amènera ses propres bagages il peut y avoir duplication des mêmes bagages, avec donc la multiplication des vulnérabilités.
C’est à mon sens le point le plus critique dans l’utilisation de ces paquets.
D’autant que le Snap Store a déjà eu des cas de malwares et de violations de confiance (par exemple 2048Ubuntu, Hextris).
Car n’importe qui peut publier dans le Store.
Si la qualité des contrôles par les équipes Debian des paquets dans leurs dépôts est certaines, je pense pas que le niveau de qualité soit le même dans les snaps ou les appimages.
Déjà avec Docker il faut dégrader la configuration AppArmor par exemple pour crun et runc.
Sans compter que les mises à jour automatiques ne peuvent pas désactivées, ou facilement désactivées, il est donc facile de pouvoir contaminer une installation.
Les utilisateurs averti peuvent prendre en compte des pratiques permettant d’éviter ou de limiter ces problèmes, mais ils ne représente que 2 ou 3% des utilisateurs.
D’où ma suppression de SNAP et Flatpak et autres trucs du genre sur toutes les installations que je fais.
Ok donc si je comprend bien le snap ou le flatpak de firefox officiel est moins sécurisé que le paquet proposé dans le dépôt officiel et mérite moins de confiance ?
Le problème n’est pas que snapstore ou flathub est plus ou moins sécure, c’est une question de confiance en la/les personnes qui distribue …
J’avais bien plus confiance dans les paquets provenant de François 
que la pluspart des snap ou flatpack mais ça reste personnel.
Maintenant ou on fait le choix d’avoir des logiciels pas forcément de première fraîcheur soit on doit passer du temps à étudier et valider les paquets (peu importe leur provenance) en faisant confiance à toute la chaine qui le distribue.
On ne m’enlèvera pas qu’un paquet officiel distribué par une fondation ou une association/entreprise peu être considéré comme de confiance et le fait de pouvoir le maintenir à jour par une simple commande voir automatisé par un unattended-upgrade est un très gros plus.
Je n’ai clairement pas envie de perdre du temps à maintenir un poste de travail en étudiant l’ensemble des paquets installé dessus, si je ne suis plus sur le canal unstable c’est pas pour rien.
Mais je n’ai pas non plus envie d’utiliser des paquets du type firefox-esr.
La question peu (mais ne creusons pas non plus cette direction par pitié) se transposer sur le catalogue d’applications disponible sur Android, Apple etc …
Pour quelle raison stp ?
Pas envie d’être emmerder avec des soucis de comptabilité sur la partie webassembly comme déjà rencontré avec des sites de clients, idem sur la gestion du css nettement amélioré sur les version à jour du dépôt Mozilla.
Idem une extension maison de ma boîte requiert une version à jour de firefox pour fonctionner et j’ai eu des soucis avec SwitchOmega … réglé en ayant installé une mise à jour de la version récente.
Je rajouterai étant un utilisateur de Brave tous les jours bah … pas de paquet dans les répo de Debian, donc obligé de passer soit par un dépôt tiers (donc à faire confiance) soit par un snap/flatpak.
Même en passant par les dépôts extrepo ?
(je demande car je sais très bien qu’au-travers de ce dépôt, 2 ou 3 versions de Brave sont fournies ; sont-elles à jour, cela je ne sais)
Que tu ajoutes le dépôt à la main ou via extrepo tu utiliseras un dépôt tiers, disons qu’avec extrepo tu le fais à la manière recommandé maintenant par Debian.
D’où mon interrogation 
puisque dans ce contexte, les dépôts sont quand même gérés par l’équipe Debian, puisque c’est l’infra IT de Debian, et soumis à validation, etc…
De mon sens l’équipe Elle ne gère que l’outil extrepo et maintient une liste de métadonnées et de clés GPG vérifiées.
https://packages.debian.org/sid/extrepo?pow_referer=https%3A%2F%2Fwww.google.com%2F
2 J'aime
Ce n’est pas seulement ça, c’est le fait que dans les snap, les librairies utilisées ont des vulnérabilités qui ne sont pas patchées, et qu’en plus on peut l’avoir à plusieurs versions dont aucune n’est à jour. et qu’il n’y en a aucun suivi. Alors que sur les paquets Debian c’est le cas.
Je suis d’accord mais ça n’implique pas obligatoirement la mise à jour automatique.
Là où je ne suis pas d’accord c’est que les editeurs de produit applicatifs suivent les vulnérabilités car c’est un risque de voir leur produit rejeté, et éventuellement de perdre des contrats, ou de ne plus en avoir. Ce n,'est pas le cas des Snaps. Il n’y a aucun process de suivi des vulnérabilités.
La seule chose qui existe c’est Snapscope, mais est-il largement employé? qu’elle consommation de temps cela implique-t-il?
Les risques actuels avec Debian sont largement plus faible qu’avec Snap du fait de leurs modèles de vérification.
Le fait d’être une entreprise ou une association ne change rien au paradigme. C’est une question de processus.
Le niveau de confiance est suffisamment élevé avec Debian, pas avec Snap du fait de leurs modèles respectifs.
Et les risques avec Arch ?
Cela dépends des éditeurs, encore une fois tout dépend de la confiance que tu accordes à l’éditeurs.
Pour reprendre l’exemple de Firefox penses-tu réellement que le snap est moins sécuriser que le paquet officiel distribué sur leur dépôt tiers , et sont-ils moins sécurisé que le paquet esr fourni dans Debian ?
Encore une fois tout dépend de la confiance … je sais je radote mais ton propos ne peux se confirmer à l’ensemble des paquets disponible dans le snapstore.
Si tu me permet s’est du vent là … paradigme ? processus ? modèles respectifs ?
Lorsque tu mets à disposition un logiciel comme Firefox de façon officiel tu ne te permets pas d’appliquer un cycle différent de livraison selon si c’est un paquet fourni dans un dépôt ou un .deb téléchargeable …
Ah ah ah là je sèche, je me permettrai pas de dire que l’un est plus solide que l’autre.
Tu parles de sécurisé je parles de vulnérabilité. Et l’éditeur d’un logiciel n’est pas forcement l’éditeur du snap.
C’est vrai, mais le risque est suffisamment élevé. Combien de snap n’ont jamais été patchés comparé aux paquets Debian?
Sans compter les autres effets pernicieux des snap: les performances (notamment en cas de présence simultanées de plusieurs versions différentes d’une même librairie), et tout particulièrement l’espace de stockage.
C’est toi qui mettait en apposition l’association (Debian) avec une société (je ne sais laquelle).
Et je parle bien de processus de suivi des vulnérabilités. Debian le fait sur ses paquets, je n’ai rien vu de tel concernant les Snaps.
Ça pourrait arriver à Debian, d’ailleurs, une bibliothèque a été piratée il y a quelques années par un Chinois.
https://www.akamai.com/fr/blog/security-research/critical-linux-backdoor-xz-utils-discovered-what-to-know
2 J'aime
Dans l’exemple donné i justement, c’est donc pourquoi je parle de confiance à donner ou de crédit si tu préfères.
el stockage est un détails de nos jours au regard des machines, comme l’argument des ressources RAM et CPU l’était avant la flambée des prix, ça l’est redevenu du coup.
Mais avouons le les seuls baissent de performances visible sont sur les applications les plus lourdes et cela reste malgré tout marginal.
Bah si justement dans le cas de Firefox, je ferais même plus confiance à Mozilla qu’a Debian dans ce cas là.
AUR sont des paquets externes à archlinux, une sorte de bibliothèque pour tout ce qui n’est pas packagés. Pour le coup ça n’est pas sur. Mais un paquet aur est en fait juste la donnée d’un PKGBUILD qui charge les sources et les recompile. Les sources peuvent provenir d’un GIT et donc pour le coup ça n’est pas sur. Archlinux est à exclure pour un serveur ou une machine «sensible» si on y met des logiciles venant d’AUR. De plus c’est une rolling release donc de toute façon ça ne s’y prete pas. C’est très bien pour un utilisateur qui ne s’inquiète pas trop si sa machine est 100% opérationnel, veut être à la dernière version et cherche une machine pile poil comme il veut, pas pour une machine de travail.
[PS: Cela dit, ça m’a fait un petit stress cette info de Korben, mais
[~]$ /tmp/check.sh
Checking for infected AUR packages (1937 total)...
Clean: None of the known infected packages were installed within 2 days of the campaigns.
[~]$ ]
Debian écrit noir sur blanc qu’il ne peut pas assuré la sécurité de l’intégralité des navigateurs web hors firefox et chromium. Alors, ils ne sont pas à mettre dans le même panier mais c’est assumé que les ressources sont limités. Des mainteneurs qui manquent de temps, c’est pas ce qui doit manquer.
Si snap peut apporter des vulnérabilités, il peut également assurés de la sécurité. De plus on ne peut pas traiter Canonical de rigolo et s’il dépose des Snap j’ai malgré tout une certaine confiance.
Effectivement la source des logiciels compte et on croit que les dépôts Debian sont infaillibles mais je n’y crois pas.
Coté Snap il y a déjà des changements et c’est plus clair sur la provenance des paquets et les éditeurs indiquent souvent ceux qu’ils préconisent.
On peut essayer aussi de faire un classement des dépôts de distribution les plus fiables et réactifs tout comme snap, flatpak, docker et cie.
Là où tout le monde va sûrement se rejoindre c’est d’installer que ce qui est nécessaire et de partir de la source la plus fiable (généralement les dépôts Debian) ou directement l’éditeur.
Il y a eu des soucis dans les dépots Debian avec certains paquets (j’ai pas d’exemples mais j’essaierai mais c’est généralement des gros).
Quand on voit ce qu’on peut faire avec un vieux rpi, c’est dément. et certaines applis qui semblent lourdes peuvent toujours se configurer et tourner (genre gitlab)