ESET a découvert des variantes Windows du malware SprySOCKS, liées au groupe chinois Earth Lusca, utilisées pour espionner des gouvernements dans quatre pays.
Le post Des versions Windows du malware SprySOCKS visent des gouvernements a été publié sur IT-Connect.
Le monde des liseuses, c'est un monde impitoyaaaable. Entre les Kobo, les Kindle, les tablettes chinoises ou encore les formats proprio des ebooks et leurs DRM à la con, c'est super difficile de faire le bon choix. Puis ça coûte cher aussi ces petits trucs... Alors si vous visez les économies, l'arrêt des prises de tête et la préservation de la planète, Episteme est un lecteur d'ebooks libre qui va vous plaire.
Il supporte de nombreux formats de livres, à peu près tout ce qui traîne sur vos disques : PDF, EPUB, MOBI, AZW3, FB2, DOCX, ODT, du Markdown, du HTML, et même vos comics en CBZ, CBR et CB7. Et le truc cool, c'est que la même appli tourne aussi bien sur Android, que Windows et Linux (c'est du Kotlin). Pas de version pour macOS par contre... snif.
Episteme sur Android et son interface en Jetpack Compose
Et surtout, avec Epistem, le cœur de lecture reste 100% local, et les trucs en ligne (genre le résumé par IA, le dico, la synthèse vocale cloud...etc) sont totalement optionnels. Notez que la version du Play Store embarque tous ces extras proprio avec achats intégrés.
Mais il existe aussi une édition "OSS Offline" à qui on a carrément retiré les permissions réseau, comme ça, votre liseuse maison ne pourra littéralement plus appeler le moindre serveur, même si elle en avait envie.
La version libre, elle, est dispo sur F-Droid et Github et fonctionne en BYOK, "bring your own key" pour y mettre votre propre clé API pour l'IA au lieu de raquer un abonnement.
Perso, je n'aime pas trop lire de livres électroniques sur mon ordinateur, et je préfère largement mon Kindle mais quand je suis obligé, j'utilise la liseuse intégrée de Calibre, et j'avoue, c'est loin d'être sexy. Episteme, lui, est quand même bien plus agréable, vous verrez...
La même appli sur desktop, Linux comme Windows
Côté confort, vous pouvez tourner les pages ou scroller vers le bas, activer la synthèse vocale, prendre des notes, placer des signets, régler la police et la taille du texte ainsi que la couleur du fond de page.
Ajoutez à cela des thèmes (Sepia, OLED, Slate), un mode reflow pour les PDF, la lecture multi-onglets, un mode musicien et les annotations à l'encre. Et si vous lisez sur un écran e-ink, le vénérable Koodo et KOReader garderont l'avantage c'est sûr, mais sur un écran classique, Episteme envoie du lourd !
Si vous galérez encore à lire vos ebooks librement , c'est clairement une piste à creuser. Ça se télécharge sur le site officiel d'Episteme si ça vous intéresse.
Besoin d'un antivirus sur votre PC Linux ? Découvrez ClamUI, l'interface graphique de ClamAV : installation, scan, protection en temps réel et quarantaine.
Le post ClamUI : un antivirus graphique pour votre PC Linux a été publié sur IT-Connect.
Linux 7.1 dévoile un pilote NTFS entièrement réécrit et un nettoyage en profondeur du noyau. Découvrez les nouveautés principales de cette version.
Le post Noyau Linux 7.1 : entre nouveau pilote NTFS et nettoyage du code, voici les nouveautés a été publié sur IT-Connect.
Plus de 400 paquets de l'Arch User Repository (AUR) ont été compromis pour diffuser un rootkit et un infostealer ciblant les identifiants des développeurs.
Le post Arch Linux : plus de 400 paquets de l’AUR piégés par un rootkit et un infostealer a été publié sur IT-Connect.
MÀJ du 12 juin : quand j'ai publié cet article, on en était à 400 paquets vérolés. Sauf que le chiffre n'a pas arrêté de grimper dans la journée. Quelques heures plus tard on parlait de 900, puis en fin de journée la liste recensait déjà 1579 paquets touchés, et les devs d'Arch précisent eux-mêmes que cette liste contient "beaucoup, mais pas tous" les paquets concernés. Bref, le décompte bouge en permanence, et il a même été suivi d'une seconde vague d'attaque encore plus sophistiquée. Donc si vous voyez circuler 400, 1500 ou 2000, c'est juste que chacun a pris la photo à un instant différent. La bonne nouvelle, c'est que les développeurs d'Arch ont depuis supprimé tous les commits malveillants qu'ils ont identifiés et estiment l'incident sous contrôle.
Si vous tournez sous Arch Linux et que vous piochez vos paquets dans l'AUR, lâchez ce que vous faites 2 minutes et lisez mon article. Car plus de 400 paquets de l'Arch User Repository ont été vérolés ce 11 juin, et le truc qu'ils embarquent ne rigole pas du tout. En effet, des chercheurs de Sonatype ont repéré une campagne baptisée Atomic Arch où un seul attaquant a réussi à glisser un stealer (un voleur d'identifiants quoi) dans des centaines de paquets d'un coup.
Mais bonne nouvelle avant de paniquer quand même, les dépôts officiels d'Arch (core, extra, multilib) ne sont pas concernés. C'est l'AUR, et uniquement l'AUR.
Si vous avez installé ou mis à jour un paquet AUR ces derniers jours, vous devez donc vérifier si vous n'êtes pas infecté. Des noms comme alvr, gnome-randr-rust ou ipfs-desktop-bin font partie de la liste, et elle est sacrément longue. Le signe qui doit vous mettre la puce à l'oreille, c'est par exemple un paquet qui n'a rien à voir avec du JavaScript et qui se mettrait pourtant à lancer un npm install durant son installation.
Pour sortir la liste de tout ce qui vient de l'AUR sur votre machine, un petit pacman -Qm fera le job, et
le forum de CachyOS
propose également un script qui compare vos paquets à la liste des vérolés connus. Méfiez-vous quand même, car ce script repère juste les noms de paquets piégés, et ne vérifie pas l'intégrité de votre système. Un résultat propre veut dire qu'aucun paquet connu n'est installé chez vous, mais pas que vous êtes tiré d'affaire, alors on reste concentré.
Alors comment ce malware s'est retrouvé dans autant de paquets ?
Eh bien l'attaquant n'a même pas eu besoin de pirater quoi que ce soit puisque l'AUR permet à n'importe qui "d'adopter" les paquets orphelins, c'est-à-dire ceux que leur mainteneur d'origine a laissés tomber. Il a donc récupéré la propriété de centaines de ces paquets abandonnés via la procédure normale, puis modifié leur PKGBUILD pour qu'à l'installation, un hook télécharge en douce un paquet npm piégé du genre atomic-lockfile. Ce paquet déploie ensuite un binaire baptisé deps, et ce deps, c'est une vraie saloperie.
Parce que ce deps, comme je vous le disais, c'est un voleur d'identifiants mais vraiment taillé pour cibler les développeurs. Dans le dos de la victime, il récupère vos clés SSH privées, vos tokens GitHub, vos identifiants npm, Docker et Podman, vos tokens HashiCorp Vault, les cookies et mots de passe de vos navigateurs, vos sessions Slack, Discord ou Telegram, vos configs VPN et même tout votre historique de commandes shell. En clair, toutes les clés de votre vie de dev qui, une fois dans la nature, ouvrent grand la porte vers d'autres systèmes.
Et si vous avez lancé le paquet en root, il installe en prime un rootkit eBPF qui se planque carrément dans le noyau pour masquer ses processus. Le fonctionnement même de ce truc fait alors qu'il est quasi impossible de détecter à l'œil nu si on est infecté ou pas. On est sur la même logique que le ver Shai-Hulud planqué dans des paquets , sauf qu'ici l'échelle a pris une autre dimension.
Alors que faire pour se protéger ?
Eh bien si vous avez le moindre doute, partez du principe que la machine est compromise, surtout si le paquet a tourné avec les droits root. Et supprimer le paquet ne suffira pas car le rootkit, lui, reste planté.
Donc on fait comme d'hab, on régénère tous ses secrets, nouvelles clés SSH, révocation et régénération des tokens GitHub, npm, Docker et Vault, changement des mots de passe stockés dans le navigateur et compagnie... Et pour la suite, comme d'hab, faites attention à ce que vous installez et prenez l'habitude de lire les PKGBUILD avant de valider, parce qu'un script post-install qui fait autre chose qu'un simple echo, ça doit vous faire tiquer direct.
Quoi qu'il en soit, l'AUR n'a jamais été audité, c'est même l'un des principes du truc et tout le monde le sait... mais des centaines voire plus d'un millier de paquets piégés d'un coup avec un rootkit qui vise vos accès, ça change fortement l'échelle du problème.
Bref, vérifiez vos paquets et faites tourner vos secrets aussi bien que vous faites tourner les serviettes quand c'est le jour du beaujolais au taf !
Et un grand merci à Maximilien pour le lien !
Une simple erreur de syntaxe, réduite à un unique caractère dans le code du noyau Linux, est à l'origine d'une faille de sécurité : CVE-2026-23111.
Le post Linux : une faille permet de devenir root à cause d’un unique caractère a été publié sur IT-Connect.
Guide complet pour maîtriser la gestion des paquets avec APT sous Linux : apt update, install, upgrade, remove et toutes les commandes essentielles sous Debian.
Le post Maîtriser la gestion des paquets avec APT sous Linux a été publié sur IT-Connect.
Mauvaise surprise pour les utilisateurs d'Asahi Linux, le projet qui fait tourner Linux nativement sur les Mac équipés de puces Apple Silicon (les fameuses M1, M2 et suivantes). La première beta développeur de macOS 27, alias "Golden Gate", distribuée le 8 juin juste après la keynote de la WWDC (la grande conférence annuelle d'Apple), fait disparaître leur partition Linux du menu de démarrage.
Le coupable est un changement dans la façon dont le boot picker (l'écran qui permet de choisir sur quel système démarrer à l'allumage du Mac) et l'application Disque de démarrage détectent les volumes jugés valides. Avec macOS 27, la partition Asahi, c'est à dire la zone du disque où Linux est installé, n'est plus reconnue comme un système amorçable.
Elle est toujours là, intacte, avec toutes vos données. Sauf que voilà. Impossible de démarrer dessus.
L'équipe du projet a publié un avertissement très clair sur Mastodon : ne mettez PAS à jour vers macOS 27 si vous utilisez Asahi. Et pour éviter les accidents, l'installateur a été modifié pour refuser de s'exécuter sur une machine déjà passée sous la nouvelle beta. Ceux qui passent outre sont prévenus, il n'y aura pas de support.
Personne ne crie au complot pour autant. L'équipe Asahi penche pour une modification accidentelle plutôt que pour une volonté délibérée d'Apple de chasser Linux de ses machines, et un rapport de bug a été déposé sous la référence FB22994760.
D'autant que la régression dépasse le seul cas de Linux : des testeurs qui gardent une ancienne version de macOS sur une partition séparée se retrouvent avec le même sélecteur amnésique. C'est donc toute la mécanique du multi-boot qui semble cassée dans cette première beta, pas une attaque ciblée contre Linux.
Une parade existe d'ailleurs pour les plus téméraires. Si une copie de macOS 26 traîne sur un second volume, il suffit de la définir comme disque de démarrage par défaut : le sélecteur se lance alors depuis cette partition, où la logique de détection fonctionne encore, et Asahi réapparaît comme par magie.
Pour rappel, Asahi Linux est né d'un travail de rétro-ingénierie assez dingue. Apple ne documente ni la séquence de démarrage de ses machines, ni le fonctionnement de ses puces graphiques, et l'équipe a tout reconstruit à la main pour aboutir à Fedora Asahi Remix, la distribution de référence quand on veut du Linux sur un Mac récent. Le projet a traversé une année 2025 agitée, avec le départ de son fondateur Hector Martin, mais c'est toujours la meilleure option pour faire vivre Linux sur ces machines.
La version finale de macOS 27 n'arrivera qu'à l'automne, ce qui laisse plusieurs mois à Apple pour corriger le tir. Le bug est signalé, la balle est dans le camp de Cupertino.
Bref, dépendre d'un sélecteur de démarrage qu'Apple peut casser à chaque beta, c'est toute la fragilité du Linux sur Mac résumée en une mise à jour.
Source : The Register
Proton travaille actuellement sur un client Proton Drive officiel pour Linux, basé sur le nouveau SDK conçu pour améliorer les performances globales du Drive.
Le post Proton prépare un client Proton Drive natif pour Linux a été publié sur IT-Connect.
Quand on est habitué à Linux et qu'on se retrouve avec un Mac, même si c'est une base unix, c'est déroutant. Heureusement, Apple est de plus en plus ouvert au monde du libre et vient de publier la version 1.0 de Container , avec dedans des "container machines" qui ressemblent furieusement à WSL. Et ça nous permet comme ça d'avoir le meilleur des deux mondes : un macOS pour le quotidien, et un vrai Linux pour vos folles bidouilles.
Vous vous souvenez forcément de mon article où je vous présentais Apple Container , cet outil écrit en Swift qui fait tourner des conteneurs Linux dans des petites machines virtuelles. Et bien un an plus tard, le projet passe en 1.0, pile pour la WWDC, et la grosse nouveauté c'est donc ce mode "machine".
Le CLI container en action, sobre comme un terminal qui bosse ( Source )
Il s'agit d'un environnement qui vous permet de faire tourner de vraies distributions Linux comme Ubuntu, Debian ou Alpine, et pas juste un conteneur modelé sur une application. La machine lance le système d'init de l'image, donc un systemctl start postgresql fonctionnera comme sur un vrai serveur.
Et à la reconnexion, à partir du même terminal ou d'un autre, l'état de la machine n'est pas perdu. Surtout, elle mappe automatiquement votre utilisateur et votre répertoire home. Votre repo vit ainsi dans le $HOME de macOS, du coup vous éditez avec votre IDE côté Mac et vous compilez côté Linux, sans étape de copie entre les 2.
Pour la prise en main, entrez les commandes suivantes en prenant soin de remplacer alpine par la distrib de votre choix :
Connexion
container machine create alpine:latest --name dev
container machine run -n dev whoami # votre user, pas root
container machine run -n dev # shell interactif
Ensuite, pour aller plus loin, vous pouvez le faire via un terminal en choisissant l'image que vous voulez ou concevoir votre propre image : n'importe quelle image Linux avec un /sbin/init fait l'affaire.
Après vous l'aurez compris parce que vous êtes les plus malins, il vous faut un Mac Apple silicon, et si ça se lance encore sur macOS 15, c'est avec des limitations et sans filet car les mainteneurs ne s'occupent actuellement que des bugs reproductibles sur macOS 26. Et migrer toute votre stack dev dessus aujourd'hui, c'est ce que je ne vous recommande pas sachant que c'est tout frais...
Mais ainsi, grâce à ces machines, plus besoin de choisir entre un Mac et une distribution Linux. Après est-ce que ça enterre OrbStack et Colima ? Pas tout de suite je pense, car ces outils tournent depuis des années sur des Mac Intel et des macOS pas tout neufs, alors que là, Apple exige sa puce maison.
Ah et côté x86, container fait aussi tourner des images amd64 via Rosetta, alors c'est le bonheur ! Et si le sujet vous branche, j'avais aussi causé de Mocker , un clone Docker natif pour Mac, et de WSL côté Windows si pour vous Mac c'est pas encore un projet ^^.
Bref, l'installeur signé est sur la page des releases , vous faites un petit container system start, et hop hop hop, à vous le kif du Linux sur votre petit Mac !
