Planète Warez

Dans le monde Linux, on entend parler des serveurs graphiques X11 et Wayland depuis longtemps. Mais de quoi s’agit-il exactement ? À quoi sert un serveur graphique ? Quelles sont les promesses de Wayland et pourquoi la migration prend autant de temps ? Nous vous proposons d’y voir plus clair.

Présentons les deux protagonistes de notre sujet. D’un côté, le X Window System. Sa première version date de 1984, en tant que projet développé au sein du MIT. Il a été essentiellement pensé à une époque où l’on trouvait des serveurs informatiques puissants et des clients légers, d’où son appellation de serveur, qui lui est resté.

On le connait mieux aujourd’hui sous son nom de X11. L’appellation vient de la onzième version de X, sortie en 1987. Ce fut la première révision à être considérée comme stable et pleinement opérationnelle. Et oui, techniquement, on utilise cette onzième version depuis 35 ans. Mais dans la pratique, les évolutions ont été continues.

De l’autre côté, on a Wayland. Beaucoup plus récent, le projet a été lancé en 2008 par Kristian Hogsberg, développeur chez Red Hat. Objectif, proposer un protocole moderne et gagnant sur toute la ligne : plus sécurisé, plus efficace et surtout plus simple. Une base neuve, capable d’exploiter beaucoup mieux le matériel qui avait largement évolué et de se débarrasser des vieilles assises de X11.

Qu’est-ce qu’un serveur graphique ?

Penchons-nous maintenant sur ce qu’est un serveur graphique (ou d’affichage), le rôle que tient ce composant et ses principaux attributs.

Commençons par le commencement. Sur un système de type Unix, dès que vous voyez quelque chose s’afficher à l’écran au sein d’une interface graphique, c’est que le serveur d’affichage est impliqué. Ce composant crucial est chargé de dessiner les fenêtres à l’écran et de gérer toutes les interactions qui s’y rapportent, ainsi que la composition de l’ensemble (assemblage des fenêtres). Il est une interface entre l’utilisateur, l’interface et le matériel lié. Il va d’ailleurs plus loin que le seul aspect graphique, puisqu’il s’occupe également des entrées de la souris et du clavier.

Au départ, l’architecture graphique était monolithique. Le serveur d’affichage devait avoir un accès complet, direct et exclusif à la carte graphique. Dans ce contexte, les pilotes – qui gèrent toute l’exploitation du matériel – étaient placés en espace utilisateur, sans accès direct au noyau. Une approche a priori sécurisée, mais qui s’est progressivement révélée peu efficace dans de nombreux scénarios. Toute la logique critique de l’affichage se retrouvait gérée par un composant unique qui embarquait tous les pilotes nécessaires.

Plusieurs composants sont donc apparus avec le temps pour répartir ce fonctionnement et répondre aux problématiques. D’abord le DRM, ou Direct Rendering Manager. En tant que sous-système du noyau Linux, il gère les accès au GPU. Il tient un rôle d’arbitre : il s’occupe avant tout de distribuer les ressources graphiques aux applications, gère la mémoire ainsi que la sécurité. Grâce à lui, les applications ont pu obtenir un accès direct au GPU (sans passer par X) et l’exploiter, avec une hausse majeure des performances.

Fedora a été la première distribution majeure à passer sur Wayland par défaut

Quelque part dans le noyau

Le KMS, ou Kernel Mode Setting, est un autre sous-système du noyau Linux. C’est à lui que revient la gestion de la résolution de l’écran, sa fréquence de rafraichissement, la profondeur des couleurs, etc. Il a permis de déplacer la logique de la « configuration de mode » de l’espace utilisateurs vers le noyau, avec plusieurs bénéfices importants. C’est grâce au KMS par exemple que la console a pu basculer en haute résolution dès le démarrage de la machine.

DRM et KMS s’utilisent à travers une bibliothèque (libdrm), qui expose des fonctions standardisées (et documentées) aux applications. L’arrivée de ces deux composants a été une étape majeure, avec une séparation nette entre la logique matérielle de bas niveau et celle d’affichage haut niveau, avec notamment tout l’applicatif, y compris le serveur graphique.

Au-dessus de DRM et KMS, on trouve un autre composant, important lui aussi, mais en espace utilisateur cette fois : Mesa. Si vous utilisez Linux, ce nom vous est peut-être familier. C’est une implémentation open source des API graphiques standard de l’industrie, comme OpenGL et Vulkan.

Prenons un exemple pour schématiser le fonctionnement général. Un jeu a des scènes 3D à faire afficher à l’écran. Il est conçu pour Vulkan et décrit donc ces scènes à l’API correspondante. Ces requêtes sont adressées à Mesa, qui s’occupe de traduire ces requêtes de haut niveau en instructions plus bas niveau, compréhensibles par le matériel. Ces instructions sont alors transmises au pilote DRM du noyau, qui les exécute sur le GPU.

Pourquoi un successeur à X11 ?

Si l’on se replace dans le contexte des jeunes années de X11, il n’était question que d’architecture client-serveur. Dans cette optique, X11 avait d’ailleurs été développé pour le réseau, avec certaines caractéristiques spécifiques. Par exemple, nulle obligation que le serveur X fonctionne sur la machine la plus puissante. Selon les cas, on pouvait faire tourner le serveur X sur un poste léger, et le client X sur un gros serveur.

Ce fonctionnement, ainsi que d’autres aspects tenant à des choix faits il y a plusieurs décennies, ont alimenté la réflexion qui a mené à Wayland. En matière d’efficacité d’abord, ce modèle client-serveur devenait un poids sur les machines plus récentes : le serveur et le client étant situés sur le même ordinateur, tout ce qui touche au réseau est inutile dans de nombreux cas. Les couches de communication et de multiples étapes intermédiaires (notamment codage/décodage) devenaient superflues et se payaient par une latence.

En outre, X11 est un vieux projet, avec une partie héritée dans le code de plus en plus importante. Ses capacités ont été augmentées par d’innombrables ajouts, extensions et patchs en une énorme base plus difficile à entretenir. Un immense patchwork qui a rendu les développements plus complexes au fur et à mesure que les besoins changeaient.

L’ensemble a abouti à un pipeline de traitement peu adapté aux applications et matériels modernes. Il n’a par exemple pas été conçu pour des écrans avec de hautes fréquences de rafraichissement et un rendu sans déchirement (tear-free). Pour ce dernier problème, il a fallu recourir à des solutions spécifiques et complexes, avec une synchronisation verticale forcée, qui a introduit elle-même de nouveaux problèmes dans certaines situations, comme un « bégaiement » de l’image (le fameux stuterring).

Ubuntu 25.10 avec GNOME 49 intègre toujours X11

Que propose Wayland ?

L’idée qui a mené à Wayland était de proposer un fonctionnement simple, sécurisé et plus efficace. Le tout en partant d’une page blanche.

Le plus gros changement réside dans la conception : le serveur d’affichage, le gestionnaire de fenêtres et le compositeur sont en fait un seul et même processus, le compositeur Wayland. Dans ce modèle, le compositeur gère l’intégralité des opérations liées à l’affichage. Il reçoit ainsi les évènements d’entrées (clavier, souris, tablettes graphiques…), gère les surfaces (fenêtres), assemble l’image finale et communique avec le noyau (via DRM et KMS, toujours là) pour afficher l’ensemble. C’est vers le compositeur Wayland que les applications se tournent pour présenter un objet à l’écran.

La sécurité est un autre changement radical, puisque Wayland impose une isolation stricte entre les clients, et donc les applications. Ces dernières ne peuvent ainsi voir que leurs propres fenêtres. Elles ne peuvent en outre recevoir les évènements d’entrées que si elles ont le focus, c’est-à-dire quand elles sont au premier plan, pour éviter qu’elles espionnent d’autres applications (ce qui vaut aussi pour les enregistreurs de frappe et les logiciels espions). De plus, elles ne peuvent pas décider où placer les fenêtres, c’est Wayland qui le fait.

L’une des grandes promesses de Wayland, c’est son approche moderne du matériel. De nombreuses caractéristiques sont nativement prises en compte. Beaucoup plus à l’aise avec les configurations multi-écrans, il gère mieux les hautes définitions (HiDPI). Il prend nativement en charge la mise à l’échelle fractionnée (125 ou 150 % par exemple), les taux de rafraichissement différents selon les écrans, les écrans tactiles et les gestes multi-touch.

