Follow

Bon, en gros tout ce que j’avais prévu pour s’avère vrai 😂
flatkill.org/

@aeris ah mais voilà, je vois que c'est du red hat encore ce truc. Pas étonnant que ça soit n'importe quoi du coup!

@Schoumi
Pour l'instant ils sont encore au début du dev donc c'est pas vraiment étonnant qu'il y ait des problèmes
@aeris

@adidal @Schoumi Nope. Là les problèmes sont structurelles et fonctionnels, et pas du tout logiciel.
Ils ne sont PAS patchables sans virer tous les intérêts vantés par ce type de projets.

@adidal @Schoumi Dès que tu embarques en dur tes dépendances, tu as de toute façon le problème que comme tu as figé ta version, tu te tapes toutes les CVE publiées tant que tu ne changes pas ta lib système dans ton image.

@adidal @Schoumi Et si tu passes ta vie à changer tes libs systèmes à chaque nouveau fix de sécu dessus, ben du coup tu ne fais pas mieux que apt & cie et arrête de faire des projets comme ça quoi 😂

@aeris
J'avoue que le problème des libs est assez chiant. Mais bon franchement tu peux toujours automatiser la màj de tout ça. On maîtrise bien tout ce qui est CI/CD.

@Schoumi

@adidal @Schoumi Automatiser = virer l’intérêt de flatpac qui se vante de justement fixer dans le marbre les dépendances.

@adidal @brainblasted @Schoumi La gestion des permissions, on a vu ce que ça donne sous Android ou Firefox. Personne ne les lit, personne ne les comprend, tout le monde fait « suivant ».

@aeris
Mais tu peux toujours les changer. C'est d'ailleurs ce qu'il manque aux distros qui prennent en charge Flatpak
@brainblasted @Schoumi

@adidal @brainblasted @Schoumi Ce n’est pas un problème de pouvoir les changer ou non.
C’est que personne ne les lit et ne les comprend.
Du coup une appli malveillante qui veut accéder à ton ~, elle s’installera sans que personne ne remarque rien.

@adidal @brainblasted @Schoumi On a la preuve par A+B que les permissions, ça ne juste marche pas. Firefox s’est taulé avec. Google s’est taulé avec. Flatpak ne fera pas mieux.

@adidal @brainblasted @Schoumi Sauf que ça laisse du dégât derrière et les mauvaises idées dans les têtes.

@adidal @brainblasted @Schoumi Ça laisse toujours penser aux gens que l'idée est bonne et que c'est juste des problèmes d'implémentation.
Au lieu de directement cramer au napalm le premier qui balance à nouveau l'idée.

@aeris
mdr au moins ils ont essayé de faire qqch. C'est mieux que de ne rien faire, nan?
@brainblasted @Schoumi

@adidal @brainblasted @Schoumi Pas sur des choses qui sont impossibles à réaliser et déjà (non) implémentées whatmille fois…

@adidal @brainblasted @Schoumi Et si tu veux faire des choses, fait de l'éduc pop sur l'hygiène info, ou va botter le cul des (non) mainteneurs d'applis obsolètes, ou porte-les toi-même.

@aeris
Bah ça dépend : t'as qu'à regarder du côté des containers dockers. Après forcément docker souffre du même genre de problème avec les libs :/
@brainblasted @Schoumi

@adidal @brainblasted @Schoumi C'est bien ce que je dis. Les mêmes (non) problèmes, les mêmes (non) solutions, les mêmes (vrais) problèmes supplémentaires.

@aeris
Bah dans le cas de docker ça fait quand même son taf. C'est bcp plus léger que d'avoir plusieurs OS virtualisés
@brainblasted @Schoumi

@adidal @brainblasted @Schoumi Non. Docker est aussi le bel exemple de la non solution à un non problème mais apportant énormément de bordel en plus.

@adidal @brainblasted @Schoumi Si on veut de la légèreté, je pense que LXC & cie suffisent largement.
On n’est pas à un systemd près, d’autant plus quand ça te fuck 99% des systèmes tiers nécessaires en prod (monitoring, update…)

@adidal @brainblasted @Schoumi Ça a ramener en prime le problème des dépendances. Combien d’images sont actuellement à jour après la sérieuse faille alpine il y a un mois ? Si on dépasse les 10%, je serais très étonné.

