Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par Jean-Pierre Pinson (08-08-2024 14:16:39)
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Hors ligne
Ça fonctionne pour tout logiciel, peu importe la forme de sa distribution.
Merci pour l'info vv222 
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
FLATHUB – applications pour Linux, fonctionnant pour nous ;
blague à part, Jean-Pierre, quand il y a une erreur de frappe, tu peux la corriger avant de la recopier (ou/et envoyer un petit mot à l'équipe de traduction fr de Debian pour leur signaler la coquille )
*********
sinon,
c'est toujours possible d'introduire un code malicieux dans une application.
Ça fonctionne pour tout logiciel, peu importe la forme de sa distribution.
comme pour XZ ? 
ou n'y a-t-il eu que les gens utilisant Debian SiD qui ont été impacté(e)s ? 
+++ et justement, dans le cas des snaps, flats ou app images, comment ça se passe ?
Si ces applications embarquent toutes leurs bibli etc avec elles pour fonctionner dans un bac à sable en autonome (si j'ai bien compris), avec une bibliothèque (?/logiciel-utilitaire) comme XZ, lors d'une mise à jour, y'a toutes les applis snap, flat et app qui viennnent se mettre à jour leur bibli vérolée, ou on a le risque d'avoir un truc dans un bac à sable utilisant des trucs bogués ou vérolés dans son système ?
Hors ligne
Jean-Pierre Pinson a écrit :FLATHUB – applications pour Linux, fonctionnant pour nous ;
blague à part, Jean-Pierre, quand il y a une erreur de frappe, tu peux la corriger avant de la recopier
*****
Désolé mais je ne vois pas où est l'erreur de frappe ubub, dis-moi ce qu'il faut mettre et je corrigerai.
En tout cas la phrase qui est importante c'est celle-là: Les binaires de ces sites peuvent inclure des logiciels propriétaires non libres.
Dernière modification par Jean-Pierre Pinson (08-08-2024 10:56:32)
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Dernière modification par Jean-Pierre Pinson (08-08-2024 13:01:52)
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Hors ligne
comme pour XZ ?
ou n'y a-t-il eu que les gens utilisant Debian SiD qui ont été impacté(e)s ?
Debian stable n’a pas été impactée.
Mais la source de cette attaque n’était de toutes manières pas technique, elle aurait pu passer peu importe les précautions mises en place côté logiciel et infrastructure.
+++ et justement, dans le cas des snaps, flats ou app images, comment ça se passe ?
Si ces applications embarquent toutes leurs bibli etc avec elles pour fonctionner dans un bac à sable en autonome (si j'ai bien compris), avec une bibliothèque (?/logiciel-utilitaire) comme XZ, lors d'une mise à jour, y'a toutes les applis snap, flat et app qui viennnent se mettre à jour leur bibli vérolée, ou on a le risque d'avoir un truc dans un bac à sable utilisant des trucs bogués ou vérolés dans son système ?
Au moins pour Flatpak et AppImage, il n’y a aucune règle (c’est possiblement mieux encadré avec snap). Chacun maintient son paquet comme il le souhaite, en mettant ou pas à jour les dépendances embarquées avec régularité. Si on fouille du côté de Flatpak et AppImage, je pense que pour reprendre ton exemple on pourrait y retrouver plusieurs exemplaires de la version compromise de xz encore aujourd’hui.
Hors ligne
Dernière modification par Jean-Pierre Pinson (08-08-2024 13:05:34)
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Debian sid
Bureau : gnome
Ordinateur : Thinkpad T400 libreboot
Hors ligne
Chacun maintient son paquet comme il le souhaite, en mettant ou pas à jour les dépendances embarquées avec régularité.
En mon sens c'est un véritable soucis.
La multiplication des sources de confiances qui est nécessaires avec Flatpak, AppImage, Snap est un soucis de sécurité.
Plus on les multiplies, plus ça devient dangereux (ont ne peux pas faire confiance à tous ceux qui se disent de confiance).
Il n'est pas rare de trouver un acteur de la sécurité corrompu à son insu (j'ai la malchance de disposé de ce livre : Rootkits, infiltration du noyau.... Ho ça ne parle pas de Linux mais y est expliqué que nos machines sont déjà corrompues à l'achat; avec ou sans OS 
)
Déjà qu'il faut faire un effort (fermer les yeux) pour faire confiance à une seule source.
On se souvient des clés révoquées de Dmitry Bogatov (https://debian-facile.org/viewtopic.php?id=17623).
Un trousseaux de clé n'est qu'un ensemble de fichier qui peut sans mal être récupérés par celui qui s'en donne les moyens (même si cryptés dans une clé mise au tour du coup ).
Dernière modification par agp91 (08-08-2024 14:49:52)
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
En mon sens c'est un véritable soucis.
La multiplication des sources de confiances qui est nécessaires avec Flatpak, AppImage, Snap est un soucis de sécurité.
Plus on les multiplies, plus ça devient dangereux (ont ne peux pas faire confiance à tous ceux qui se disent de confiance).
Je suis d’accord, et c’est ma raison principale pour n’utiliser qu’un seul et unique gestionnaire de paquets : apt.
Pas de Flatpak, pas d’AppImage, mais pas non plus de pip (Python), cargo (Rust) ou npm (JavaScript) par exemple.
Un trousseaux de clé n'est qu'un ensemble de fichier qui peut sans mal être récupérés par celui qui s'en donne les moyens (même si cryptés dans une clé mise au tour du coup
Je souhaite quand même bonne chance à qui voudrait voler les clés que j’utilise pour signer des paquets à destination des dépôts Debian offficiels, ça nécessiterait des moyens qui sont très loin d’être à la portée de n’importe qui 
(et pour bien leur compliquer la tâche ça ne leur permettrait de corrompre qu’un nombre très restreint de paquets, qui de plus sont très peu installés par les utilisateurs de Debian)
Hors ligne
Je souhaite quand même bonne chance à qui voudrait voler les clés que j’utilise pour signer des paquets à destination des dépôts Debian offficiels, ça nécessiterait des moyens qui sont très loin d’être à la portée de n’importe qui
C'est pour cela que j'ai arrêté la secu... Ca rend fou... Et parano
Maintenant je suis un vrai pot de miel
(et pour bien leur compliquer la tâche ça ne leur permettrait de corrompre qu’un nombre très restreint de paquets, qui de plus sont très peu installés par les utilisateurs de Debian)
Sur mais qu'en est-il des autres acteurs ?
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
Sur mais qu'en est-il des autres acteurs ?
Ceux que je connais prennent la sécurité de leurs clés très au sérieux. À savoir que Debian nous distribue sur demande des tokens physiques pour améliorer cette sécurité.
Mais je ne connais pas non plus tout le monde au sein de Debian, loin de là. Donc une bonne partie de la confiance que j’accorde est extrapolée à partir des comportements des personnes que je connais.
Hors ligne
que tous chez Debian et ceux qui développent les soft utilisés par Debian sont intègres.
Dernière modification par agp91 (08-08-2024 16:26:26)
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
Mais je ne connais pas non plus tout le monde au sein de Debian, loin de là. Donc une bonne partie de la confiance que j’accorde est extrapolée à partir des comportements des personnes que je connais.
certains paquets sont installés partout, donc c'est sur ces personnes que repose l'essentiel de la sécurité.
je n'ai pas d'ordre de grandeur mais certains paquets sont à mon avis peu utilisé et essentiellement à destination des particulier (par exemple les jeux).
j'imagine que c'est déjà théorisé mais à part la confiance je ne vois pas comment gérer ce type de projet.
je dirai que ça se rapproche du consensus scientifique.
L'attaque de la supply chain est une réalité et vv222 à un avis très tranché.
Pour autant, je n'aurai aucune crainte sur certains logiciel du moment que les développeurs ont la compétence de mettre à disposition via différents canaux.
sur la sécurité de apt, je ne suis pas certains qu'elle soit supérieur à pip, npm, cargo ou autre 
c'est les acteurs et les contraintes pour distribuer des logiciels qui assurent la sécurité.
Il faut d'abord n'installer que ce qui est essentiel et pas passer sont temps à installer tout et n'importe quoi sur sa machine. sinon, faire ça sur un environnement qui ne risque rien.
Hors ligne
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil 
Hors ligne
Pour autant, je n'aurai aucune crainte sur certains logiciel du moment que les développeurs ont la compétence de mettre à disposition via différents canaux.
sur la sécurité de apt, je ne suis pas certains qu'elle soit supérieur à pip, npm, cargo ou autre
Pour pip, cargo, npm, etc, c'est la multiplication des sources de confiance, qui pose problème (une de plus par soft installé).
En sachant que : La plus part des développeurs ne sont pas au fait de la sécurité (sinon nous aurions des softs sécurisés et il y aurait pas de soucis de sécurité). Quand au packageurs (les constructeurs de paquet) peuvent ne pas être les développeurs des softs qu'ils empaquettent.
Il y en fait très peu (pour ne pas dire pas) de logiciel libre qui ont subit un audit de sécurité. Encore moins qui en subit à chaque version.
Un autre soucis est que les failles de sécurité d'un soft ,ne sont pour la plus part divulgués, qu'une fois que le créateur du soft ai porté correction.
Impossibilité de contrôler ce qui est intégré à l'application.
C'est le soucis de toutes containérisations qui ne soit pas réalisé par soi même. On peut citer : snap, flatpack, mais aussi docker, kbernette, lxd (lxc sauce canonical) et même lxc si le container tourne sous une autre autorité que root (tout comme avec lxd, les dépôts du mina installé dans un contraire ne sont alors plus ceux de Debian) et j'en oubli.
Finalement, VM, containers, ou toutes couches intermédiaires complexifient le système (ce qui n'est jamais bon en terme de sécurité). Et cache à l’hôte ce qui est réaliser dans les isolations. Il est grandement plus sage d'avoir un simple système qui fait tourner des services ou des applicatifs correctement configurés.
En fait les container sont issus de chroot, qui au départ n'a pas été créé pour la sécurité, mais pour l'usage pratique des développeurs, pour tester sans altérer le système.
Snap, faltpac, appimage, etc, ne sont pas développés pour la sécurité mais pour faciliter la diffusion des softs.
Dernière modification par agp91 (09-08-2024 12:50:36)
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
]C'est pour cela que j'ai arrêté la secu...
Hors ligne
Dernière modification par agp91 (09-08-2024 13:01:23)
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
En ligne
Quand au packageurs (les constructeurs de paquet) peuvent ne pas être les développeurs des softs qu'ils empaquettent.
Pour moi c’est la situation idéale. En tant que développeur on a forcément des œillères au sujet de nos propres logiciels (moi le premier), c’est donc une très bonne chose que les empaqueteurs soient des personnes distinctes qui vont avoir une lecture différente des problématiques liées à la distribution.
Un très bon développeur peut en même temps être un très mauvais empaqueteur/distributeur. C’est d’ailleurs ce qui explique selon moi la prolifération de Flatpak et consorts.
Hors ligne