Wayland est un protocole, pas un logiciel

Wayland est une spécification de protocole, pas un logiciel unique comme l’est X11. Il ne s’agit donc pas d’un composant standardisé auquel tous les autres peuvent se référer en tant que tel. C’est encore une différence fondamentale avec X11, puisque la responsabilité de fournir un environnement de bureau complet est déplacée vers chaque compositeur qui implémente cette spécification Wayland.

Si l’on prend les deux environnements de bureau les plus utilisés, GNOME et KDE, cette responsabilité est confiée respectivement à Mutter et KWin. Et c’est ici que les problèmes peuvent commencer, car cette approche engendre une fragmentation. Si vous souhaitez développer une application, il ne suffit pas en effet de dire « elle est compatible Wayland ». Il faut s’assurer qu’elle fonctionne correctement avec Mutter, KWin ou n’importe quel compositeur qui a implémenté Wayland. Or, ces implémentations ne sont pas identiques. Il existe des variations autour des extensions présentes et des subtilités dans la mise en application.

Ce qui nous fait entrer de plain-pied dans la grande question : pourquoi l’adoption de Wayland est-elle aussi lente ?

Un nombre incalculable de problèmes

Dire que la transition de X11 vers Wayland a été complexe relève de l’euphémisme. On savait qu’une rupture aussi radicale dans l’approche n’aurait pas que de joyeuses conséquences. En outre, Wayland a ses propres problèmes, et certaines promesses n’ont qu’en partie été tenues.

Le modèle de sécurité entraine ainsi une grande cassure. L’isolation stricte des clients a des conséquences majeures sur les fonctionnalités, notamment d’accessibilité. Les lecteurs d’écran, à destination des personnes aveugles ou malvoyantes, ne pouvaient plus fonctionner. Il en allait de même avec les outils de partage ou d’enregistrement d’écran (Discord, OBS…), de bureau à distance (VNC, RDP…), les raccourcis clavier globaux ou encore les outils d’automatisation (Autokey…).

Il a donc fallu tout repenser. C’est là qu’entrent en piste deux composants clés : PipeWire pour l’audio et les portails de bureau XDG pour le graphique. Ces derniers sont des API de haut niveau auxquelles les applications s’adressent pour demander certaines actions, comme accéder à l’écran pour le partager. Ils agissent comme des portails sécurisés pour concentrer les demandes. Le traitement lui-même est confié à PipeWire. Celui-ci a été pensé initialement comme le successeur de PulseAudio et de Jack, mais son rôle a été étendu pour gérer les flux vidéo.

Si PipeWire est un framework utilisable en tant que tel, les portails XDG dépendent des environnements. On trouve par exemple xdg-desktop-portal-kde et xdg-desktop-portal-gnome, respectivement pour KDE et GNOME. Il faut donc que les applications fassent appel à ces composants pour faire leurs demandes.

Cette immense cassure explique déjà en bonne partie pourquoi il a fallu des années avant que des fonctions considérées comme élémentaires avec X11 soient disponibles avec Wayland. Embrayons avec un autre facteur-clé de cette lenteur dans la transition : NVIDIA.

NVIDIA, l’élément (très) perturbateur

Si vous êtes utilisateur de Linux, vous savez peut-être que posséder un GPU NVIDIA peut être synonyme de galère, notamment à cause des pilotes. Pour une expérience complète, notamment avec les jeux, il est presque obligatoire d’utiliser le pilote propriétaire fourni par l’entreprise. Problème, celle-ci avait une vision précise de comment les choses devaient être organisées.

Historiquement, la pile graphique Linux s’est organisée autour d’une API : Generic Buffer Manager, ou GBM. Cette interface est responsable de l’allocation et de la gestion des tampons graphiques en mémoire. NVIDIA ne l’a pas entendu de cette oreille et a tenté de pousser sa propre API, EGLStreams. À l’implémentation des compositeurs Wayland, il fallait ainsi ajouter des chemins de traitement dédiés à NVIDIA. Ce code spécifique a été source de retards et de bugs. Après des années de pression de la communauté, l’entreprise a finalement cédé et implémenté le support de GBM.

Ce n’était pas le seul problème. Un autre conflit existe et n’est toujours pas résolu : la bataille entre les synchronisations implicite et explicite. Historiquement (encore une fois), la synchronisation sous Linux est implicite : le pilote du noyau s’en charge et s’assure qu’une opération de lecture sur un tampon graphique ne se déclenche qu’une fois que l’opération d’écriture précédente est finie. Ce modèle a le gros avantage de simplifier le développement d’applications, mais il peut manquer d’efficacité, car le pilote ne connait pas les « intentions » de l’application. AMD et Intel ont bâti leurs pilotes open source sur ce modèle.

Dans la synchronisation explicite, c’est à l’application ou l’API graphique (comme Vulkan) d’indiquer quand une opération est terminée. La méthode a pour inconvénient de reporter cette charge sur les développeurs d’applications, dont la tâche devient plus complexe. En revanche, le parallélisme et les performances sont meilleurs. NVIDIA a choisi ce modèle pour son pilote open source. La solution n’est apparue qu’au printemps 2024 sous la forme d’un protocole de synchronisation explicite pour Wayland.

Linus Torvalds avait eu en 2012 sa façon bien à lui de dire tout le bien qu’il pensait de NVIDIA avec un

. Si le problème à l’époque n’était pas directement lié (il était alors question des puces Tegra), il préfigurait ce qu’allait être la relation entre l’entreprise et le monde du libre pour de nombreuses années.

XWayland, le pont entre les deux mondes

Vous avez peut-être là aussi croisé ce nom : XWayland. Ce composant a vite eu un rôle critique au sein des distributions Linux, car il assure la compatibilité en permettant aux applications X11 de fonctionner sur Wayland. Comment ? En fournissant un serveur X11 complet, qui s’exécute comme un client Wayland.

On comprend vite l’intérêt. Toutes les applications ne sont pas encore prêtes pour Wayland et certaines ne fonctionnent qu’avec X11. Lorsqu’une telle application est lancée, elle se connecte à XWayland, qui traduit les requêtes pour les envoyer au compositeur Wayland.

Il n’est donc pas question d’une simple couche d’émulation temporaire, mais bien d’un composant en soi, devenu la pierre angulaire de toute la stratégie de transition. Elle a cependant des limites, car ce modèle encapsulé peut créer des incompatibilités dans la communication entre les applications X11 et Wayland, sur des opérations très basiques comme le copier-coller ou le glisser-déposer. Ses performances sont moins bonnes, certaines fonctions peuvent être inaccessibles et des problèmes de sécurité spécifiques à X11 sont toujours là.

La transition étant loin d’être terminée, XWayland restera en place encore longtemps. C’est d’ailleurs à cause de son importance cruciale que les grandes décisions actuelles de transition plus complète vers Wayland épargnent XWayland. Par exemple, l’équipe de développement de GNOME a annoncé que la version 49 de l’environnement commencerait à supprimer tout le code lié à X11, mais cette décision ne s’étend pas à XWayland. L’équipe a depuis changé d’avis, se laissant un peu plus de temps pour supprimer ce code.

Notez que de nombreuses distributions utilisent des sessions Wayland par défaut depuis plusieurs années. Certaines permettent cependant un autre type de session depuis l’écran de connexion, dont X11. Avec le retrait du code, cette capacité disparaitra complètement.

Debian 13 permet toujours de choisir une session X11

Et aujourd’hui alors ?

Aujourd’hui, la transition est irréversible. Depuis l’année dernière notamment, des étapes majeures se sont enchainées, aboutissant aux décisions récentes autour de Wayland et du gommage progressif de X11 dans le code. XWayland va rester en place et assurer la compatibilité des applications n’ayant pas fait encore le voyage. Les raisons peuvent être multiples, comme un manque de moyens face à l’ampleur du travail, ou un abandon partiel ou complet du projet. Qu’il s’agisse de Fedora, Ubuntu ou encore Red Hat, tous ont annoncé des plans pour déprécier X11 plus ou moins rapidement.

X11 est désormais dans un quasi-état de maintenance. Très peu de nouveautés sont ajoutées, car l’essentiel du travail se fait sur Wayland. D’ailleurs, une bonne partie des personnes qui travaillaient sur X11 sont aujourd’hui sur Wayland.