@adidal @brainblasted @Schoumi Et encore, je ne parle que des couches basses, plus tu vas monter dans le n° de layer, plus tu as de chance que le mainteneur n’ait rien maintenu.
Proba que ton appli qui est layer 5 ou 6 soit à jour : 0.

@aeris nan mais en fait, y a rien de nouveau dans cette page.

On est déjà tous au courant de ces problèmes, et on est justement en train de travailler dessus. Mais bon période de transition, nuance, tout ça…

Et concernant la sandbox imparfaite, faut pas oublier que les paquets système sont pas du tout sandboxés, donc dans le pire des cas, Flatpak est au même niveau que les paquets système.

🙄

@mathieu Le problème de gimp est *impatchable*. Ce n’est pas un bug, c’est simplement le design même de tout embarquer dans l’image qui conduit à ça !

@mathieu C’est exactement l’illustration de ce que je dis sur le problème majeur de toutes ces solutions « immutable qui embarque tout ».
Ça transforme de facto le mainteneur de l’image (ie de l’application) en le mainteneur de l’ensemble de tous les composants de l’image (ie de toutes les dépendances).
Le taff étant juste monstrueux (à chaque sortie d’une release de sécu d’une dépendance, il faut rebuilder l’image de l’app) que tout le monde se limite à relivrer sur les maj majeure de l’appli.

@mathieu Et déjà que tu as perdu le côté sandboxing, qu’en plus tu perds du coup l’autre intérêt vanté de ces technos qui est de figer dans le temps les dépendances.
Bilan : ça fait au mieux aussi bien que apt au niveau fonctionnel, mais avec tout plein de problèmes supplémentaires en pratique.

@aeris je vois pas du tout ce qui serait impatchable avec GIMP.

@mathieu Que c’est un problème humain et non logiciel.
C’est juste que les mainteneurs des applis Gimp, VSCode et autres n’ont *PAS* patché leurs libs systèmes…

@mathieu La seule solution serait d’automatiser des rebuilds auto dès qu’une des dépendances bougent, mais ça veut dire virer flatpak qui n’a du coup plus aucun intérêt (image plus immuable + upgrade des dépendances = exactement apt).

@mathieu Leurs images restent bindées sur de vieilles versions de lib (c’est même l’un des avantages vantés de flatpak), et du coup reste faillible en permanence à toutes les CVE dévoilées depuis.

@aeris ben encore une fois, "période de transition" …

Pour le SDK Freedesktop, on est en train de plancher sur un tracker de CVE automatique pour s'assurer qu'on n'a pas de failles connues non corrigées.

Et le SDK Freedesktop étant la base des autres runtimes, ça va déjà faire un bien fou.

GNOME bosse aussi sur ça pour son SDK (hint : quasiment les mêmes personnes).

Aucune idée de KDE, mais on bosse aussi ensemble, donc y a pas de raison.

@aeris et une fois qu'on a la "maintenance story" correcte pour les runtimed, on a fait la majeure partie du taf, vu le partage des runtimes, et le fait que globalement les libs bien critiques (e.g OpenSSL) sont dans les runtimes.

Y a aucune raison qu'on ne puisse pas faire pareil pour les amplis. Genre, je sais que Flathub veut aussi automatiser les checks de CVE et, surprise, c'est la même personne qui bosse sur ça qui a commencé un truc pour le SDK Freedesktop.

@mathieu Ça ne change rien au problème : flatpak n’a juste plus aucun intérêt par rapport à un apparmor + apt standard.
Sinon massivement de la complexité…

@mathieu apt & cie, ça repose sur 25 ans de retour d’expérience, si c’est encore utilisé, ce n’est pas pour rien.

@aeris bien sur que si il reste des intérêts.

Par exemple, rendre aux upstreams la responsabilité de distribuer leurs propres applications.

Choisir leurs dépendances et les versions de celles-ci, c'est aussi un intérêt.

Flatpak sait aussi sandboxer des trucs que apparmor ne sait pas faire (iirc seuls les paths sont gérés ?).

