Aller au contenu principal ↑ ↓

Voir les messages

Cette espace vous permet de voir toutes les Voir les messages réalisées par ce membre. Vous ne pouvez voir que les Voir les messages réalisées dans les espaces auxquels vous avez accès.

Messages - chalu

1
Matériel / Re : scanner ne marche pas
As tu essayé un autre pilote ?
As tu essayé une installation en passant par l’outil en ligne de commande hp-setup au lieu de YaST ?
Essaie de nous retourner les réponses précises que tu obtiens dans un terminal.
2
Nouvelles du projet openSUSE / Re : News openSUSE : Ce que nous devons retenir de la porte dérobée XZ
@jenrem au boulot, les gens ne sont pas maître de l'environnement qu'ils utilisent contrairement à un usage privé et d'ailleurs la plupart du temps ils ne savent pas ...
Pour le privé,  c'est beaucoup lié aux habitudes. J'ai des proches qui ont découvert linux après Windows 7 et qui lorsqu'ils sont repassés à Windows 10, étaient impatients de repasser à Linux...
Le problème ici est que XZ est utilisé par plein de logiciels...
L'article est intéressant pour ce qu'il raconte de la gestion d'une faille et des perspectives pour que le libre soit moins vulnérable.
3
Nouvelles du projet openSUSE / Re : News openSUSE : Ce que nous devons retenir de la porte dérobée XZ
Détrompe toi, en lisant tout l’article, tu verras que c’était openSSH qui était visé et qui est utilisé par beaucoup de distributions Linux. Il a été clair dès le début que c’était openSSH utilisé par Linux qui était visé. Le fait que ce soit un ingénieur de chez Microsoft n’implique pas que Microsoft soit visé, cet ingénieur est aussi un développeur de la communauté PostgreSQL, il contribue à un logiciel open source.
Les serveurs sont souvent sur Linux, il y a des tas d’utilisations de Linux dans les entreprises, les administrations,…
5
Nouvelles du projet openSUSE / Re : News openSUSE : Ce que nous devons retenir de la porte dérobée XZ
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é !
6
Nouvelles du projet openSUSE / News openSUSE : Ce que nous devons retenir de la porte dérobée XZ
Dirk Müller, un des responsable sécurité chez SUSE, revient sur la découverte de la porte dérobée XZ et sa gestion.
source : https://news.opensuse.org/2024/04/12/learn-from-the-xz-backdoor/
traduction automatique en ligne ci-dessous en deux messages car l'article est trop long pour un seul ;)
Ce que nous devons retenir de la porte dérobée XZ
12. avril 2024 | Dirk Müller | CC-BY-SA-3.0
Beaucoup de choses ont été écrites sur la porte dérobée XZ ces dernières semaines, il est donc temps de regarder vers l'avenir. Avant de le faire, nous partageons plus de détails sur ce qui s'est passé concernant openSUSE. Pour un aperçu de la manière dont cela a affecté les utilisateurs d'openSUSE, veuillez vous référer au message précédent [on en a parlé sur le forum ici et là ] .

