Aller au contenu principal ↑ ↓

Sujets

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

Sujets - chalu

1
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
2
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.
4
Sécurité / Faille de sécurité dans le paquet xz sur Tumbleweed et MicroOS
On a parlé de cette faille ici. Je remets ci-dessous mon message :
Bonjour,
j’ai eu une notification rouge hier m’invitant à mettre à jour avec l’indication mise à jour de sécurité. Au moins les notifs sur plasma 6 fonctionnent.
C’est digne d’un film d’espionnage cette histoire. Le développeur Jian Tan (JiaT75 sur github) de code malicieux a préparé son coup depuis plusieurs années d'après ce que j'ai lu sur le net sur ce sujet. Tout d’abord en s’incrustant dans le projet et en évinçant le dev d’origine qui n’allait pas bien.
Et ensuite en insérant des bugs pour forcer la mise à jour, avec des comptes créés pour l’occasion par des gens ou lui pour faire pression et faire ces majs.
C’est un paquet intégré à systemd, on ne peut pas s’en passer, du moins l’utilisatrice lambda que je suis.
Il semble que si on n’utilise pas ssh, c’est moins inquiétant. Par contre la fin de l’annonce indique bien que si on l’utilise, il faut refaire une installation fraîche, le système (et les clés) risquant d’être compromis.
D’après certains, il pourrait y avoir d’autres « découvertes » dans le code. Le dev de code malicieux ayant pris la main depuis 2022 au moins…

Pour vérifier que vous avez la mise à jour avec les paquets corrigés :
Code: [Sélectionner]
zypper se -is xz liblzma 
Chargement des données du dépôt... 
Lecture des paquets installés... 
 
S | Name               | Type   | Version               | Arch   | Repository 
--+--------------------+--------+-----------------------+--------+------------------------------- 
i | liblzma5           | paquet | 5.6.1.revertto5.4-3.2 | x86_64 | Dépôt principal de mise à jour 
i | liblzma5-x86-64-v3 | paquet | 5.6.1.revertto5.4-3.2 | x86_64 | Dépôt principal de mise à jour 
i | xz                 | paquet | 5.6.1.revertto5.4-3.2 | x86_64 | Dépôt principal de mise à jour 
i | xz-lang            | paquet | 5.6.1.revertto5.4-3.2 | noarch | Dépôt principal de mise à jour
 
Notez le "reverto" qui indique le correctif.

Pour regarder si ssh est actif sur votre système (vous avez pu cocher lors de l'installation pour que ça le soit, même si vous ne l'avez pas utilisé. Il semble que le service est activé par défaut sur Aeon)
Code: [Sélectionner]
sudo systemctl status sshd
Chez moi j'ai :
Code: [Sélectionner]
○ sshd.service - OpenSSH Daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; preset: disabled)
     Active: inactive (dead)
qui indique que le service est désactivé (ouf !)
Rappel : il faut mettre à jour puis redémarrer
5
Programmes et logiciels / zypper-1.14.70 prendra en charge une nouvelle option : 'dup --remove-orphaned'
Bonjour à tous, :)
Cette annonce a été faite dans la mailing list Factory.
Actuellement, nous avons la version 1.14.68-1.4 de zypper sur notre TW, mais prochainement arrivera avec une mise à jour vers la version 1.14.70, une nouvelle option
Code: [Sélectionner]
sudo dup --remove-orphaned
qui permettra de supprimer les paquets orphelins inutiles, c'est-à-dire les paquets qui ne sont plus reliés à un dépôt (qui n'existent plus dans les dépôts que vous utilisez) et qui ne sont pas des dépendances d'autres paquets installés sur le système.
Attention à cette commande, il est tout à fait possible que des paquets soient installés sur votre système sans être reliés à un dépôt, par exemple des paquets téléchargés et installés "à la main" pour faire fonctionner une imprimante ou un scanner ! Dans ce cas, ils sont orphelins et considérés comme inutiles car ils ne sont des dépendances d'autres paquets. Dans ce cas, il faudra protéger ces paquets pour éviter une suppression,  via YaST ou avec la commande :
Code: [Sélectionner]
sudo zypper al nom-paquet-a-conserver

Dans le fil, il est indiqué, alternativement, la possibilité de créer un dépôt local pour que ces paquets ne soient plus considérés orphelins :
En root, créer un répertoire local
Code: [Sélectionner]
mkdir /LocalRepo 
zypper ar -f /LocalRepo LocalRepo
Mettre dedans les fichiers .rpm et ils ne seront plus considérés comme orphelins.

