2
Essaie avec ma commande ci-dessus pour voir le retour. Regarde bien parmi les paquets supprimés s'il y a un logiciel que tu utilises.
Ensuite, regarde dans YaST s'il reste des paquets texlive comme le dit @oh!rocks .
S'il te semble qu'il n'y a plus rien, il faudra après la suppression que tu passes texlive en tabou : dans YaST, tu cherches le paquet texlive puis clic droit dessus > Tabou - ne jamais installer.
Sinon, lors d'une prochaine grande maj d'un des paquets marqués i+ dans le retour de la commande
zypper se --recommends-pkg texlive
il voudra se réinstaller.
4
Tu peux faire
sudo zypper rm --clean-deps texlive
en faisant attention aux paquets qui vont être supprimés
6
one or more print queues exist for this device
Supprime la configuration que tu as commencé à faire pour repartir de zéro. Tu cliques sur les lignes et "supprimer"
7
@jenrem : oui c'est vrai que ça déborde 
tu peux envoyer le résultat dans un fichier texte que tu ouvriras ensuite avec kate par exemple sur KDE.
Tu fais la commande en utilisateur et tu trouveras le fichier dans ton home
zypper se --requires-pkg texlive >paquets-dependant-texlive.txt
zypper se --recommends-pkg texlive >paquets-recommandant-texlive.txt
Tu pourras faire défiler la liste et voir la ligne qui commence avec i ou i+
@oh!rocks : xournal ne semble pas installé sur son PC, c'est lui qui provoque la demande d'installation de texlive chez moi. J'ai eu du mal à trouver que c'était lui qui provoquait ça.
Après on peut peut-être imaginer un paquet qui demande en recommandé un autre paquet texlive-qqchose qui lui même demande texlive ?
@jenrem : Regarde si tu as des texlive installés
8
Tu n’as pas de drapeau i ou i+ dans la première colonne dans le retour que tu as mis sur le forum, c’est surprenant. Normalement le paquet qui appelle texlive lors de certaines majs devraient être indiqué par i ou i+ dans la première colonne.
Tu as aussi la commande pour les dépendances avec le même principe du I ou I+ dans la première colonne pour trouver le responsable.
zypper se --requires-pkg texlive
9
Bonsoir,
Pour savoir quel paquet demande texlive en recommandé, tu peux faire
zypper se --recommends-pkg texlive
dans la liste qui s'affiche, tu cherches le ou les paquets avec le drapeau i ou i+
Chez moi, c'est le logiciel qui demande cette installation. J'ai bloqué texlive.
15
TLDR (Résumé) de ce qui s'est passé
Les distributions Linux ont été utilisées à mauvais escient pour offrir une porte dérobée à leurs utilisateurs. Le but exact de la porte dérobée reste encore une spéculation. Il peut s'agir d'un individu souhaitant vendre l'accès à une puissance de calcul abondante via des machines virtuelles hébergées dans un cloud public et dotées d'un port SSH vulnérable ouvert au public. C’est là une extrémité plutôt improbable, mais toujours possible, du spectre. L’autre extrémité du spectre est une entreprise qui vend des portes dérobées à des acteurs étatiques qui les utilisent pour accéder à distance et secrètement à n’importe quelle machine Linux. Même si des erreurs ont été commises, cet objectif a presque été atteint. Où est la vérité ? Pour cela, d’autres preuves doivent être identifiées et analysées.
Il est temps d'attendre
Après cet examen attentif des coulisses de ce qui s’est passé fin mars, le reste de cet article passe à l’avenir.
Loi de Linus et les distributions
« Avec suffisamment d’yeux, tous les bugs sont superficiels ». Dans les communautés open source, cela est souvent cité comme une raison pour laquelle on peut faire confiance à l'open source. Pour les projets open source qui attirent suffisamment l’attention de contributeurs suffisamment qualifiés, cette « loi » a probablement au moins un certain poids. Cependant, Heartbleed (voir ici pour l’histoire de Heartbleed) nous a appris par exemple que ces conditions ne sont pas universellement remplies. Il existe de nombreux projets qui sont absolument essentiels et pourtant sont considérés comme ennuyeux et ne parviennent pas à attirer beaucoup de responsables ou de contributeurs, et ceux qui participent au projet sont déjà ensevelis sous une pile de travail et ne peuvent pas vraiment consacrer d'efforts significatifs à la montée en puissance. de nouveaux venus.
La porte dérobée XZ a été conçue pour cibler uniquement les distributions. D’abord par les pré-vérifications que la porte dérobée exécutait avant son déploiement, mais aussi parce que les conditions nécessaires à l’implantation n’existaient qu’en aval dans ces distributions. Debian, ainsi que les autres distributions concernées comme openSUSE, contiennent une quantité importante de correctifs uniquement en aval pour des projets open source essentiels, comme dans ce cas OpenSSH. Avec le recul, cela devrait être un autre apprentissage au niveau Heartbleed pour le travail des distributions. Ces correctifs constituent les étapes essentielles pour intégrer la porte dérobée et ne font pas l'objet de l'examen minutieux qu'ils auraient probablement reçu de la part des responsables en amont respectifs. Que vous fassiez confiance ou non à Linus Law, il n’a même pas eu l’occasion d’intervenir ici. L'amont n'a pas échoué sur les utilisateurs, les distributions ont échoué sur l'amont et leurs utilisateurs ici.
L'open source et leurs communautés
Être capable d'inspecter le code source des logiciels open source donne à la communauté un avantage imbattable par rapport aux alternatives propriétaires à fournisseur unique. Cependant, l’audit du code source prend beaucoup de temps et nécessite souvent des experts en domaine et en sécurité très expérimentés. Les distributions commerciales devraient jouer et jouent un rôle important à cet égard ; pourtant, ils ne l'ont pas identifié. Le projet XZ était en ce sens l’angle mort idéal quant à la manière dont les efforts sont généralement alloués aux audits de sécurité. Très profondément imbriqué et important pour chaque distribution pour des raisons non évidentes, et dans l'état d'un seul responsable et de très peu de contributeurs ou de réviseurs depuis des années. Ce n’est pas le nouveau projet open source brillant natif du cloud ou autrement sophistiqué qui attire des milliers de développeurs ou de chercheurs en sécurité, et pourtant il est tout aussi important pour l’intégrité et la sécurité de l’informatique moderne. S’il y a quelque chose à apprendre ici, c’est que les critères de sélection sur lesquels se concentrer doivent être ajustés en fonction de ces apprentissages.
Par ailleurs, d’autres ont déjà souligné que le vecteur d’attaque initial n’était pas technique. Ce n’était pas une archive tar archaïque. La véritable attaque initiale était une ingénierie sociale et utilisait un comportement toxique dans les communautés. Ceci est réel et n’affecte pas seulement dans ce cas les responsables existants des projets open source. De nombreuses histoires ont été racontées dans lesquelles le stress ou l'épuisement professionnel des responsables étaient liés à des participants toxiques dans les communautés du projet. Même si je pense que les distributions ne font pas partie de ces activités, nous ne sommes pas conçus pour empêcher que ces choses se produisent. Les développeurs de la distribution sont concentrés sur leurs problématiques et leurs utilisateurs et risquent, du fait de leur temps limité, de négliger les communautés open source (en amont). C'est une autre chose que nous devons garder à l'esprit.
Des initiatives comme CHAOSS et l’ Open Source Security Foundation ont été fondées car sinon, ces situations seraient trop faciles à ignorer. Ils fournissent un service essentiel dans l’analyse du « facteur bus » ou du « facteur de collusion » quant au nombre d’acteurs nécessaires pour renverser un projet et permettent ainsi à d’autres de se concentrer sur l’orientation de l’aide là où elle compte le plus.
Le prix de la liberté
Le FLOSS n'est pas une question de coût, ni de liberté d'utilisation , mais de liberté d'inspection et de (ré)utilisation . Quel est le prix de cette liberté ? Dans le monde propriétaire, les logiciels sont payants. En open source, cette liberté doit recevoir la reconnaissance qu’elle mérite et doit être valorisée. Lorsque quelqu’un qualifie la porte dérobée XZ d’incident de sécurité de la chaîne d’approvisionnement logicielle, ce n’est pas une image complète. Une chaîne d'approvisionnement en logiciels serait l'endroit où il y a un fournisseur à une extrémité. Mais les projets et les communautés open source ne sont pas aujourd’hui des fournisseurs. Ils n’ont aucun contrat juridiquement contraignant avec aucun de leurs consommateurs et aucun échange d’argent n’est impliqué. Il existe une communauté, de taille variable, qui contribue et aide, soit en tant que bénévoles, soit en tant que travailleurs rémunérés. La plupart des projets n’en reçoivent pas suffisamment.
En guise de réflexion ouverte : les distributeurs devraient-ils activement développer et gérer leur chaîne d'approvisionnement et traiter « leurs fournisseurs » comme de véritables fournisseurs avec des termes et conditions mutuelles juridiquement contraignantes et des compensations convenues ?
Le Web sécurisé de confiance est la nouvelle sécurité de la chaîne d'approvisionnement
Dans cet incident particulier, des archives tar signées ont été utilisées pour publier le lanceur de la porte dérobée. Beaucoup de choses ont été dites à ce sujet. Nous devons réaliser qu’il s’agit d’une distraction. Un piège. En termes de taille de code, 99,9 % de la porte dérobée se trouvait dans le référentiel de code source. Le lanceur dans l'archive tar devait limiter l'exposition de la porte dérobée aux seules victimes prévues, techniquement inutiles pour quoi que ce soit ou par quoi que ce soit. Il aurait été tout aussi facile à intégrer et tout aussi difficile à repérer, le reste des 0,1 % étant également engagé dans le référentiel de code du projet, juste d'une manière légèrement différente.
Pour la plupart des autres scénarios d’attaque imaginables, les artefacts de version signée offrent des qualités importantes. Ils répondent à l’attente d’expédier uniquement ce qui a été jugé prêt à être expédié. Ils fournissent une chaîne vérifiable de manière indépendante jusqu'à l'origine (le « Fournisseur »). Cependant, chaque distribution commence par cette première partie vérifiable de la chaîne, puis s'y ajoute. Souvent (ou presque toujours) avec un moyen transparent de vérifier également ces changements (sous la forme de procédures conformes au SLSA), le tout de manière isolée. Dans quelle mesure ces chaînes disjointes sont-elles fiables ? Actuellement, les distributions réutilisent occasionnellement des correctifs identiques ou similaires en plus des versions de projet en amont, mais sinon, la plupart du temps, elles fonctionnent de manière isolée et ne collaborent que rarement activement. L'élément essentiel du correctif en aval qui a activé la porte dérobée existait depuis près de 10 ans dans les distributions, mais n'a pas encore été vu en amont.
Nous reconnaissons que la porte dérobée du XZ est intelligemment construite. Pourtant, son exécution comportait des défauts surprenants. Quiconque souhaite intégrer d’autres portes dérobées a tiré les leçons de la large couverture publique de tout ce qui n’a pas fonctionné. Ces erreurs ont été signalées, publiées et tirées des leçons. Nous avons donné aux acteurs derrière cette porte dérobée une formation gratuite pour de futures attaques. Il est temps que les distributions en tirent également des leçons et suivent également des cours de formation. Nous devons collaborer activement et construire un réseau de confiance solide et fiable avec les projets open source et entre nous pour être prêts à relever les inévitables défis futurs à venir. Construisons ensemble un réseau de confiance sécurisé !