Mais la transition aura été particulièrement longue. L’explication est multifactorielle, comme on l’a vu : NVIDIA a été un élément perturbateur majeur, le modèle de sécurité de Wayland a nécessité la réécriture complète de nombreux éléments et il a fallu du temps pour que des fonctions élémentaires soient de retour. De manière générale, si Wayland n’est pas exempt de défauts, il représente définitivement l’avenir de la pile graphique sur Linux. Et s’il doit durer aussi longtemps que X11, il restera en place plusieurs décennies.

La plupart des gros problèmes liés à Wayland sont aujourd’hui réglés, le dernier gros point à traiter étant la gestion de la synchronisation explicite au sein des compositeurs. Les prochaines années seront consacrées au polissage, à l’accompagnement des applications « récalcitrantes » ou encore à la création de fonctions manquantes, comme une véritable suite d’outils pour l’accessibilité. Il faudra également que les extensions les plus courantes de Wayland continuent leur standardisation afin de gommer les différences entre les environnements de bureau.

Source : next.ink

Sont loin d’être cons les mecs. Ils profitent de l’engouement et de la crédulité des Windowsiens sous win10 voulant passer à Linux :trollface:

En mai dernier, nous prenions en main AnduinOS. Cette distribution sans grande prétention se proposait de reprendre une base Ubuntu et de lui adjoindre un bureau aussi proche que possible de Windows 11. Objectif affiché : faciliter autant que possible les transitions pour les personnes intéressées. Elle a été créée par Anduin Xue, ingénieur chez Microsoft travaillant presque exclusivement sur Linux. Il s’agit en revanche d’un projet personnel, non affilié à l’entreprise.

Une mouture 1.4 du système est sortie le 17 octobre. Malgré le peu d’évolution dans le numéro de version, les changements sont profonds. Ils s’articulent principalement autour de la base technique, qui passe d’Ubuntu 25.04 à 25.10, avec un noyau Linux 6.17 et GNOME 49.

La version ajoute également trois extensions gnome-shell pour élargir la bascule automatique de la couleur d’accentuation dans les applications, un mode « Anduin To Go » pour les installations sur clés USB, ainsi qu’une uniformisation du nom et du logo associé au sein du système. On notera aussi le remplacement de Firefox par sa variante ESR pour éviter le paquet snap associé.

Anduin Xue précise que si la mise à jour est techniquement possible entre AnduinOS 1.3 et 1.4, elle n’est pour l’instant pas recommandée, à cause des profonds changements techniques introduits. Dans son billet d’annonce, il ajoute qu’un script dédié sera fourni dans les deux mois. « Nous nous engageons à n’abandonner aucun utilisateur de la version 1.3 et nous les aiderons finalement à passer à la version 1.4 de manière sûre et fiable. Ce plan devrait être entièrement mis en œuvre d’ici janvier 2026 au plus tard », explique le développeur.

Source : next.ink

@michmich a dit dans Fin de Windows 10 : à Bordeaux, des associations du libre sentent la différence :

mais il me semble qu’il y a des distributions orientées pour les entreprises (qui j’imagine sont un poil trop “canonical” à ton goût)

Oui tu as bien compris 🙂
Mais quand bien même elles seraient orientées entreprise, ça ne changera rien à mon problème.

Achète de la RAM 🙂

En bref:

– Amélioration visuelle et thème automatique : Première version à proposer par défaut les quatre coins arrondis pour les fenêtres et introduit la bascule automatique entre thèmes sombre et clair selon l’heure, avec des fonds d’écran dynamiques et KNightTime pour ajuster la température d’écran.

– Presse-papier et fonctionnalités pratiques : Le presse-papier Klipper permet maintenant de marquer des entrées comme favorites pour les conserver en permanence, avec support de l’encre d’imprimante, bouton mise en veille prolongée sur l’écran de connexion et recherche “floue” dans KRunner.

– Support Wayland et performances : Nouvelles capacités Wayland avec mode picture-in-picture et protocole “pointer warp”, plus les “plans de superposition” qui améliorent les performances des jeux et réduisent la consommation lors de la lecture vidéo.

La nouvelle version de l’environnement Plasma pour les distributions Linux est disponible depuis peu en bêta. L’équipe de développement a décidé de lui donner certaines capacités visuelles qui lui faisaient défaut, dont la bascule automatique des thèmes. Mais on trouve aussi bon nombre d’améliorations dans tous les recoins.

Maintenant que GNOME 49 est disponible en version finale, les regards se tournent vers la prochaine évolution majeure de l’autre grand environnement de la sphère Linux, à savoir KDE Plasma. La bêta de la version 6.5 est disponible depuis quelques jours et plusieurs distributions permettent de la tester.

Précisons néanmoins qu’il n’est pas si aisé d’essayer ces nouveautés, car peu de ces distributions fournissent un environnement Plasma sans modifications. Nous avions porté notre dévolu sur KDE Neon Testing, pour obtenir une expérience inchangée, mais la branche de test affiche toujours Plasma 6.4.5. Contrairement à ce qu’indique l’équipe de KDE dans sa présentation, c’est la branche Unstable qui dispose actuellement de Plasma 6.5.

Plusieurs améliorations visuelles

Plasma 6.5 introduit diverses nouveautés pour l’interface. par exemple, c’est la première version de l’environnement à proposer par défaut les quatre coins arrondis pour les fenêtres, plutôt que seulement deux en haut et deux coins carrés en bas. Ce n’est pas une révolution, mais Plasma se retrouve aligné désormais avec ce que l’on peut voir dans Windows, macOS et la plupart des distributions Linux fournies avec GNOME (quand les applications sont pleinement compatibles GTK4).

Le nouveau Plasma introduit également la bascule automatique entre les thèmes sombre et clair selon l’heure de la journée. Cette fonction, qui existe depuis longtemps dans GNOME et macOS, permet de changer pour un thème sombre à l’heure du coucher du soleil, afin de fournir un environnement moins agressif pour les yeux. Comme les autres systèmes, on peut toutefois paramétrer cette bascule ou la désactiver. À noter également que Plasma 6.5 propose des fonds d’écran adaptés (« dynamiques ») et que l’on peut personnaliser quel fond est utilisé dans un mode spécifique. Le choix du thème apparait aussi dans Paramétrage rapide, à l’ouverture de l’outil Configuration.

L’équipe ajoute avoir procédé à de nombreux petits ajustement un peu partout pour améliorer la lisibilité des textes, réduire les clignotements et ajouter des correspondances visuelles à tout ce qui pourrait déclencher un son.

Plasma 6.5 introduit dans le même temps KNightTime. Comme son nom l’indique, la fonction ajuste automatiquement la température de l’écran selon l’heure de la journée, un comportement désormais classique dans les systèmes d’exploitation. Là encore, ce comportement peut être désactivé.

Nombreux petits ajouts pratiques

Les notes de version de Plasma 6.5 contiennent une longue liste d’ajouts plus ou moins notables, mais dont beaucoup s’annoncent pratiques. Exemple simple, mais parlant : la prise en charge du niveau d’encre des cartouches d’imprimante, et la possibilité de recevoir des alertes quand ce niveau devient bas.

On trouve également plusieurs améliorations notables du presse-papier et de l’application qui l’accompagne, Klipper. Plasma 6.5 ajoute ainsi une fonction réclamée depuis longtemps : pouvoir marquer certaines entrées comme favorites afin de les y enregistrer de manière permanente. Qu’importe alors le redémarrage de la machine, on pourra ressortir les éléments régulièrement collés les fois suivantes. Autre fonction, le support de la synchronisation du presse-papiers entre le client et le serveur lors de sessions de bureau à distance.

On continue dans les ajouts pratiques avec l’apparition sur l’écran de connexion d’un nouveau bouton pour déclencher la mise en veille prolongée de l’ordinateur, si le système détecte une configuration compatible. Un ajout semblable à celui des contrôles média de GNOME 49 sur l’écran de connexion, que KDE possédait déjà.

Et ça continue

Il est difficile de rassembler les nouveautés de Plasma 6.5, tant elles sont réparties dans de nombreux composants. Par exemple, le widget Sticky Notes est beaucoup plus pratique, grâce à plusieurs améliorations : la couleur déjà utilisée est indiquée dans le menu, la couleur de la note est affichée dans le menu contextuel, l’ensemble est plus lisible en fonction du thème, et la fenêtre popup peut être redimensionnée.