La commande utilisateur
Code: [Sélectionner]
zypper packages --orphaned
montre sur mon PC trois paquets orphelins
Code: [Sélectionner]
S | Repository | Name                  | Version        | Arch
--+------------+------------------------+----------------+-------
i | @System    | libabsl2301_0_0        | 20230125.3-3.1 | x86_64
i | @System    | libprotobuf-lite22_5_0 | 22.5-4.1      | x86_64
i | @System    | libprotobuf22_5_0      | 22.5-4.1      | x86_64
6
Contribuer à la communauté openSUSE / Des ateliers pour contribuer au projet openSUSE
Bonjour à tous :) ,
J'imagine que ceux intéressés par une contribution ne sont pas passés à côté de cette annonce. Ce sont des dates d'ateliers visant à permettre de contribuer efficacement, par exemple pour utiliser OBS, faire un paquet rpm ...
L'annonce est là : https://news.opensuse.org/2024/03/20/contribution-workshop-to-cover-rust/

Les vidéos des tutoriels sont disponibles sur la chaîne :
https://www.youtube.com/opensuse

Evidemment, c'est en anglais mais comme on l'a évoqué dans un autre fil, c'est la langue commune des contributeurs.
Pas de traduction de l'annonce donc mais vous pouvez toujours faire une traduction de l'annonce vous-même avec un traducteur en ligne ;)
7
Nouvelles du projet openSUSE / Plasma 6 arrive dans les versions d'openSUSE
Bonjour à tous  :)
Nous avons déjà parlé sur le forum de l'arrivée de Plasma 6 sur Tumbleweed, elle est arrivée également dans kalpa qui est la version d'openSUSE MicroOS avec le bureau KDE alors que Aeon est celle avec Gnome. Il n'est pas question dans cette annonce de la sortie pour Leap 15.6. Donc wait and see pour cette dernière  ;)
Ci-dessous la traduction automatique de l'annonce dont la source en anglais est ici : https://news.opensuse.org/2024/03/22/plasma-arrives-in-os-distributions/

J'ajoute que certaines des issues de Plasma 6 lors de sa sortie ont été corrigées dans la mise à jour 6.0.2 déjà publiée.

Plasma arrive dans les versions d'openSUSE
Beaucoup d'enthousiasme couvait lors de l'annonce de la sortie de Plasma 6 de KDE et maintenant la MegaRelease est arrivée dans openSUSE Tumbleweed et Kalpa tandis que les plans pour Slowroll progressent.

Les utilisateurs de la version continue (rolling) et la communauté des développeurs bénéficient d'une mise à niveau qui marque un changement monumental pour les utilisateurs de bureau KDE . La mise à jour deviendra une version Slowroll en avril, car des changements de version au rythme régulier sont attendus entre le 2 et le 14 avril.

Près d'une décennie après la sortie de Plasma 5 , l'expérience de bureau pour Plasma 6 commence. La transition signifie non seulement un progrès en termes d'esthétique et de fonctionnalité, mais souligne également l'engagement d'openSUSE à fournir cette technologie très attendue à ses utilisateurs.

Plasma 6 introduit une tonne d'améliorations et de fonctionnalités qui s'adressent à un large éventail d'utilisateurs ; du passionné de technologie à l'utilisateur occasionnel. La mise à jour envisage des changements majeurs sous le capot comme une transition vers le dernier cadre d'application Qt et une migration vers le protocole de serveur d'affichage Wayland qui est défini comme session graphique par défaut. Cependant, à l'heure actuelle, il est important de noter que la session Wayland n'est pas encore la session par défaut dans Tumbleweed ; cette décision permet aux utilisateurs et aux développeurs de discerner si les problèmes rencontrés proviennent de Plasma 6 lui-même ou de la session Wayland. Kalpa, le dérivé de bureau KDE de Tumbleweed , prévoit de passer par défaut à Wayland .

Les développements incluent une sécurité améliorée, des performances et une prise en charge matérielle moderne améliorée.

Malgré ces changements importants, les utilisateurs devraient trouver l'environnement Plasma 6 familier, conservant l'apparence classique de KDE tout en jetant les bases des innovations futures.