Dans les coulisses
Quelques jours avant la divulgation publique de la porte dérobée XZ, l'équipe de sécurité des produits SUSE a eu un indice selon lequel il y avait quelque chose d'étrange dans les versions XZ 5.6.x. Je suis l'employé de SUSE et le packager openSUSE qui mettait à jour et incluait cette version dans openSUSE Tumbleweed, je me suis donc impliqué assez tôt. À ce moment-là, aucun contexte ni aucune information partagée lors de la divulgation publique initiale n’étaient disponibles. Cependant, cet indice était toute l’information dont nous avions besoin. Cela a changé notre façon de considérer un projet open source central et établi. Sans cela, les petites différences étranges dans l'étape de « configuration » du système de construction auraient été facilement ignorées.
Un jour avant la divulgation, jeudi soir, la sécurité des produits SUSE a reçu un rapport plus long et détaillé d'Andres Freund via la liste de divulgation de sécurité des distributions partagées. La liste de distribution est une liste de diffusion cryptée où les distributeurs collaborent et se coordonnent sur la divulgation de problèmes de sécurité. Ce rapport a apporté de nouvelles connaissances selon lesquelles la porte dérobée XZ ciblait spécifiquement OpenSSH, qui est l'une des parties réseau de presque tous les systèmes Linux. Cela a encore accru notre niveau de menace d'être une porte dérobée d'accès à distance et nous a également amené à élargir nos efforts de communication prévus.
L'équipe de sécurité SUSE et moi avons commencé à analyser. La sécurité des produits SUSE est membre de divers forums de sécurité privés, comme la liste des distributions et CERT VINCE et autres, qui nous permettent de coordonner les correctifs entre les fournisseurs de logiciels et de préparer les mises à jour aux dates de divulgation. Avec les premières informations indiquant qu'il y avait quelque chose de suspect, il était relativement facile de trouver des éléments plus suspects sans ordre particulier :
  • openSUSE et SUSE suivent les signatures d'artefacts de publication avec un trousseau de signatures fiables. Nous avons remarqué que la clé avec laquelle les artefacts étaient signés avait changé il y a quelque temps, nous avons donc dû mettre à jour notre trousseau de confiance pour le projet XZ. Nous avons vérifié qu'il y a eu un transfert de responsabilité entre le responsable et que le nouveau responsable a un accès direct aux validations ainsi que la possibilité de signer les versions et de les publier. Le réseau de confiance de cette nouvelle clé de signature n'était pas bien connecté, ce qui aurait pu déclencher une alerte, mais elle était signée par le précédent mainteneur et cela nous suffisait.
  • En regardant l'historique des commits, il y a eu une vague de commits entre la dernière version bêta 5.5 et la version 5.6.0 dans un court laps de temps par ce nouveau responsable ; ne vient pas via une Pull Request et aucun examen ou discussion évident à ce sujet. C’était immédiatement préoccupant. Normalement, les projets ne font pas cela juste avant une nouvelle version majeure. L'examen de chaque validation a immédiatement montré que des fichiers de test étranges étaient validés et mis à jour dans la version 5.6.1, et qui n'avaient pas de mises à jour correspondantes dans le cadre de test ou dans le code du projet, ils étaient donc « inutilisés ». Normalement, les fichiers de test sont validés avec un correctif de code dans la même validation, ou avec une référence à un problème antérieur, ou à une validation abordée par le scénario de test. Pour un responsable expérimenté d’un projet en amont, cela semblait être un gros oubli. Les messages de validation étaient en quelque sorte plausibles mais n'avaient pas vraiment de sens, surtout si l'on compare les (petites) différences entre 5.6.0 et 5.6.1.