On note aussi l’apparition d’interrupteur dans les paramètres rapides pour des éléments comme le Bluetooth, qui évitent de devoir cliquer sur la catégorie pour activer/désactiver un élément. On continue avec un petit rattrapage sur GNOME dans la gestion des pilotes, puisque la boutique Discover peut maintenant en gérer l’installation si besoin. Les développeurs indiquent que cette modification est utilisée avec succès depuis plus d’un an sur la distribution Solus.

Autre nouveauté très bienvenue, une page de configuration permet de rassembler toutes les permissions données aux applications basées sur des portails. Même si on pense tout de suite aux paquets Flatpak, l’équipe précise que c’est bien pour l’ensemble des portails. Pour une application, on peut ainsi voir les autorisations accordées et les désactiver si besoin. Par exemple, couper l’accès aux notifications, lui retirer sa priorité haute, ne plus lui permettre d’empêcher la mise en veille, bloquer la géolocalisation, etc.

Encore un peu ?

Les recherches dans KRunner deviennent en outre plus pratiques. Le composant supporte en effet désormais la recherche « floue » pour les applications : on peut retrouver ce que l’on cherche non pas en indiquant le nom exact, on peut la décrire avec des termes génériques, qui peuvent même contenir des erreurs (dans une certaine mesure). Cette recherche prend aussi en charge les raccourcis globaux. Si vous cherchez par exemple à effectuer une capture d’écran d’une zone spécifique, il suffit de décrire le résultat à KRunner pour qu’il vous indique le bon raccourci.

Plasma 6.5 contient – inévitablement – des améliorations liées au support de Wayland. L’environnement prend ainsi en charge le mode picture in picture du « nouveau » serveur d’affichage, ainsi que le protocole « pointer warp ». Ce dernier permet à un client (comme une application) de téléporter le curseur de la souris d’un endroit à un autre. L’équipe indique que pour limiter les dérapages, cette faculté ne sera gérée qu’au sein de la fenêtre étant au premier plan.

On continue avec plusieurs nouveautés pour les tablettes. Le nouveau Plasma permet notamment de configurer les molettes, quand la tablette utilisée en contient. Ces molettes sont le plus souvent utilisées pour appliquer un niveau de zoom ou pour modifier la taille du pinceau. De même, leurs versions tactiles sont également prises en charge, comme on les retrouve parfois sur les modèles Wacom. Plasma permet alors d’en modifier le comportement, voire de les désactiver.

Enfin, signalons que Plasma 6.5 introduit les « plans de superposition » pour le traitement graphique. Le procédé évite de calculer notamment ce qui se trouve derrière une fenêtre et donc de ralentir la composition de l’ensemble. Selon l’équipe de développement, cet ajout améliore les performances et la latence pour les jeux en mode fenêtré, tout en réduisant « considérablement » la consommation d’énergie lors de la lecture vidéo. Cette capacité est encore incomplète et ne fonctionne par exemple pas sur les configurations HDR. De plus, on ne peut s’en servir que pour une seule sortie par GPU, donc pas en mode multi-écrans.

La version finale de Plasma 6.5 est attendue pour le 21 octobre. Notez que l’un des grands apports prévus, KDE Initial System Setup (KISS), est finalement reporté à la version 6.6.

– Source :

https://next.ink/201208/kde-plasma-6-5-arrondit-ses-angles-et-sadoucit-la-nuit-venue/

La distribution GLF OS, axée sur le jeu vidéo, est désormais disponible en version finale. Dans ce premier article, nous allons présenter les grandes lignes du système. Dans un deuxième temps, nous ferons une prise en mains de GLF OS et nous pencherons plus généralement sur le jeu vidéo sur Linux.

Mise à jour du 10 septembre :

La version finale de GLF OS vient d’être mise en ligne. Comme nous l’indique Vinceff, à l’origine du projet, cette mouture corrige de nombreux bugs et apporte diverses améliorations, dont des optimisations dans le noyau.

On note également quelques nouveautés, comme l’arrivée d’un alias permettant de voir la dernière mise à jour installée, l’ajout d’un écran de bienvenue pour guider les nouveaux utilisateurs, le support du VRR dans la version GNOME, ou encore l’ajout de plusieurs extensions.

Pour les personnes qui avaient installé la bêta, l’arrivée de la version finale se fera comme n’importe quelle autre mise à jour. Sur le serveur Discord de la distribution, on peut lire qu’un ou deux redémarrages peuvent être nécessaires. Les utilisateurs ayant choisi la variante « rolling » seront basculés sur la branche testing le 17 septembre. À cette date, cette dernière passera automatiquement sur la version N+1 de la distribution. La documentation fournit une méthode pour passer de stable à testing ou inversement sans réinstallation du système.

Les évolutions du système se feront désormais au rythme d’une version par saison. La prochaine arrivera donc dans environ trois mois.

Article originel du 4 juin :

Le jeu vidéo représente souvent une barrière au changement d’environnement. Sur PC, l’immense majorité des titres ne sont disponibles que sous Windows, quelle que soit la boutique utilisée pour y jouer. Il est plus simple de trouver des équivalents Linux pour la plupart des applications que de faire fonctionner ses jeux préférés. Du moins, ce fut le cas pendant longtemps.

La situation a sérieusement commencé à évoluer ces dernières années, sous l’impulsion de Valve particulièrement. Le projet Proton, issu d’un fork de Wine, est désormais au cœur d’une offensive de l’éditeur dans le monde du jeu vidéo. Il est pleinement intégré à Steam OS, que l’on retrouve surtout sur la console portable Steam Deck. Celle-ci ayant connu un grand succès commercial, elle a fait des émules, entrainant une réflexion nouvelle sur la possibilité de jouer sur Linux. GLF OS arrive donc à un tournant intéressant.

Une naissance simple

Vinceff, très impliqué dans la communauté Linux avec notamment de nombreuses vidéos tutos, est l’initiateur de GLF OS (dépôt GitHub). Comme il nous le raconte, il était utilisateur de Mageia. Il avait basculé sur Linux après une énième mise à jour problématique de Windows 10 et s’était rendu compte que ses jeux principaux fonctionnaient sur la distribution. C’est dans ce contexte qu’il commence à proposer des vidéos.

Rapidement, la chaine YouTube gagne des dizaines d’abonnés. Quand le cap des 250 est franchi, Vinceff décide d’ouvrir un serveur Discord pour favoriser les discussions. Il le nomme simplement Gaming Linux FR et les personnes affluent, aussi bien des « sachants » que d’autres, intéressées par le thème et cherchant des réponses à des problèmes pratiques.

Le Discord, créé pendant la crise sanitaire, compte aujourd’hui plus de 3 300 membres. Aucune distribution n’est privilégiée, la thématique étant l’entraide sur le thème général du jeu sur Linux. L’idée est cependant venue d’une distribution qui serait entièrement tournée vers le jeu, en facilitant la prise en main et en donnant immédiatement accès aux outils courants. Le projet a été nommé GLF OS, GLF étant une simple contraction de Gaming Linux FR.

Le système est aujourd’hui le résultat d’un travail d’équipe, comprenant des contributions de plusieurs dizaines de développeurs, le cœur de l’équipe étant constitué d’une petite vingtaine de personnes. Le projet, lui, est codirigé par Vinceff et Cammi.

Une base NixOS

Un grand nombre de distributions sont basées sur Debian ou Ubuntu. GLF OS a regardé ailleurs : vers NixOS. Cette distribution Linux ne date pas d’hier, puisque le projet de recherche qui lui a donné naissance date de 2003. Le système a même sa propre fondation depuis 2015.

NixOS est avant tout basée sur le gestionnaire de paquets Nix. Tout se fait par une configuration déclarative : on écrit dans un fichier texte ce que l’on souhaite, et le gestionnaire construit le système à partir de ces informations. C’est autant le cas pour l’installation initiale que pour les mises à jour.

Comme nous l’explique Vinceff, cette approche déclarative est couplée à une gestion transactionnelle des configurations. Les mises à jour sont donc atomiques, ce qui signifie – dans les grandes lignes – que les opérations liées créent une nouvelle image du système, sur laquelle l’utilisateur ne bascule réellement qu’au redémarrage suivant, si aucune erreur n’a été détectée. Ce mécanisme permet une fiabilité généralement plus élevée, car l’image utilisée est en lecture seule. L’atomicité a particulièrement le vent en poupe depuis quelques années, notamment chez Fedora.