La nouvelle version propose des fonctionnalités telles qu'une vue d'ensemble et des effets de grille sur le bureau ; Il améliore les gestes du pavé tactile et la prise en charge partielle du High Dynamic Range (HDR) sur Wayland, qui, combiné au nouveau fond d'écran « Scarlet Tree », transforme le bureau en un espace de travail  attrayant et animé.

Plasma 6 introduit des changements visant à améliorer l'expérience utilisateur, notamment un changement dans les paramètres par défaut. Notamment, il adopte une action d'un simple clic pour sélectionner les fichiers et dossiers et une action de double-clic pour les ouvrir. Bien que l'approche en un seul clic rationalise le processus d'ouverture, elle peut être moins intuitive pour les utilisateurs habitués à d'autres systèmes et pourrait compliquer la sélection de plusieurs éléments. Le double-clic, cependant, est plus familier à ceux qui migrent depuis différents systèmes et offre une facilité d'utilisation connue lors de la sélection d'éléments.

Bien que la transition vers Plasma 6 promette de nombreux avantages, quelques problèmes mineurs ont été identifiés dans l'instantané. Aucun n’a été jugé suffisamment grave pour retarder sa sortie.

Ces issues connus incluent :
  • Paramètre du thème GTK pour les nouvelles installations : certains utilisateurs peuvent trouver que le thème GTK n'est pas défini correctement. Une solution de contournement consiste à le définir manuellement dans les paramètres système ou à exécuter « kded5 » une fois.
  • Changement d'icône du lanceur pour les mises à niveau : les utilisateurs mettant à niveau leur système peuvent remarquer que l'icône du lanceur est par défaut l'icône Plasma. Cela peut être ajusté manuellement en changeant l'icône en « commencer ici la marque ».
  • Mises à niveau à partir de systèmes plus anciens : un problème connu affecte les utilisateurs effectuant une mise à niveau à partir des versions 15.3 ou antérieures de Leap liées à un package appelé « libksysguard5-helper ». La solution recommandée est d’opter pour la désinstallation du package problématique.
  • Délai de démarrage de Plasmashell : les utilisateurs sans matériel Bluetooth peuvent rencontrer un retard au démarrage de Plasmashell si kdeconnect-kde est installé, ce qui peut être atténué en désactivant l'icône de la barre d'état système de KDE Connect.

Alors qu'openSUSE continue d'évoluer avec Plasma 6, Tumbleweed, Kalpa et Slowroll restent déterminés à fournir des systèmes nouveaux, stables et mis à jour à la communauté open source mondiale.
L'équipe d'empaquetage d'openSUSE KDE encourage les utilisateurs à adopter cette nouvelle phase, à explorer les riches fonctionnalités de Plasma 6 et à fournir des commentaires pour aider à affiner les futures versions. L'aventure ne fait que commencer pour Plasma 6 et nous invitons les gens à s'engager dans le développement de logiciels open source et à « s'amuser » dans ce voyage vers une nouvelle ère de l'informatique de bureau.
10
Programmes et logiciels / aperçu lors de l'impression sur okular
Bonjour,
En cliquant sur "imprimer" dans okular, je n'ai pas d'aperçu du document que je veux imprimer.
J'ai noté aussi que le menu aperçu avant impression a un bug et n'affiche pas ce qu'il faut le plus souvent, il fait planter même parfois okular.
Est-ce la même chose chez vous ? (PC et système en signature)
11
Nouvelles du projet openSUSE / 8 juin 2022 : sortie de Leap 15.4
Bonjour à tous :)

Leap 15.4 est sortie aujourd'hui.
La particpation des utilisateurs pour la recherche et corrections des bugs est importante.
Pour participer, n'hésitez pas à vous créer un compte qui vous permettra de vous connecter sur le wiki, le bugzilla et weblate et  sur le forum officiel international...
Les pages sur lesquelles la communauté Alionet d'openSUSE intervient pour la sortie de Leap 15.4, il s'agit de traduire les annonces et informations du wiki en anglais ;) :
Comme vous le constaterez, l'annonce n'est pas encore traduite donc si quelqu'un veut participer, ce serait super 👍

