Triste époque, mais qu'est ce que tu veux que je te dise ?!
Rien, puisque à aucun moment, personne n'a parlé de sécurité absolue et inviolable.
Par contre, il y a une grosse différence entre aucune sécurité et zéro confiance (tous ceux qui proposent des paquets AppImage) et une sécurité qui ne sera sans doute jamais infaillible (Flatpak), on est d'accord, mais qui reste bien meilleure que la solution existante (les distributions dans leur forme actuelle, puisque même si elles sont réactives sur leurs propres paquets, elles ne peuvent proposer aucune garantie sur tout ce qui provient de sources tierces et encore moins sur toutes les applications propriétaires).
Pire encore, non seulement on ne peut avoir aucune confiance dans un paquet AppImage, mais surtout, puisque tout repose sur l'éditeur qui propose le paquet, à moins que ce soit géré par une grosse entreprise dont on peut relativement prédire qu'ils prennent les questions de sécurité au sérieux et qu'ils seront sans doute encore là demain, pour tous les autres, c'est prendre un risque inconsidéré sur la durée.
Prenons le paquet AppImage d'une petite application libre gérée par un unique développeur. Pas un gros projet à la Firefox ou LibreOffice. Le genre de petit projet qu'on trouve à foison sur GitHub, qui sont loin d'être toujours empaquetés dans les distributions et pour qui ce genre de paquet universel est une très bonne chose (ou en tout cas, devrait l'être).
Maintenant, admettons que ce petit projet nous propose un paquet AppImage. On le récupère, on l'installe (en espérant qu'ils n'aient pas oublié de dépendances, puisque apparemment ça semble être possible :p), tout fonctionne bien, on est content. Demain, il arrive une merde au développeur ou il abandonne tout simplement son projet. Si des failles sont découvertes dans la foulée dans les différentes dépendances, elles ne seront jamais corrigées dans le paquet.
Et c'est bien là tout le souci. Vouloir confier la gestion de la sécurité, non pas uniquement de leur application, comme le propose Flatpak, mais également de l'ensemble des dépendances de l'application, à des développeurs dont ça ne sera pas forcément le métier et qui n'auront pas forcément le temps ou l'envie de s'en occuper.
Et encore une fois, non, on ne peut pas garantir qu'un développeur n'inclura pas volontairement ou non des merdes dans son paquet Flatpak. Mais ça sera la même chose pour un paquet AppImage, qui aura potentiellement en plus tout plein de failles dans ses dépendances.
Ton raisonnement revient donc à dire que puisque la sécurité absolue est un rêve impossible, alors ce n'est même pas la peine d'essayer de l'atteindre et qu'il vaut mieux se contenter d'une solution bien moins efficace, mais qui occupera potentiellement un peu moins de place sur le disque...
[^] # Re: trop de place
Posté par Okki (site web personnel, Mastodon) . En réponse au journal Mais pourquoi flatpak ?. Évalué à 0.
Rien, puisque à aucun moment, personne n'a parlé de sécurité absolue et inviolable.
Par contre, il y a une grosse différence entre aucune sécurité et zéro confiance (tous ceux qui proposent des paquets AppImage) et une sécurité qui ne sera sans doute jamais infaillible (Flatpak), on est d'accord, mais qui reste bien meilleure que la solution existante (les distributions dans leur forme actuelle, puisque même si elles sont réactives sur leurs propres paquets, elles ne peuvent proposer aucune garantie sur tout ce qui provient de sources tierces et encore moins sur toutes les applications propriétaires).
Pire encore, non seulement on ne peut avoir aucune confiance dans un paquet AppImage, mais surtout, puisque tout repose sur l'éditeur qui propose le paquet, à moins que ce soit géré par une grosse entreprise dont on peut relativement prédire qu'ils prennent les questions de sécurité au sérieux et qu'ils seront sans doute encore là demain, pour tous les autres, c'est prendre un risque inconsidéré sur la durée.
Prenons le paquet AppImage d'une petite application libre gérée par un unique développeur. Pas un gros projet à la Firefox ou LibreOffice. Le genre de petit projet qu'on trouve à foison sur GitHub, qui sont loin d'être toujours empaquetés dans les distributions et pour qui ce genre de paquet universel est une très bonne chose (ou en tout cas, devrait l'être).
Maintenant, admettons que ce petit projet nous propose un paquet AppImage. On le récupère, on l'installe (en espérant qu'ils n'aient pas oublié de dépendances, puisque apparemment ça semble être possible :p), tout fonctionne bien, on est content. Demain, il arrive une merde au développeur ou il abandonne tout simplement son projet. Si des failles sont découvertes dans la foulée dans les différentes dépendances, elles ne seront jamais corrigées dans le paquet.
Et c'est bien là tout le souci. Vouloir confier la gestion de la sécurité, non pas uniquement de leur application, comme le propose Flatpak, mais également de l'ensemble des dépendances de l'application, à des développeurs dont ça ne sera pas forcément le métier et qui n'auront pas forcément le temps ou l'envie de s'en occuper.
Et encore une fois, non, on ne peut pas garantir qu'un développeur n'inclura pas volontairement ou non des merdes dans son paquet Flatpak. Mais ça sera la même chose pour un paquet AppImage, qui aura potentiellement en plus tout plein de failles dans ses dépendances.
Ton raisonnement revient donc à dire que puisque la sécurité absolue est un rêve impossible, alors ce n'est même pas la peine d'essayer de l'atteindre et qu'il vaut mieux se contenter d'une solution bien moins efficace, mais qui occupera potentiellement un peu moins de place sur le disque...