NixOS propose toujours deux versions par an, en mai et novembre. La numérotation des versions est la même que pour beaucoup de distributions : l’année suivie du mois. La toute fraiche version 25.05 désigne ainsi la version « mai 2025 ». Le système est disponible en deux branches, stable et unstable. Pour ses objectifs, GLF OS compose avec les deux, comme nous le verrons.

GLF OS : premier contact

L’installation de GLF OS ne réserve aucune surprise. L’environnement par défaut est GNOME, mais l’installateur permet de changer pour KDE. Pour le reste, on est sur la liste habituelle des questions pour cette étape, avec choix du partitionnement, création du temps, sélection du fuseau horaire, etc.

Il y a quand même une étape importante : le choix de l’édition. Par défaut, « Standard » installe la version complète du système pensée pour le jeu vidéo, qui réclame environ 20 Go d’espace libre. Il s’agit d’une suite complète, avec notamment Firefox en navigateur par défaut et LibreOffice pour la bureautique. On peut également choisir une installation minimale, fournie presque sans aucune application. Deux autres éditions sont proposées. La première, Studio, est orientée vers tout ce qui touche à la création graphique. La seconde est une variation intégrant Da Vinci Resolve (une licence est nécessaire).

L’installation (Standard dans notre cas) est un peu plus longue que pour une distribution ordinaire, NixOS ayant besoin d’un peu plus de temps pour construire le système, à partir des scripts propres à GLF OS. Au redémarrage, le bureau est très classique. Bien qu’il s’agisse d’une base GNOME modifiée, notamment pour avoir un dock affiché en permanence (via Dash to Dock), elle ne choquera pas longtemps une personne venant de n’importe quelle autre distribution GNOME.

L’un des éléments peut-être les plus « étranges », c’est l’absence apparente de gestion des mises à jour. Le système s’en occupe en fait seul et envoie simplement une notification pour indiquer qu’une opération est terminée. Dans ce cas, les changements ne seront pas appliqués tant que GLF OS n’aura pas redémarré. Le redémarrage n’est jamais suggéré.

En outre, l’installation d’applications supplémentaires se fait via Flatpak et passe par Easy Flatpak. L’approche générale de GLF OS se veut résolument moderne : un système atomique et des conteneurs logiciels.

Le jeu vidéo comme spécialité

GLF OS étant spécialisée dans le jeu vidéo, la distribution contient plusieurs applications dédiées à cet usage. Déjà, les personnes ayant un PC équipé d’un GPU NVIDIA auront la bonne surprise de constater que ce dernier est détecté et que l’installation des pilotes correspondants est automatique.

Côté logithèque, on retrouve bien sûr Wine et Proton, tous deux disponibles dans leur dernière révision. La distribution propose également trois applications cruciales : Steam évidemment, ainsi que Lutris et Heroic. Les deux dernières sont des clients capables de se connecter à des comptes Steam, Ubisoft, EA, Epic, GOG ou encore Amazon. De là, ils permettent l’accès aux jeux en créant un environnement préconfiguré pour permettre leur lancement grâce à Proton.

Dans cet esprit d’une plateforme pensée pour le jeu vidéo, on trouve tout un ensemble de modifications et d’ajouts. Par exemple, la base du système repose sur la branche stable de NixOS (GNOME, KDE, Wayland, Pipewire, pilotes NVIDIA…), mais tout ce qui nécessite des mises à jour régulières s’appuie sur la branche unstable. C’est le cas pour toutes les applications en lien avec le jeu vidéo comme Steam, Heroic Games Launcher, Lutris, Proton, Mesa et autres.

GLF OS apporte en outre ses propres modifications, dont le kernel qui est une version 6.14 modifiée pour régler certains soucis de compatibilité, notamment avec le Ryzen 9800 X3D d’AMD. L’équipe a également intégré des paquets pour étendre le support des volants de jeu (ThrustMaster, Fanatec et Logitech) et des manettes (Xbox, PlayStation, Switch et 8bitdo).

Nous aurons l’occasion de revenir sur le sujet avec une prise en main concrète et un retour d’expérience sur ce qu’est le jeu vidéo sur Linux aujourd’hui. En attendant, la bêta de GLF OS peut être téléchargée depuis son site officiel.

Source : next.ink

En bref :

– Fini de mentir à votre boss : cette barre de progression pour rsync révèle ENFIN où en sont vos transferts de téraoctets.

– Les admins système cachaient ce secret : comment transformer rsync muet en tableau de bord professionnel avec rsyncy.

– Pendant que vous galérez avec rsync aveugle, cette alternative libre affiche vitesse, ETA et progression en temps réel.

Vous venez de lancer un bon gros rsync en prod pour migrer 3 téraoctets de données et votre boss vous sur-saoule toutes les 10 minutes avec des : “Alors, ça en est où ?” en boucle et vous, en bonne victime, vous répondez “Ça avance chef, ça avance…”.

On peut faire mieux non ? Et oui, avec rsyncy qui vous permet au lieu d’avoir un rsync muet qui vous laisse dans le noir, de profiter d’une vraie barre de progression visuelle. Comme ça, vous voyez le pourcentage d’avancement, la vitesse de transfert, le volume copié, le temps écoulé, l’ETA, le nombre de fichiers traités… Bref, toutes les infos pour répondre factuellement à votre hiérarchie et prendre des décisions éclairées de grand professionnel qui aura bientôt une augmentation de salaire ^^.

L’installation est super simple. Vous avez plusieurs options selon votre setup :

# One-liner universel curl https://laktak.github.io/rsyncy.sh|bash # Sur macOS avec Homebrewbrew install rsyncy # Avec Gogo install github.com/laktak/rsyncy/v2@latest # Avec pipx (version Python) pipx install rsyncy

– Et une fois installé, vous pouvez soit lancer rsyncy directement avec les mêmes arguments que rsync :

rsyncy -a /source/ /destination/

– Soit piper la sortie de votre rsync habituel vers rsyncy :

rsync -a --info=progress2 -hv /source/ /destination/ | rsyncy

Ce qui est top, c’est qu’avec ce paramètre, rsyncy ajoute automatiquement les arguments nécessaires pour avoir le maximum d’informations comme ça y’a plus besoin de vous rappeler des bonnes options.

– La barre de progression affichera quelque chose comme ça :

Et là, vous avez tout… la barre visuelle, le pourcentage, les données transférées, la vitesse actuelle, le temps écoulé et le nombre de fichiers traités. C’est clair, net et précis.

– Pour les environnements où les couleurs posent problème (certains logs, scripts automatisés), vous pouvez les désactiver avec :

NO_COLOR=1 rsyncy /source/ /destination/

Pour les devs qui veulent debugger ou enregistrer leurs transferts rsync, l’auteur recommande d’utiliser “ pipevcr ”, un autre de ses outils qui permet d’enregistrer et rejouer des flux de données. Pratique pour tester rsyncy sans lancer de vrais transferts.

Voilà, comme ça avec rsyncy, vous savez exactement où vous en êtes et vous pouvez estimer si vous allez respecter votre fenêtre de maintenance, prévenir si ça va déborder, ou rassurer tout le monde que tout se passe bien.

– Sources : Laurent-Biagiotti-linkedin

https://github.com/laktak/rsyncy

https://korben.info/rsyncy-barre-progression-visuelle-rsync.html

La nouvelle mouture du noyau Linux est sortie ce dimanche 27 juillet. Une version assez attendue, car contenant de nombreuses améliorations pour le matériel, que l’on parle de support ou de performances. On trouve bon nombre d’apports pour Intel, AMD et NVIDIA notamment.

SEV chez AMD, TDX chez Intel

Chez AMD par exemple, avec d’importants changements dans le pilote et sous-système AMD-SBI, avec à la clé une meilleure surveillance de la puissance et de la température. La Secure Encrypted Virtualization (SEV) est enfin supportée, pour renforcer la sécurité des machines virtuelles chiffrées (sur serveurs utilisant des processeurs AMD). Le nouveau noyau identifie en outre plus facilement les plantages et causes de réinitialisation sur l’ensemble des processeurs Zen.