12
Programmes et logiciels / openBoard sur Tumbleweed
Bonjour,
Actuellement, il n’est plus possible d’installer la version d’openBoard du dépôt éducation car des dépendances de la version 1.6.1 d’openBoard ont été supprimées des dépôts openSUSE.
Citer
nothing provides pkgconfig(Qt5WebKit), nothing provides pkgconfig(Qt5WebKitWidgets)
Si vous en avez besoin, vous pouvez installer la version 1.7 qui est encore expérimentale mais ne semble pas trop bugguée et qui a le mérite de ne plus avoir besoin des paquets supprimés.Le dépôt est maintenu par la même personne que le dépôt éducation, on peut lui faire confiance.
https://build.opensuse.org/package/show/home:letsfindaway:experimental/OpenBoard

Pour ma part, j’avais installé openBoard avant la suppression des dépendances alors le paquet et les dépendances restent installés, par contre je n’ai pas intérêt à faire un nettoyage de paquets orphelins 😉

Il n’y a pas de souci pour Leap 15.3.
13
Général / Installer une ancienne application sur iPad/iPhone ancien. récupérer les photos
Bonjour à tous,
Je possède un iPad dont le système iOS est en version 12.5.5
Il ne peut plus évoluer vers une version récente d'iOS, il a une dizaine d'années mais il fonctionne très bien !
Avec un PC sous Windows 10, on peut récupérer facilement ses photos et aussi installer une version d'une ancienne appli de l'appstore qui demande une version plus récente d'iOS. Seulement en démarrant le PC sous Windows, voilà t'y pas que les plombs sautent ... je pense qu'un ventilo ou l'alimentation est fichu  :( !  Et alors comment faire quand on ne dispose plus que d'un PC sous Linux, openSUSE Tubleweed pour moi ? :o 
Ma solution a été d'utiliser virtualbox avec le pack d'extension pour gérer l'USB, d'installer Windows 10 (gratuit à installer et utiliser si ce n'est pas un vrai PC) puis d'installer le logiciel iTunes version 12.6.4 pour gérer depuis Windows les apps de mon iPad (ou sur iPhone, ça devrait fonctionner aussi)

Voici tous les détails et mes sources.
  • Installation de virtualbox depuis les dépôts officiels openSUSE avec YaST, je suis sous KDE donc j'ai choisi le paquet virtualbox-qt.
  • Si c'est la première utilisation de virtualbox, il faut ajouter votre utilisateur au groupe vboxusers avec la commande en root
    Code: [Sélectionner]
    usermod -aG vboxusers nom-utilisateur
    Il faut fermer la session utilisateur et la rouvrir pour que ce soit pris en compte.
  • Installation du paquet d'extension qui va avec la version de virtualbox. On télécharge le paquet sur le site de vitualbox avec un navigateur internet en faisant bien attenbtion de prendre la version qui correspond à notre version de virtualbox. Une fois le téléchargement terminé, on démarre virtualbox. Dans Fichier > Paramètres > Extensions, on clique sur le bouton + puis on navigue jusqu'au dossier au où a téléchargé le pack, on le sélectionne pour l"'installer, le mot de passe root est demandé.
  • On crée ensuite une machine virtuelle pour windows10 en sélectionnant la configuration :
    • Type : Microsoft Windows et Version : Windows 10 (64bits)
    • Régler la quatité de RAM à 4096 Mo si c'est possible, le minimum est à 2048 mais ça risque de faire peu.
    • Créer un disque virtuel vdi dynamiquement alloué de 75 Go pour être confortable (ça ne prend pas toute cette place car c'est dynamiquement alloué, pour moi c'est à peine 15 Go pour l'instant)
  • On affine les réglages de la vm en la sélectionnant puis Configuration
  • Onglet Système : dans Général on peut décocher la disquette, pour le chipset j'ai choisi ICH9. Dans Processeur : mettre 2 CPU si possible et dans accélération mettre Hyper-V et laisser cocher "activer la pagination imbriquée"
  • Onglet affichage : le maximum de Mo pour la mémoire video et cocher acceleration 3D
  • Onglet Stockage : sélectionner le lecteur de disque "vide", cliquer sur "choisir un fichier disque" en bout de ligne de"lecteur optique" et naviguer jusqu'au dossier contenant l'ISO de windows 10 que vous aurez préalablement téléchargé depuis le site : https://www.microsoft.com/fr-fr/software-download/windows10ISO en sélectionnant l'édition puis la langue. Choisir ensuite le lien 64-bits qui est proposé. C'est une ISO qui fait 5,5 Go à peu près.
  • Onglet Dossiers partagés : On sélectionne Dossier permanent ou dossier temporaire et on clique sur le bouton + puis sur "Autre" dans chemin du dossier pour sélectionner un dossier du disque dur, Images par exemple ouun dossier créé spécialement.
Une fois l'ISO sélectionnée dans le lecteur optique, fermer la fenêtre de configuration de virtualbox et démarrer la machine virtuelle pour installer windows 10.
Bon à savoir :
On passe la saisie de la clé produit, ça pose pas de problème dans une machine virtuelle.
On évite l'obligation de créer un compte utilisateur distant avec compte microsoft lors de l'installation en désactivant la carte réseau dans les périphériques ce qui coupe internet et oblige à la création d'un utilisateur local.

Récupération des photos :
Une fois l'installation faite et la vm windows 10 opérationnelle.
Je branche l'iPad déverrouillé sur le PC et on coche dans la vm windows Périphériques > USB iPad. Sur l'écran de l'iPad il faut autoriser la connexion avec l'ordinateur.
On ouvre ensuite l'explorateur de fichiers de Windows et on accède à l'iPad et à son répertoire DCIM où on peut copier les photos et vidéos pour aller les coller dans notre dossier partagé et ainsi y avoir accès depuis openSUSE.

Installation d'une ancienne application plus disponible sur l’Appstore alors qu’une version compatible avec notre version d’iOS a existé :
Pour installer une application qui n'est plus disponible pour notre version d'iOS et que l'on n'a jamais installée, mais dont une version compatible a pourtant existé, on peut procéder ainsi :
L'iPad n'est pas connecté au PC. Je veux installer sur mon iPad l'application PressReader qui n'est plus disponible qu'à partir d'iOS 13. C'est une application ancienne, des versions ont été créées pour iOS 12, mais elles ne sont pas proposées dans l'Appstore de l'iPad.
On installe dans la vm windows la version 12.6.4 d'iTunes qui fonctionne sous Windows 10 64bits et permet de gérer les applications de l'iPad.
On lance iTunes > Compte et on s'identifie avec son compte apple, il a fallu que je confirme que c'était bien moi sur l'iPad.
Une fois identifié, on éteint l'iPad pour que la suite fonctionne.
On ouvre iTunes sur la vm.
On clique sur "store" (à droite de Radio), on cherche l'apps, dans mon cas pressreader.
Elle apparait avec un bouton "obtenir". On clique sur ce bouton. Une fois qu'elle est téléchargé dans iTunes, on ne pourra rien en faire mais ça permet lorsque l'on rallume l'iPad et que l'on va dans l'AppSore de rechercher l'apps Pressreader.
Elle apparait avec "un nuage" comme les applications que l'on a déjà installé puis désinstallé.
En cliquant sur le bouton pour installer, on a un message qui nous demande si on souhaite installer la dernière version compatible.
Et voilà 8)

Les sources :
https://tutorielsgeek.com/comment-installer-windows-dans-virtualbox-sous-linux/
https://www.commentcamarche.net/mobile/ios/791-installer-des-applis-sur-iphone-ou-ipad-avec-une-ancienne-version-d-ios/




14
Nouvelles du projet openSUSE / IRC : openSUSE migre vers libera.chat
Bonsoir,
Si vous utilisez parfois les canaux IRC d’openSUSE sur freenode, il va y avoir du changement. Une migration de freenode vers libera.chat est programmée pour les jours qui viennent.
https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/LCFCHULXR6774YKWKX5ASKQG3ABN6B3P

Le réseau IRC Freenode a récemment été déserté par ses administrateurs qui ont fondé un nouveau réseau, suite à un conflit avec le propriétaire du nom de domaine de Freenode. Plusieurs projets ont fait le même choix qu’openSUSE.
15
Nouvelles du projet openSUSE / Leap 15.3 arrive bientôt... Elle est sortie maintenant !
Bonjour à tous :)

Dans un mois environ, Leap 15.3 sortira !
C'est la dernière ligne droite pour les traductions des annonces et du wiki.
Pour participer, n'hésitez pas à vous créer un compte qui vous permettra de vous connecter sur le wiki, le bugzilla et weblate et même je crois sur le forum officiel...
Les pages sur lesquelles la communauté Alionet d'openSUSE intervient pour la sortie de Leap 15.3, il s'agit de traduire les annonces et informations du wiki en anglais ;) :