Une enquête plus approfondie a permis de trouver le « étape zéro » intégré dans le système de construction et, grâce à cela, nous avons pu franchir les couches de dissimulation pour démêler les deuxième et troisième étapes. En quelques minutes, il nous est apparu clairement que des efforts très importants avaient été consacrés à son développement. Ce n’était pas le travail d’un seul développeur par un dimanche après-midi pluvieux. En outre, la deuxième étape a laissé entendre qu'il s'agissait d'une porte dérobée spécifiquement destinée à des environnements spécifiques, aux builds de packages Debian ou RPM utilisant GCC et glibc. Un utilisateur normal construisant à partir des sources, soit à partir de l'archive tar détournée, soit à partir de git n'aurait jamais été affecté. Cela a sonné l’alarme. Ainsi, avant d’aller plus loin dans l’ingénierie inverse, nous avons évalué l’impact.
Depuis un certain temps, openSUSE n'utilise pas XZ pour la compression de nos packages RPM de distribution ; nous sommes passés à Zstd il y a quelque temps. Cependant, XZ est très largement utilisé dans la distribution, entre autres pour décompresser les sources de notre compilateur GCC que nous utilisons pour construire tout le reste de la distribution. Nous avons vérifié et constaté que la version potentiellement malveillante de XZ était utilisée pour créer notre compilateur actif openSUSE GCC, qui est utilisé dans toutes les autres versions de la distribution. Le pire des cas auquel penser ici est que le déballage des sources de construction du compilateur GCC a été modifié par le XZ malveillant et que nous avons un compilateur système qui n'est plus digne de confiance. Bien que nous ayons des vérifications de signature sur les sources (et que nous ayons sécurisé des copies de chaque entrée de source que nous avons utilisée n'importe où dans un magasin de confiance), nous ne vérifions pas si les sources décompressées sont réellement les sources dont la signature a été vérifiée avant le déballage.
Ainsi, même sans plus d’informations sur la porte dérobée, nous avons compris que l’impact dans le pire des cas pourrait être désastreux. Nous avons donc commencé à identifier les projets, produits et distributions concernés. Heureusement, cette liste s’est avérée assez restreinte. Une équipe ad hoc a été constituée pour gérer la suppression de la porte dérobée.

Suppression initiale de la porte dérobée pour nos utilisateurs
openSUSE Tumbleweed fournit un canal de mise à jour d'urgence que nous pouvons utiliser pour récupérer des régressions fatales dans les instantanés Tumbleweed réguliers. Ces phénomènes sont extrêmement rares grâce à notre pipeline de tests automatisés, mais ils surviennent. Nous avons injecté une rétrogradation de XZ dans ce canal de mise à jour d'urgence et avons commencé à créer une version intermédiaire d'instantané openSUSE dans laquelle la mise à jour malveillante de XZ a été supprimée. Cependant, en raison de la nature inconnue de la porte dérobée obscurcie, nous avions prévu la pire hypothèse. Nous avons commencé à collecter le nombre de packages qui ont été construits et publiés avec la construction du compilateur GCC suspect dans l'environnement de construction. C'était une très longue liste. De plus, comprendre l’inversion du code objet malveillant de la porte dérobée dans Ghidra nous prendrait encore quelques heures. Après une courte synchronisation, nous avons décidé d'opter pour la voie sûre et de jeter tous les paquets construits avec XZ/GCC potentiellement malveillants et avons commencé à les reconstruire tous avec uniquement les paquets provenant d'une sauvegarde sécurisée, pour restaurer l'intégrité de notre distribution le plus rapidement possible. openSUSE teste régulièrement ce « mode bootstrap » dans le cadre du développement de notre distribution et s'appuie sur l'automatisation de la reconstruction fournie par l' Open Build Service , ce n'était donc pas beaucoup de travail humain. C'était juste beaucoup de charge pour notre cluster de build. Nous avons attendu quelques heures devant nous, ce qui a permis une analyse plus approfondie de la porte dérobée.

Analyse de la porte dérobée
L’analyse du code objet s’est avérée prendre beaucoup de temps. Même si la deuxième étape qui vérifiait les bonnes conditions de build (s'agit-il d'une version de distribution, dispose-t-elle de l'environnement de compilateur attendu, etc.) était facile à décoder et nous a aidé à comprendre l'impact potentiel, au départ, nous ne savions pas vraiment quoi. le code objet obscurci qui a été injecté lors de la construction fonctionnait.
En utilisant Ghidra, nous avons pu récupérer du code C quelque peu lisible à partir du code machine injecté, nous avons donc commencé à essayer de déchiffrer le puzzle. Repérer le point d'entrée dans la _get_cpuid fonction qui faisait partie de la gestion IFUNC a été l'une des premières découvertes. Le simple fait de rechercher cette combinaison de mots sur Google a conduit à une discussion en amont, à la désactivation d'ifunc dans le projet oss fuzz et à un rapport de bug intéressant dans la communauté Fedora où des problèmes de Valgrind ont été signalés avec XZ 5.6.0 et apparemment, l'amont les corrigeait en mettant à jour. des choses sans rapport, y compris « les fichiers de test » dans le référentiel. Il y avait non seulement des commits dans le dépôt, mais aussi une communication trompeuse autour du problème directement lié à ces commits, ce qui montrait évident que nous ne trouvions pas un accident malheureux provoqué par un responsable innocent qui aurait pu être piraté, mais une action planifiée de la part du responsable actuel. responsable en amont. Juste au cas où les sonnettes d'alarme ne seraient pas déjà assez fortes, cela a doublé leur niveau sonore.

Préparation à la divulgation publique
En combinant tout ce que nous avons appris jusqu’à présent, le tableau est devenu plus clair. Quelqu'un avait passé des années de préparation à préparer le terrain, à se bâtir une bonne réputation de mainteneur, à reprendre le projet, puis à choisir un moment qui était une fenêtre critique pour plusieurs projets de distribution et également au milieu du Nouvel An lunaire. comme d'autres jours fériés pour publier une nouvelle version avec de nouvelles fonctionnalités et une porte dérobée obscurcie qui a été bien conçue pour cibler uniquement des distributions spécifiques, à savoir celles utilisant GCC, Binutils, Glibc avec RPM ou les processus de construction Debian sur x86_64.
En gardant tout cela à l’esprit, nous avons réalisé que ce sujet allait faire l’objet d’une grande couverture publique. Cela fera la une des journaux pendant des jours, voire des semaines. Nous avons donc lancé un nouveau chantier pour nous y préparer avec les équipes de communication.

Divulgation publique
Au moment de la divulgation publique, tous les axes de travail étaient déjà terminés. Nous avons identifié la liste des produits concernés et avons déjà publié toutes les mises à jour pour tous les produits concernés. La communication était prête à être mise en ligne et envoyée aux parties concernées. Tout cela a été possible parce que de nombreuses personnes se sont surpassées, ont mis tout le reste de côté pour réagir en temps opportun et avec beaucoup d'engagement pour s'assurer que nous n'avons rien manqué ou négligé ; tout cela alors qu'un long week-end férié avait déjà commencé. Félicitations à tous ceux qui ont travaillé 24 heures sur 24 pour préparer cela.

Héros de l'histoire
Si rien de pire ne s'est produit, c'est uniquement grâce à Andres Freund, un développeur de la communauté PostgreSQL, qui n'a pas ignoré une étrange régression des performances des connexions SSH sur son installation instable Debian récemment mise à niveau. Un autre témoignage selon lequel ne pas abandonner quelque chose que tout le monde aurait probablement ignoré au cours des mois ou des années à venir est ce qui fait d'un héros un héros.
Toutefois, s’appuyer sur des héros n’est pas une stratégie durable et fiable. Donc, pour l’avenir, nous devons tous tirer les leçons de ce qui s’est passé et devenir une grande équipe de petits héros.
La photo sur cet article a été prise par Matthias Pastwa et utilisée sous CC-BY-ND 2.0 DEED
7
Nouvelles du projet openSUSE / Du changement pour les fonds d'écran
openSUSE annonce un changement de format du fond d'écran par défaut qui passe de jpeg à png afin d'utiliser la même chose que SUSE. Le changement aura lieu lors d'une mise à jour, il est conseillé de se déconnecter de sa session puis de se reconnecter si on utilise le fond d'écran par défaut d'openSUSE. Il est prévu de proposer de nouveaux fonds d'écran à la suite de ce changement.
source : https://news.opensuse.org/2024/04/09/common-wallpaper-path/

Traduction fr automatique en ligne ci-dessous
Le fond d'écran par défaut a un chemin commun entre openSUSE et SUSE
9. avril 2024 | Lubos Kocman | CC-BY-SA-3.0

Nous utiliserons désormais png pour le fond d'écran par défaut défini sur openSUSE Tumbleweed et les prochaines versions d'openSUSE Leap et Leap Micro .
La raison de cette décision est l'unification des fonds d'écran avec SUSE Linux Enterprise via un lien symbolique de compatibilité, car le format devait être le même. SLES et SLED utilisent PNG depuis le dernier changement de nom dans SLE 15 Service Pack 3 et openSUSE utilise JPG jusqu'à présent.
L'utilisation d'un chemin de fond d'écran par défaut commun permet aux applications utilisant un fond d'écran ou une marque système similaire d'être réexécutées sur SLES et openSUSE sans avoir besoin d'être reconstruites.
Le petit prix pour l'utilisation du format sans perte est une légère augmentation de la taille, cependant, nous utilisons optipng, donc elle se situe dans les unités de mégaoctets pour toutes les résolutions de fonds d'écran combinées.
Code: [Sélectionner]
ls -la /usr/share/wallpapers/openSUSEdefault/contents/images/1600x1200.png -rw-r--r-- 1 root root 417791 Apr 5 13:14 /usr/share/wallpapers/openSUSEdefault/contents/images/1600x1200.png
Code: [Sélectionner]
ls -la /usr/share/wallpapers/SLEdefault/contents/images/1600x1200.png -rw-r--r-- 1 root root 417791 Apr 5 13:14 /usr/share/wallpapers/SLEdefault/contents/images/1600x1200.png
Code: [Sélectionner]
ls -la /usr/share/wallpapers/SLEdefault lrwxrwxrwx 1 root root 15 Apr 5 13:15 /usr/share/wallpapers/SLEdefault -> openSUSEdefault

Nous avons également fourni une nouvelle icône apple-touch , qui faisait partie des logos de la distribution SUSE Linux Enterprise et qui manquait du côté openSUSE.
Puisqu'il s'agit en fait d'un changement de fond d'écran par défaut, nous recommandons aux utilisateurs qui utilisent le fond d'écran par défaut de se déconnecter et de se connecter pour éviter tout problème. Veuillez vous assurer que le système a pu relire
Code: [Sélectionner]
/usr/share/wallpapers/openSUSE-default-static.xml
La bonne nouvelle à ce sujet est que nous prévoyons de proposer une nouvelle collection de fonds d'écran pour openSUSE Leap 16 ainsi que pour openSUSE Tumbleweed, qui n'a pas vu de changement de fond d'écran depuis un certain temps ; considérez-le simplement comme un joli petit exercice d’incendie.
8
Installation et boot / Re : ecran figé tumbleweed kde
Mais on parle aussi sur le forum francophone de ce bug avec ton fil ;)  D'ailleurs, tu peux éditer ton titre dans le premier message si tu veux.
Il y a un nouvel instantané 20240404 avec une maj de mesa mais pas sûr que ça règle ton souci.
9
Matériel / Re : clé USB en lecture seule
Bonjour,
Avoir une clé qui passe en lecture seule peut être le signe d'un système de fichiers endommagé, ça peut arriver par exemple si on n'éjecte pas une clé correctement. Si elle passe d'un système windows à un système linux, ça peut arriver aussi. Windows m'a recemment demandé de vérifier le système de fichiers, si c'est ton cas, tu peux vérifier si windows te le propose.
Sinon, si tu n'utilises que Linux, tu peux t'inspirer de tutos :
https://doc.ubuntu-fr.org/tutoriel/comment_reparer_clef_usb
https://www.cedric-augustin.eu/index.php?post/2022/12/31/Clee-USB-en-lecture-seule-sous-Linux

Dans la mesure où on n'a pas la clé et aucun retour de commande, c'est compliqué d'être plus précis. Je pense qu'avec ces deux liens, tu devrais trouver des pistes pour t'en sortir et ce qui serait sympa, ce serait de nous faire un retour de ce qui a marché (ou pas) ;)
13
Installation et boot / Re : ecran figé tumbleweed kde
Quand tu dis que tu refais une installation, est-ce que tu écrases ton home ?
Tu n'aurais pas un fichier caché de configuration de sddm  qui mettrait le bazar ?
ou alors ce serait une incompatibilité de TW avec le matériel ? de la version du kernel ? avec la carte graphique ?

As-tu essayé un autre gestionnaire de session, comme gdm ou lightdm ?
tu dois pouvoir faire le changement de gestionnaire de session depuis la console tty.

Edit : as-tu le dépôt packman ? les drivers graphiques de ce dépôt ? Ton problème ressemble à celui-ci :
https://forums.opensuse.org/t/after-tw-update-i-cant-enter-anything-at-login-screen/173701/9
c'est peut-être toi d'ailleurs ?
des bugs sont déclarés pour radeon (avec sddm ?):
https://bugzilla.suse.com/show_bug.cgi?id=1222156
j'ai pas tout lu
14
Installation et boot / Re : ecran figé tumbleweed kde
Bonjour,
En démarrant le PC, tu ne peux pas passer à une console tty ? Qu'est-ce qui pourrait expliquer ceci ? Une mise à jour interrompue ?
Tu es bloqué avec Gnome aussi ?
15
Sécurité / Re : Attention aux thèmes de Kde : ils peuvent effacer les données ...
Merci pour l'info !
Citer
Selon un article de Reddit cité par KDE, au moins un utilisateur a vu ses fichiers effacés après avoir installé l'un de ces thèmes Plasma globaux. Après son installation, le thème a supprimé toutes les données personnelles des lecteurs montés à l'aide de « rm -rf », une commande UNIX très dangereuse qui supprime de force et de manière récursive le contenu d'un répertoire (y compris les fichiers et autres dossiers) sans aucun avertissement ni demande de confirmation. Lorsque cette commande est utilisée pour supprimer des fichiers, ils sont définitivement effacés et ne peuvent être récupérés qu'à l'aide d'un logiciel de récupération de données ou restaurés à partir de sauvegardes. Bien que le thème global défectueux ait depuis été supprimé du magasin de KDE, tout autre thème global disponible via le référentiel de plugins officiel de KDE pourrait entraîner une perte de données si les développeurs ne les ont pas minutieusement testés avant de les soumettre.
C'est comme un écho de ce qu'il s'est passé avec le paquet xz.
En utilisant tel ou tel dépôt, tel ou tel fichier téléchargé, on doit avoir confiance dans celui qui fournit...
Moi qui m'accomode très bien du thème openSUSE, je change juste le fond d'écran du bureau pour une photo perso, je sens que ça ne va pas m'inciter à changer mes habitudes  ;)