Côté Intel, on trouve aussi des améliorations pour la sécurité des machines virtuelles, avec le support de l’hôte Trust Domain Extensions (TDX) pour KVM pour renforcer l’isolation. La surveillance du matériel est là aussi renforcée, notamment la température, permettant notamment l’apparition de garde-fous pour l’overclocking.

Le noyau 6.16 introduit également une nouvelle option de compilation X86_NATIVE_CPU. Comme son nom l’indique, elle permet aux personnes compilant elles-mêmes leur noyau de forcer une optimisation sur les capacités spécifiques du processeur utilisé. L’option devrait améliorer les performances sur le matériel récent, pour mieux tirer parti des jeux d’instructions.

Blackwell et Hopper de NVIDIA

Côté GPU, la prise en charge des architectures Blackwell et Hopper de NVIDIA a été ajoutée au pilote « Nouveau ». Les puces Intel reçoivent plusieurs améliorations, dont le support de la fonction Link-Off Between Frames (LOBF) pour les ordinateurs portables, pour économiser l’énergie. Outre des correctifs, le pilote Intel Xe sait maintenant indiquer la vitesse des ventilateurs.

Parmi les autres améliorations, on en trouve beaucoup pour le système de fichiers bcachefs, surtout sur les performances. Cependant, comme le notait It’s FOSS News fin juin, l’avenir de ce support dans le noyau est incertain, Linus Torvalds n’ayant pas apprécié les derniers échanges avec le mainteneur principal du projet. Signalons aussi des améliorations de performances pour Btrfs, le support de l’écriture atomique dans XFS ou encore le support d’Intel QAT dans EROFS.

Comme toujours, l’installation de nouveau noyau dépend de la distribution Linux utilisée. Souvent, sur les systèmes dits classiques, le noyau ne change vraiment qu’avec la version majeure suivante. Sur les distributions de type rolling release, comme Arch Linux et openSUSE Tumbleweed, le noyau devrait être très rapidement proposé, si ce n’est déjà fait. Dans tous les cas, il existe des mécanismes pour forcer l’installation d’un nouveau noyau, mais la manipulation n’est pas recommandée, à moins de savoir ce que vous faites.

Source : next.ink

@Psyckofox a dit dans Koske : quand des images de pandas cachent un malware Linux :

@Violence

J’avais mis en place un plan infaillible mais t’es entrain de me griller 😁

https://planete-warez.net/post/99100

Je t’ai vu mettre ça dans le topic des fragiles @Psyckofox 🤣

Si vous avez toujours voulu fouiller le dark web sans y passer 3 heures à chercher dans le noir, j’ai déniché un outil Python qui fait le boulot pour vous : Darkdump.

Créé par Josh Schiavone, Darkdump est une interface OSINT (Open Source Intelligence) qui permet de mener des investigations sur le deep web. En gros, vous tapez un mot-clé, et l’outil va scraper les sites .onion correspondants pour en extraire des emails, des métadonnées, des mots-clés, des images, des liens vers les réseaux sociaux, et j’en passe.

Darkdump utilise Ahmia.fi (un moteur de recherche pour le dark web) pour trouver les sites .onion pertinents, puis il les scrape quand vous êtes connecté via Tor. Bref, c’est Google pour le dark web, en ligne de commande et avec des super-pouvoirs.

– Pour l’installer, rien de plus simple :

git clone https://github.com/josh0xA/darkdumpcd darkdumppython3 -m pip install -r requirements.txtpython3 darkdump.py --help

Mais attention, avant de vous lancer, il faut configurer Tor correctement. Sur Linux ou Mac, installez Tor (sudo apt install tor ou brew install tor), puis éditez votre fichier /etc/tor/torrc pour ajouter :

ControlPort 9051HashedControlPassword [VotreMotDePasseHashé]

Pour générer le hash du mot de passe, utilisez tor --hash-password "mon_mot_de_passe". Ensuite, démarrez le service Tor et vous êtes prêt à explorer les profondeurs du web.

Ce qui est cool avec Darkdump, c’est sa flexibilité. Vous pouvez l’utiliser de plusieurs façons. Voici quelques exemples données dans la doc officielle :

Rechercher 10 liens et scraper chaque site : python3 darkdump.py -q "hacking" -a 10 --scrape --proxy Juste récupérer 25 liens sans scraper (pas besoin de Tor) : python3 darkdump.py -q "free movies" -a 25 Chercher et télécharger les images : python3 darkdump.py -q "marketplaces" -a 15 --scrape --proxy -i

L’outil peut extraire pas mal de trucs intéressants comme des documents (PDF, DOC, XLS, PPT…), des adresses email, des métadonnées, et même des liens vers des profils de réseaux sociaux. C’est super pour les chercheurs en sécurité ou encore les journalistes d’investigation.

Maintenant, parlons un peu d’Ahmia.fi, le moteur qui fait tourner tout ça. Contrairement à ce qu’on pourrait croire, vous n’avez pas besoin de Tor pour accéder à l’interface d’Ahmia… vous pouvez y aller directement depuis votre navigateur normal. Par contre, pour visiter les sites .onion qu’il trouve, là il vous faudra Tor Browser.

Le moteur de recherche Ahmia

Ce qui est bien avec Ahmia, c’est qu’ils filtrent le contenu illégal comme ça c’est pas le far west total. Ils essaient tant bien que mal de garder ça propre et légal.

En 2025, Ahmia reste donc l’un des moteurs de recherche du dark web les plus fiables, aux côtés de Torch, DuckDuckGo (version Tor), Haystak et Not Evil. Chacun a ses spécificités, mais Ahmia reste le préféré pour sa politique de filtrage du contenu illégal.

Bon, évidemment, je dois faire mon speech de prévention et Josh Schiavone lui-même précise : Il n’est pas responsable de l’utilisation que vous faites de son outil. Ne l’utilisez donc pas pour naviguer sur des sites illégaux selon les lois de votre pays. C’est un outil pour la recherche légitime, l’OSINT, la cybersécurité, pas pour faire n’importe quoi.

D’ailleurs, petite anecdote, la v3 de Darkdump a été mise à jour récemment, et apparemment il y a même des forks qui commencent à apparaître avec des mises à jour complètes. La communauté OSINT est active sur ce projet, ce qui est bon signe pour sa pérennité. Voilà, donc pour ceux qui veulent aller plus loin dans l’OSINT sur le dark web, Darkdump n’est qu’un logiciel parmi d’autres et fait partie d’une boîte à outils plus large qui comprend des trucs comme OnionScan, TorBot, ou encore Dark Web OSINT Tools. Mais pour débuter, c’est vraiment l’un des plus simples et des plus efficaces.

Ça ne transformera pas le dark web en votre terrain de jeu, mais au moins vous verrez où vous mettez les pieds. Et dans un monde où l’information est de plus en plus fragmentée et cachée, c’est pratique, mais souvenez-vous, avec un grand pouvoir vient une grande responsabilité donc utilisez-le à bon escient !

– Sources :

https://github.com/josh0xA/darkdump

https://korben.info/darkdump-outil-osint-fouille-dark-web.html

Trois paquets malveillants ont été déposés sur le dépôt communautaire utilisé par Arch Linux : l’Arch User Repository. Ces paquets installaient en réalité le logiciel malveillant Chaos, un Cheval de Troie capable de donner un accès distant à la machine infectée. Faisons le point.

Des malwares dans le dépôt communautaire d’Arch Linux

L’Arch User Repository (AUR) est un dépôt de paquets sur lequel les utilisateurs d’Arch Linux peuvent trouver des applications et paquets en tout genre non disponibles dans les dépôts officiels. En effet, il s’agit d’un dépôt communautaire. Cependant, il repose sur la confiance et la vigilance des utilisateurs, car il n’y a pas de réel processus de validation : n’importe qui peut déposer un paquet.

Et, pour preuve, le 16 juillet dernier, un utilisateur avec le pseudo “danikpapas” a mis en ligne trois paquets sur l’AUR : librewolf-fix-bin, firefox-patch-bin et zen-browser-patched-bin. Ces derniers dissimulaient un script d’installation malveillant.

“Le 16 juillet, vers 20 heures UTC+2, un paquet AUR malveillant a été téléchargé sur le site AUR.”, peut-on lire sur le site d’Arch Linux. Ce paquet n’était pas seul, puisqu’il y a eu deux autres paquets chargés par le même utilisateur.