@mathieu Non, apparmor est capable de bloquer n’importe quel appel système. Réseau, matos, filesystem…
Et non, flatpak n’a plus d’intérêt puisqu’il faut JUSTEMENT interdire aux upstreams de choisir leurs dépendances, ou en tout cas pas leurs versions (c’est la dernière à jour, point).

@mathieu Et les upstreams sont déjà capables de livrer leur propre application hein. Je ne vois pas en quoi flatpak change quoi que ce soit ici.

@mathieu Certes, il faut packager pour chaque distribution. Mais Flatpak ne changera rien car ne sera finalement qu’une distribution parmi les autres s’ils résolvent leur problème de dépendance.

@mathieu Sans parler qu’il y aura de facto plusieurs versions de l’image flatpak à livrer, ne serait-ce que pour supporter les différentes glibc des différentes distributions hôtes pour flatpak (appimage s’est déjà pris les pieds dans le tapis là-dessus… forum.cozy.io/t/erreur-suite-a)

@mathieu Et avant de trouver une solution, encore faut-il s’assurer qu’il y a un problème.
As-tu déjà vu une application malveillante dans les dépôts des distributions ? À ma connaissance non.
Même s’il y en avait eu une, le sandboxing aurait-il améliorer la situation ? À mon avis non.
Et même s’il l’avait améliorer, aurait-on pu utiliser une solution déjà existante et bien plus robuste ? Oui, de la pure virtualisation.
Donc pourquoi envisager le sandboxing du coup ?

@mathieu Quelqu’un qui est à ce point parano pour vouloir des applis sandboxées de partout, il va sous QubeOS, point.
Par contre l’utilisabilité au quotidien frise le 0%, parce qu’un sandboxing efficace est un sandboxing qui va à l’encontre des besoins primaires d’un gens standard.

@mathieu Plus de possibilité de copier/coller. Plus d’accès à ~ donc plus de config homogène entre application ou de sauvegarde dans un répertoire commun. Plus de communication possible d’une application à l’autre. Etc.

@aeris ben ouais, exactement.

Le sandboxing est un compromis qui (à terme) peut offrir une sécurité correcte en gardant une UX raisonnable.

@aeris @mathieu "As-tu déjà vu une application malveillante dans les dépôts des distributions ?" C'est pas tant le fait qu'elle soit malveillante que le fait qu'elle expose des bugs exploitables.

@rom1v @mathieu Oui, mais alors on en arrive au point précédent : on a surtout besoin de libs système à jour, et de ne pas se coltiner des applications avec des dépendances antédiluviennes…

@rom1v @mathieu Non, une application qui utilise OpenSSL 0.9.8, tu ne veux juste pas t’en servir. Ou alors dans un env **VRAIMENT** cloisonné type VM. Pas dans un truc totalement bordélique.

@aeris @mathieu Oui, mais y'a pas que ça. Prends un truc qui fait du parsing (un lecteur vidéo, au hasard), à jour, avec des dépendances à jour, y'a très probablement plein de moyens de l'exploiter.

@rom1v @mathieu Non. Déjà il n’a aucune raison d’être accessible du réseau. Même s’il l’était, tu as un firewall. Et si on parle compromission physique, on parle compromission physique, ie « you're doomed ».

@aeris @mathieu Ça dépend quelle est la menace. Si je t'envoie une vidéo spécialement forgée pour exécuter du code sur ta machine quand tu la lis avec $PLAYER, c'est mieux si ton player n'a pas _tous_ les droits sur la machine.

@aeris @rom1v ben ouais, la sandbix bloque le réseau par défaut. 🙂

@aeris nome, la glibc est dans le runtime.

Contrairement à AppImage, aucune lib n'est prise sur l'hôte.

@mathieu kernel + glibc, c’est atomique. Remplacer l’un sans remplacer l’autre, c’est une TRÈS mauvaise idée.
Et du coup, comme app + glibc c’est aussi atomique, on a kernel + glibc + app qui est atomique.
Dit autrement, faire tourner une application qui n’a pas été builder sur *EXACTEMENT* la même version de glibc + kernel, c’est du suicide assisté par ordinateur.

Sign in to participate in the conversation
Mastodon

PARCE QUE C’EST MON INSTANCE !