Deux autres paquets malveillants ont été téléchargés par le même utilisateur quelques heures plus tard. Ces paquets installaient un script provenant du même dépôt GitHub qui a été identifié comme un cheval de Troie d’accès à distance (RAT).

La méthode était simple, mais efficace : le fichier de construction PKGBUILD de chaque paquet contenait une instruction pour cloner un dépôt GitHub (par exemple : https[:]//github.com/danikpapas/zenbrowser-patch.git). Ce qui signifie que le système téléchargeait et exécutait le code du malware durant le processus de construction du paquet. L’utilisation de scripts de construction de paquets, appelés PKGBUILD, est tout à fait normal dans le contexte d’Arch Linux.

Qu’est-ce que le malware Chaos RAT ?

Le logiciel malveillant Chaos est un RAT, c’est-à-dire un cheval de Troie d’accès à distance (Remote Access Trojan). Une fois installé sur une machine, il se connecte à un serveur C2 (commande et contrôle), ici localisé à l’adresse 130[.]162.225.47:8080, et attend les ordres des cybercriminels !

L’attaquant dispose alors d’un accès distant sur le système compromis: il peut télécharger et envoyer des fichiers, exécuter des commandes arbitraires ou encore ouvrir un reverse shell. Ceci ouvre la porte à des actions malveillantes, comme le vol d’identifiants ou de données.

La bonne nouvelle, c’est que le nettoyage a été fait suite aux signalements de certains utilisateurs qui ont pris la peine d’analyser les paquets sur VirusTotal :

Les dépôts GitHub associés à cette campagne ont été supprimés. Les trois paquets malveillants ont été supprimés par l’équipe d’Arch Linux le 18 juillet.

Pour les utilisateurs qui auraient pu installer l’un de ces paquets, vous devez vérifier votre machine. Recherchez la présence d’un exécutable suspect nommé systemd-initd, potentiellement situé dans le dossier /tmp.

– Source :

https://www.it-connect.fr/arch-linux-trois-paquets-aur-malveillants-destines-a-installer-le-malware-chaos-rat/

@Psyckofox :lol:

Vos serveurs web classiques, les censeurs les trouvent en 3 clics. Même avec un VPN foireux, même caché derrière CloudFlare, même en priant très fort, alors imaginez que vous voulez publier un truc sur le web sans que personne ne puisse remonter jusqu’à vous ? Et bien en fait c’est hyper simple avec torserv qui lance automatiquement votre site comme service caché Tor.

Il s’agit d’un serveur web statique durci qui intègre nativement Tor. Pas de base de données MySQL qui traîne, pas de PHP qui fuite, juste vos fichiers HTML, CSS et JavaScript servis proprement. Le truc génial, c’est la configuration zéro. Vous lancez le binaire et hop, votre site devient accessible via une adresse .onion automatiquement générée.

J’ai découvert torserv après avoir passé 2 heures à galérer avec une config manuelle d’Apache + Tor pour un petit projet perso car configurer un service caché à la main, c’est pas de la tarte. Faut éditer torrc, créer les bons répertoires, gérer les permissions, redémarrer les services… Avec torserv, tout ça disparaît. Vous pointez sur votre dossier web et c’est parti.

Et le pire dans tout ça ? C’est que même après avoir fait votre config manuelle parfaite, vous êtes jamais sûr à 100% de pas avoir laissé trainer une faille. Un header Apache qui balance votre version, un module PHP mal configuré, un log qui enregistre les requêtes… Avec torserv, ces soucis n’existent pas. Le code est minimaliste par design.

Pour comprendre l’intérêt, faut savoir comment fonctionnent les services cachés Tor. Contrairement à un site normal où votre serveur a une IP publique visible, un service .onion reste planqué dans le réseau Tor. Les visiteurs passent alors par plusieurs relais chiffrés, et même eux ne connaissent pas votre vraie localisation.

Mais torserv va plus loin.

Il embarque directement le binaire Tor, donc pas besoin d’installer quoi que ce soit sur votre machine. Et le serveur intégré écrit en Go gère tout : il lance Tor en tâche de fond, génère les clés cryptographiques pour votre .onion, et sert vos fichiers avec les bons headers de sécurité. Tout ça dans un seul exécutable de moins de 20 Mo.

Le petit bonus sympa c’est que torserv ajoute du jitter temporel sur les réponses (50-200ms aléatoires) et du padding sur la taille des fichiers. Ça complique sérieusement l’analyse de trafic pour ceux qui voudraient identifier votre site par ses caractéristiques réseau.

Et les cas d’usage sont nombreux. Vous pouvez par exemple héberger des documents sensibles sans passer par un cloud public. Parfait pour le journalisme d’investigation, l’activisme dans certains pays, ou même pour une entreprise qui veut éviter les fuites via des plateformes externes.

– Mais y’a d’autres trucs cools à faire :

Partage temporaire de fichiers : Vous lancez torserv le temps de partager des docs, puis vous coupez tout. Aucune trace. Blog personnel vraiment privé : Pour publier vos pensées sans que Google indexe tout Backup décentralisé : Pour héberger vos sauvegardes chiffrées accessibles uniquement via Tor

Maintenant, si vous voulez tester, vous devez télécharger le binaire depuis GitHub, vous le lancez dans le dossier contenant vos fichiers web, et torserv génère automatiquement votre adresse .onion. En 5 minutes chrono vous avez un site web invisible.

– Concrètement, ça donne ça :

wget https://github.com/torserv/torserv/releases/download/latest/torserv-linux-amd64.zip unzip torserv-linux-amd64.zip cd TorServ ./torserv

Et boom, vous avez un truc du genre : http://xxxxxxxxxx.onion qui s’affiche dans votre terminal. Copiez-collez dans Tor Browser et voilà.

Ce qui m’a surpris pendant mes tests, c’est la performance. J’avais des aprioris sur la lenteur du réseau Tor, mais pour du contenu statique, ça reste très correct. Évidemment, on est pas sur de l’hébergement classique, mais pour des documents, des pages simples, ça fait le taf. Et puis l’avantage, c’est que votre bande passante n’est pas plombée puisque le trafic transite par les relais Tor.

Et la sécurité intégré à torserv, ce n’est pas que du marketing. Le serveur limite les requêtes, filtre les tentatives d’exploitation, et expose le minimum de surface d’attaque. Bref, contrairement à Apache ou nginx avec leurs 50 000 modules, torserv fait juste ce qu’il doit faire : servir des fichiers statiques de manière sécurisée. Moins de complexité, moins de failles potentielles.

– Voici ce qu’il propose :

Scrubbing EXIF automatique : Vos photos sont nettoyées de toutes métadonnées avant d’être servies Headers durcis : Pas de User-Agent, pas de Referer, pas d’ETag qui traîne Localhost only : Le serveur n’écoute que sur 127.0.0.1, impossible d’y accéder depuis ailleurs que votre propre machine Pas de logs : Rien, nada, que dalle. Même sous la torture, votre serveur ne balance rien

Après vous l’aurez compris, c’est du statique uniquement, donc oubliez WordPress, les formulaires dynamiques ou les API. Si vous avez besoin d’interactivité, faudra regarder ailleurs. Et puis, c’est plutôt récent comme projet, donc ça n’a pas encore la maturité d’un Apache.

– Autres trucs chiants :

Pas de HTTPS : Mais bon, avec Tor c’est déjà chiffré de bout en bout, donc on s’en fout Pas de compression : Gzip et compagnie sont désactivés pour éviter les attaques BREACH PDF bloqués : Par sécurité, torserv refuse de servir des PDF (trop de métadonnées potentielles) Taille max des fichiers : Évitez les vidéos de 2 GB, ça va ramer sévère

Comparé aux autres solutions, torserv a ses avantages. OnionShare c’est bien pour du partage ponctuel, mais c’est GUI only et moins flexible et SecureDrop c’est overkill pour la plupart des usages.

Je trouve donc que Torserv trouve le bon équilibre car il est assez simple pour être utilisé par n’importe qui, et assez sécurisé pour tenir la route face aux menaces courantes. Et pour du professionnel avec de gros besoins, partez plutôt sur une infrastructure dédiée mais pour 90% des cas d’usage (partage de docs, mini-site personnel…etc) c’est exactement ce qu’il vous faut.

Attention quand même, l’anonymat total n’existe pas. Même avec Tor et torserv, vos habitudes de rédaction, vos heures de publication, le style de vos contenus peuvent vous trahir. L’OPSEC (operational security) reste crucial. Et évidemment, côté légalité, respectez les lois de votre pays car Tor c’est pas un permis pour tout faire.

Un dernier conseil, si vous êtes vraiment parano (et vous avez peut-être raison), utilisez l’option --new-key qui génère une nouvelle adresse .onion à chaque lancement. Comme ça, même si quelqu’un trouve votre site, il pourra plus y accéder la prochaine fois. C’est radical mais efficace.

– Sources :

https://github.com/torserv/torserv

https://korben.info/torserv-serveur-web-anonyme-tor-zero-config.html

lol vive Windaube 😉

Si votre site web est devenu le buffet à volonté préféré des bots de sociétés IA, débarquant par milliers, se servant dans votre bande passante et repartant sans même dire vous laisser un mot sur l’oreiller, alors j’ai une solution pour vous ! Ça s’appelle Anubis et c’est un outil qui vérifie si vos visiteurs sont de vrais humains ou des aspirateurs à données déguisés.

Car oui, personne n’est épargné ! Par exemple, le bon vieux site kernel.org a dû mettre en place une protection contre ces scrapers qui menaçaient sa disponibilité et ce n’est pas un cas isolé. Codeberg, ScummVM, FreeCAD et même certains sites de l’ONU ont adopté la même solution pour rester en ligne face à cette nouvelle forme de DDoS “légitime”.

Bref, pendant que vous lisez ces lignes, une bataille fait rage avec d’un côté, les développeurs qui maintiennent des sites utiles à la communauté et de l’autre, des armées de robots envoyés par les géants de l’IA pour aspirer tout le contenu possible afin d’entraîner leurs modèles.

Bien sûr, Cloudflare et autres services similaires peuvent vous aider, mais ils créent une dépendance à des intermédiaires centralisés, contraires à l’esprit même du web. Et franchement, si vous hébergez un petit projet open-source, vous n’avez probablement pas envie de payer pour une protection contre un problème que vous avez pas créé.

Heureusement, Anubis est là et s’inspire d’une idée plutôt ancienne : Hashcash
Il s’agit d’une idée remontant aux années 2000 pour lutter contre le spam email. Le principe est simple et génial à la fois : imposer un petit coût “computationnel” à chaque requête. Grosso merdo, comme mettre un péage sur une route qui serait insignifiant pour un conducteur occasionnel, mais super ruineux pour une entreprise qui fait passer des milliers de camions par jour.

Voici comment ça marche concrètement :

Un visiteur arrive sur votre site protégé par Anubis Le serveur lui présente un challenge mathématique à savoir trouver un nombre qui, ajouté à une chaîne de caractères spécifique et passé dans une fonction SHA-256, donne un hash avec un certain nombre de zéros au début Le navigateur du visiteur calcule alors ce hash en parallèle grâce aux Web Workers (du JavaScript qui travaille en arrière-plan sans bloquer l’interface) Une fois trouvé, le résultat est envoyé au serveur qui vérifie sa validité Si c’est bon, un cookie spécial est généré pour autoriser les visites futures sans avoir à repasser le test

Pour un navigateur moderne sur un PC normal, ce calcul prend quelques secondes, ce qui en fait une petite friction acceptable. Mais pour un scraper industriel qui doit traiter des millions de pages… c’est une autre histoire. Et ce système est totalement configurable puisqu’il permet d’ajuster la difficulté (nombre de zéros requis, par défaut 4-5), d’utiliser un algorithme intentionnellement lent pour punir les bots identifiés, et de créer des règles personnalisées via des expressions régulières et un langage d’expression appelé CEL.

Voici par exemple une règle permettant d’autoriser les requêtes API tout en bloquant le reste :

- name: allow-api-requests action: ALLOW expression: all: - '"Accept" in headers' - 'headers["Accept"] == "application/json"' - 'path.startsWith("/api/")'

Ou encore, bloquer spécifiquement les bots d’Amazon :

- name: amazonbot user_agent_regex: Amazonbot action: DENY

La bonne nouvelle, c’est qu’Anubis est ridiculement simple à mettre en place. Un VPS basique avec Docker suffit amplement et l’outil consommera moins de 32 Mo de RAM en moyenne, autant dire rien du tout à l’échelle d’un serveur récent.

La méthode la plus simple pour mettre Anubis en place, c’est comme d’hab : Docker Compose. 5 lignes de config et vous êtes protégé :

services: anubis-nginx: image: ghcr.io/techarohq/anubis:latest environment: BIND: ":8080" DIFFICULTY: "4" TARGET: "http://nginx" SERVE_ROBOTS_TXT: "true" ports: - 8080:8080 nginx: image: nginx volumes: - "./www:/usr/share/nginx/html"

Et si vous préférez les packages natifs, sachez qu’Anubis est disponible pour Debian, Ubuntu, RHEL et autres distributions populaires. Les plus bidouilleurs peuvent même l’installer depuis les sources.

La configuration avec les serveurs web les plus courants est bien documentée :

Nginx : ajoutez Anubis comme un upstream et redirigez tout le trafic à travers lui Apache : similaire à Nginx, avec quelques spécificités liées à Apache Et même Traefik ou Caddy pour les plus modernes d’entre vous

Une fois tout configuré, vérifiez quand même que tout fonctionne correctement en visitant votre site. Et si vous voyez la jolie page de challenge la première fois, puis accédez normalement au site après, c’est que tout est bon !

Si vous hésitez, sachez que avantages d’Anubis sont nombreux :

C’est gratuit et open-source, contrairement aux solutions payantes qui vous factureront à la requête Ultra-léger, avec une consommation minimale de ressources Vous gardez le contrôle total : pas d’intermédiaire entre vous et vos visiteurs Personnalisable à l’extrême : ajustez précisément les règles selon vos besoins Respectueux de la vie privée : aucun partage de données avec des tiers

Mais il y a aussi des arguments plus émotionnels, et tout aussi valables :

L’indépendance : vous restez maître de votre infrastructure La résistance : vous participez à un mouvement de défense du web ouvert La communauté : vous soutenez un projet porté par des valeurs éthiques La satisfaction intellectuelle : c’est quand même une solution élégante à un problème complexe, avouez-le

Par contre, sachez que :

Anubis nécessite JavaScript côté client Et qu’il peut potentiellement bloquer certains bots ou utilisateurs légitimes si mal configuré

Mais comparé aux alternatives commerciales, le rapport bénéfice/contrainte penche largement en faveur d’Anubis.

Bref, si vous en avez marre de voir votre bande passante dévorée par des bots trop gourmands, c’est le moment d’agir. Quelques minutes de configuration aujourd’hui pourraient vous épargner des heures de maintenance demain.

Et si vous avez des questions sur l’installation ou la configuration, n’hésitez pas à consulter la documentation officielle. Et un grand merci à Lorenper pour le partage !

– Source :

https://korben.info/anubis-protection-site-web-bots-ia.html

C’est juste pour appuyer le fait que cela arrive partout et qu’il faut arrêter de croire que ça n’arrive qu’à Microsoft…

Ça arrive partout, sur tout les OS. C’est juste qu’on en parle ++ quand c’est Microsoft et que c’est plus facile de taper sur eux.

Concernant le pare-feu, j’en utilise depuis Windows XP et aussi sous linux. Il serait en effet temps de s’y mettre, rien de plus important de surveiller les accès internes et externes de ses bécanes :

Qui fait quoi? Et qui accède à quoi ? Quand ce n’est pas un logiciel malveillant qui se fait passer pour un autre.

Ba on va dire que le serveur le supporte largement, mais largement. C’est sur qu’il faut doser, si t’es limite tu évites sinon lâche les chevaux.

L’intérêt d’un WAF n’est plus à faire non plus… N’importe quel adminsys compétent te le dira.
Puis bon, on est plus sur du pentium 4. On peut faire relativement pas mal de choses.

Si ta machine le supporte, il n’y a aucune raison valable de se priver de sécurité, bien au contraire. Ce serait suicidaire de ne pas le faire.

Voici une énorme liste de ressources d’administration système gratuites et open source.

Le gros plus est que la plupart des apps et services de cette liste peuvent être dockerisés.

Enjoy 🙂

https://github.com/awesome-selfhosted/awesome-selfhosted?tab=readme-ov-file