Valve publie le code source de Lepton, sa couche de compatibilité pour exécuter des jeux Android sous Linux via Steam.

Le post Valve publie Lepton pour jouer à des jeux Android sous Linux a été publié sur IT-Connect.

Source

Un programme se ferme brusquement et le terminal affiche Segmentation fault, parfois traduit par « erreur de segmentation » ? Sous Linux, ce message indique généralement que le processus a tenté d’accéder à une zone mémoire qu’il n’avait pas le droit d’utiliser. Le noyau lui envoie alors le signal SIGSEGV et met fin à son exécution.

Le message seul ne révèle pas la cause. Il faut d’abord identifier précisément l’application concernée, retrouver les événements enregistrés au moment du crash, puis examiner le core dump lorsqu’il existe. Cette démarche permet de différencier un bug de l’application, une bibliothèque incompatible, un pilote défaillant ou, plus rarement, un problème matériel.

Ce guide présente une méthode progressive avec journalctl, dmesg, coredumpctl et GDB. Il s’adresse aux utilisateurs Linux : il n’est pas nécessaire de savoir programmer pour recueillir une trace utile et choisir la bonne correction.

Guide connexe : Linux plante ou se bloque : diagnostiquer les causes et trouver l’origine

Qu’est-ce qu’une erreur « Segmentation fault » sous Linux ?

Comprendre simplement le signal SIGSEGV

Chaque programme dispose d’un espace mémoire protégé. Il y place son code, ses bibliothèques et les données dont il a besoin. Si le programme tente de lire ou d’écrire à une adresse invalide, le noyau bloque l’opération. Il envoie le signal SIGSEGV, généralement identifié par le numéro 11, puis arrête le processus.

Un segfault concerne donc d’abord un processus. Il ne signifie pas automatiquement que Linux entier est instable. Si l’écran se fige, si la machine redémarre ou si plusieurs services cessent de répondre en même temps, commencez plutôt par le guide consacré aux blocages et plantages généraux de Linux.

Les causes les plus fréquentes

• Un bug dans l’application : une mauvaise gestion de la mémoire peut provoquer un accès invalide. C’est la cause la plus probable lorsqu’un seul programme plante toujours de la même façon.
• Une extension ou un module : un greffon de navigateur, un module Python, un thème ou une extension native peut faire tomber le processus principal.
• Une bibliothèque incompatible : le programme peut charger une version de bibliothèque qui ne correspond pas à celle attendue, notamment après une mise à jour incomplète ou l’installation manuelle d’un logiciel.
• Un paquet ou un fichier corrompu : un binaire endommagé ou des données illisibles peuvent déclencher le crash au lancement ou lors d’une opération précise.
• Un pilote : les applications utilisant intensivement le GPU, le son ou un périphérique peuvent planter dans une bibliothèque liée au pilote.
• La mémoire vive : une RAM instable reste possible, mais elle est surtout suspecte lorsque des applications différentes plantent à des endroits variables.

Évitez donc de réinstaller immédiatement le système ou de remplacer la RAM après un seul segfault. Les journaux et la trace d’appels permettent souvent de réduire fortement le champ des causes.

Identifier l’application qui provoque le segfault

Reproduire le plantage et relever le message affiché

Notez l’heure exacte du problème, le nom de l’application et l’action effectuée juste avant sa fermeture. Si le programme possède une commande de lancement, exécutez-la depuis un terminal. Vous verrez ainsi ses messages d’erreur au lieu de constater seulement la disparition de sa fenêtre.

nom-du-programme
echo $?

Le code de sortie ne suffit pas à établir la cause, mais il confirme que le programme ne s’est pas terminé normalement. Ne reproduisez pas plusieurs fois une opération susceptible d’endommager des données. Travaillez sur une copie si le crash survient lors de l’ouverture ou de la conversion d’un fichier important.

Consulter les erreurs avec journalctl

Sur une distribution utilisant systemd, journalctl centralise les événements du système et des services. Commencez par limiter la recherche à la période du crash :

journalctl --since "10 minutes ago"
journalctl -b --grep='segfault|segmentation fault|SIGSEGV'

L’option -b limite la sortie au démarrage actuel. La recherche avec --grep nécessite une version relativement récente de systemd. Si elle n’est pas reconnue, affichez simplement la période utile puis recherchez le nom du programme dans la sortie.

Pour une application lancée comme service systemd, interrogez directement son unité :

journalctl -u nom-du-service --since "30 minutes ago"

Recherchez notamment le nom de l’exécutable, segfault, SIGSEGV, le signal 11 et le nom d’une bibliothèque se terminant par .so. Conservez plusieurs lignes avant et après l’événement afin de ne pas perdre son contexte.

Le guide complet :

Comment utiliser journalctl pour voir et lire les journaux Linux Systemd

Examiner les messages du noyau avec dmesg

Le noyau peut lui aussi enregistrer le processus fautif, l’adresse mémoire et la bibliothèque impliquée. La commande suivante rend les dates plus lisibles et filtre les événements courants :

sudo dmesg --ctime | grep -i -E 'segfault|general protection|trap'

Selon la politique de sécurité de la distribution, la lecture de dmesg peut être réservée à l’administrateur, d’où l’emploi de sudo. Une ligne mentionnant toujours le même exécutable ou la même bibliothèque oriente vers un défaut logiciel reproductible. Des processus très différents, des adresses changeantes et d’autres erreurs matérielles justifient une vérification plus large.

Le tutoriel complet d’utilisation :

Comment utiliser la commande dmesg sur Linux

Retrouver et examiner un core dump

Lister les plantages avec coredumpctl

Un core dump est un instantané de la mémoire et de l’état du processus au moment de son arrêt. Lorsqu’il est géré par systemd-coredump, coredumpctl permet de retrouver les crashes sans chercher manuellement un fichier core.

Selon la distribution, systemd-coredump peut être absent ou désactivé. L’absence de résultat avec coredumpctl ne signifie donc pas qu’aucun segfault ne s’est produit.

coredumpctl list
coredumpctl list nom-du-programme
coredumpctl -1 info

La liste indique notamment la date, le PID, le signal, le chemin de l’exécutable et l’état du core dump. Dans la colonne correspondante, present signifie que le fichier est encore accessible. missing indique que son entrée existe toujours dans le journal mais que le fichier a été supprimé. truncated signale un enregistrement incomplet.

Pour éviter d’analyser le mauvais crash, utilisez le PID affiché ou le chemin complet de l’exécutable :

coredumpctl info 12345
coredumpctl info /chemin/vers/le-programme

Que faire lorsqu’aucun core dump n’est disponible ?

L’absence de résultat ne prouve pas l’absence de segfault. Le stockage peut être désactivé, le fichier peut avoir expiré, votre compte peut ne pas avoir les droits nécessaires ou la distribution peut ne pas utiliser systemd-coredump. Vérifiez d’abord la limite appliquée au shell et la destination configurée par le noyau :

ulimit -c
cat /proc/sys/kernel/core_pattern

Une limite égale à 0 interdit la création d’un core dump pour les programmes lancés depuis ce shell. Pour un test ponctuel, vous pouvez ouvrir un nouveau terminal, autoriser les core dumps dans cette session, puis lancer l’application depuis ce même terminal :

ulimit -c unlimited
nom-du-programme

Cette modification concerne la session et les processus qu’elle lance ; elle ne constitue pas une configuration permanente de tout le système. Un core dump peut contenir des données présentes dans la mémoire de l’application, par exemple des documents, des URL ou des jetons de session. Ne le publiez pas tel quel sur un forum ou un gestionnaire de bugs.

Analyser le segfault avec GDB

Installer GDB et ouvrir le core dump

GDB est un débogueur, mais quelques commandes suffisent pour obtenir une trace utile sans modifier le programme. Installez-le avec le gestionnaire de paquets de votre distribution :

# Debian, Ubuntu et dérivées
sudo apt install gdb

# Fedora
sudo dnf install gdb

# Arch Linux et dérivées
sudo pacman -S gdb

Avec systemd, le moyen le plus simple consiste à demander à coredumpctl d’ouvrir le dernier crash correspondant :

coredumpctl debug nom-du-programme

Si plusieurs entrées portent ce nom, utilisez le PID relevé précédemment. GDB charge alors l’exécutable et le core dump associés. Pour un core dump conservé manuellement, la syntaxe générale est :

gdb /chemin/vers/le-programme /chemin/vers/le-fichier-core

Générer une trace avec backtrace

Lorsque l’invite (gdb) apparaît, lancez la commande backtrace, abrégée en bt :

bt
thread apply all bt
quit

La première commande affiche la pile d’appels du thread qui a planté. La seconde affiche la trace de tous les threads ; elle est utile pour les applications multithreadées. Chaque ligne représente une fonction appelée avant le crash. La trame #0 correspond au point où l’exécution s’est arrêtée, puis #1, #2 et les suivantes remontent la chaîne des appels.

Si la sortie contient principalement des adresses hexadécimales, des points d’interrogation ou la mention no debugging symbols found, les symboles de débogage manquent. Le core dump reste valide, mais la trace sera moins parlante. Les paquets de symboles portent des noms différents selon la distribution ; recherchez ceux de l’application et de la bibliothèque citée dans les premières trames.

Repérer l’application ou la bibliothèque en cause

Ne concluez pas automatiquement que la fonction affichée en #0 contient le bug. Elle peut avoir reçu des données invalides d’un appel précédent. Pour un utilisateur, l’objectif est surtout d’identifier un motif :

• le nom de l’application revient dans les premières trames : cherchez une mise à jour ou un rapport de bug correspondant à cette version ;
• une extension ou un module tiers apparaît : désactivez-le temporairement et refaites le test ;
• une bibliothèque graphique ou un pilote revient systématiquement : comparez avec les dernières mises à jour du pilote et testez, si l’application le permet, sans accélération matérielle ;
• la trace change à chaque crash et plusieurs logiciels sont concernés : examinez la mémoire et le matériel avant d’accuser une application précise.

Avant de transmettre la trace, relisez-la et retirez les chemins contenant votre nom d’utilisateur ainsi que toute donnée confidentielle. Conservez toutefois les versions des paquets, le signal, les noms des bibliothèques et les numéros de trame.

Corriger le segfault selon son origine

Mettre à jour ou réinstaller le paquet concerné

Commencez par relever la version du programme, puis installez les mises à jour normales de votre distribution. Évitez de mélanger un paquet officiel avec des bibliothèques copiées manuellement dans /usr/local ou avec une archive téléchargée depuis une autre distribution.

Si le problème touche un seul paquet et persiste après la mise à jour, réinstallez uniquement ce paquet :

# Debian, Ubuntu et dérivées
sudo apt install --reinstall <nom-du-paquet>

# Fedora
sudo dnf reinstall <nom-du-paquet>

# Arch Linux et dérivées
sudo pacman -S <nom-du-paquet>

Une réinstallation remplace les fichiers gérés par le paquet, mais ne supprime généralement pas votre configuration personnelle. Si le crash semble lié au profil utilisateur, renommez son dossier de configuration pour effectuer un essai avec un profil neuf. Gardez l’ancien dossier comme sauvegarde et ne le supprimez qu’après avoir récupéré les données utiles.

Les guides :

• Apt Linux : installer et mise à jour de package et distribution
• Ubuntu : mettre à jour les paquets et applications

Revenir à une version précédente après une régression

Un segfault apparu immédiatement après une mise à jour peut être une régression. Vérifiez l’historique du gestionnaire de paquets et la version signalée dans le core dump. Si votre distribution fournit encore la version précédente, un retour temporaire peut confirmer le diagnostic.

Ne téléchargez pas au hasard une ancienne bibliothèque depuis un site tiers et ne remplacez pas manuellement un fichier système. Une rétrogradation doit rester limitée au paquet concerné, utiliser les dépôts ou le cache de la distribution et être suivie d’une recherche de correctif. Notez la manipulation afin de pouvoir revenir à la version courante.

Vérifier les bibliothèques et les pilotes

Une trace pointant vers une bibliothèque ne prouve pas que celle-ci est seule responsable, mais elle fournit une piste. Comparez son paquet avec la version de l’application et terminez toute mise à jour interrompue. Pour un logiciel installé manuellement, testez si possible la version fournie par la distribution ou un format isolé officiellement proposé par l’éditeur.

Si le crash se produit lors de l’affichage 3D, de la lecture vidéo ou de l’ouverture d’une interface graphique, recherchez le pilote graphique dans journalctl, dmesg et la backtrace. Désactiver provisoirement l’accélération matérielle dans l’application peut servir de test, mais ce contournement ne remplace pas la mise à jour ou la correction du pilote.

Tester la mémoire lorsque plusieurs applications plantent

Une panne de RAM devient crédible lorsque des programmes sans rapport plantent aléatoirement, que les traces varient ou que les journaux contiennent aussi des erreurs matérielles. Vérifiez alors les événements du noyau et suivez une procédure de diagnostic matériel complète. L’article Diagnostiquer le matériel sous Linux en ligne de commandes détaille les contrôles de la mémoire, des disques, du processeur et des températures.

Avant un test prolongé, sauvegardez les données importantes. Si un profil XMP ou EXPO, un overclocking ou un réglage manuel de tension est actif, revenez aux valeurs stables recommandées par le fabricant pour vérifier si les erreurs cessent.

Checklist rapide pour résoudre un segfault

Les commandes à exécuter dans l’ordre

• Notez l’heure, le nom du programme, l’action effectuée et la fréquence du crash.
• Lancez si possible l’application dans un terminal pour récupérer son message d’erreur.
• Consultez la période correspondante avec journalctl --since "10 minutes ago".
• Recherchez les événements du noyau avec sudo dmesg --ctime.
• Listez les crashes avec coredumpctl list, puis ouvrez l’entrée pertinente avec coredumpctl info.
• Si un core dump est disponible, lancez coredumpctl debug, puis bt.
• Mettez à jour ou réinstallez seulement le paquet identifié, puis refaites le test.
• Si plusieurs programmes plantent de façon aléatoire, élargissez le diagnostic à la mémoire, aux pilotes, au stockage et à la stabilité matérielle.

Les informations à conserver pour demander de l’aide

• la distribution Linux, sa version et la version du noyau obtenue avec uname -r ;
• le nom exact et la version de l’application ;
• les étapes permettant de reproduire le crash ;
• les lignes pertinentes de journalctl et dmesg ;
• le signal, le PID et le chemin de l’exécutable indiqués par coredumpctl info ;
• la sortie de bt, nettoyée de toute donnée personnelle ou sensible ;
• la date d’apparition du problème et les mises à jour installées juste avant.

Cette méthode transforme un message très général en diagnostic exploitable. Dans la majorité des cas, la combinaison des journaux, du core dump et de la backtrace permet au minimum d’identifier le composant concerné et d’éviter les corrections radicales sans rapport avec la cause réelle.

Ressources utiles et articles liés

• Linux plante ou se bloque : diagnostiquer les causes et trouver l’origine
• Diagnostiquer le matériel sous Linux en ligne de commandes
• Tester et faire un diagnostic matériel de son PC sur Ubunturs
• daemon : surveiller et diagnostiquer les erreurs matérielles sous Linux
• Vérifier et dépanner un service sous Linux avec systemctl et journalctl
• Ubuntu : faire un memtest/diagnostic de la mémoire RAM
• Diagnostiquer les problèmes matériels : tester ses composants
• Stress test CPU, GPU, disque : tester la stabilité de votre ordinateur

L’article Segmentation fault sous Linux : diagnostiquer et corriger un segfault est apparu en premier sur malekal.com.

Source

Source

Andy Nguyen, le développeur qui portait le projet Linux sur PS5 , a annoncé mardi soir qu'il arrêtait tout !!! Plus de PS5 Linux, plus de scène PS5, c'est terminé pour lui. Adios donc le support de la PS5 Pro dont la sortie était prévue pour 2027.

Alors que s'est-il passé ? Hé bien pour lui, la scène était autrefois un groupe de chercheurs très doués et maintenant, c'est devenu une bande de débutants qui utilisent des LLM et écrivent des hacks qu'ils "ne comprennent même pas". Des "slop kiddies", comme il dit !

Ce qu'il leur reproche, c'est surtout d'avoir trouvé la toute dernière faille d'hyperviseur selon lui, celle qu'il avait lui aussi dans ses tiroirs, et d'être allés la signaler à Sony. Il leur avait pourtant demandé une seule chose : Attendre la sortie de GTA 6, pour que les gens puissent acheter le jeu normalement et profiter ensuite de Linux. Les slops kiddies avaient dit oui et pourtant, le lendemain, la faille se retrouvait dans les mains de Sony.

C'est moche ! Surtout que sa demande n'avait rien d'un caprice. GTA 6 sort le 19 novembre, et pour l'acheter sur le PSN il faut être à jour niveau firmware. Sauf qu'un firmware à jour, c'est ce qui referme le hack... Nguyen essayait donc de tenir les deux bouts durant des mois, en attendant que tout le monde ait son jeu.

Face à lui, on retrouve donc Jordy, celui qui a envoyé le rapport à Sony via HackerOne, et qui s'est exprimé publiquement sur cette affaire dès le lendemain. Il ne nie rien, explique que le bug est bien celui de Nguyen, qu'il lui avait demandé de ne pas le signaler, qu'il avait accepté. Mais comme quelqu'un d'autre a trouvé la même faille quelques heures plus tard, avec une IA, il l'a alors signalé histoire d'être le premier et de toucher le bounty.

Bref, tout ça, ce serait encore la faute de l'IA... Mais moi ce que je vois surtout, c'est qu'il n'y a plus vraiment d'étiquette respectée entre les hackers, qu'il soit confirmé ou du dimanche, et ça, c'est bien dommage.

Maintenant la bonne nouvelle c'est que Linux continue de tourner sur les PS5 Phat et Slim en firmwares 3.00 à 7.61, avec la sortie HDMI 4K60, l'Ethernet et le SSD M.2. Tout ça repose sur des failles que Sony a déjà corrigées et les cinq dépôts sont toujours en ligne. Bref, comme aucun n'est archivé, et que le loader est sous GPL-3.0, n'importe qui peut reprendre le travail là où Nguyen l'a laissé. Si ça vous tente !

Bref, pour moi toute cette histoire ce n'est pas uniquement un problème d'IA, c'est surtout un problème de gens qui font n'importe quoi. Je comprends donc parfaitement qu'il arrête, il doit être dégoûté le pauvre... des mois de boulot partis aux chiottes et on en paie tous le prix.

Après évidemment, Sony a poussé un nouveau firmware PS5 ce mercredi, et pas mal de monde dans la communauté, dont Jordy, incite fortement les gens qui aimerait installer Linux sur leur PS5 dans un futur proche, à ne surtout pas l'installer ! Tu m'étonnes !

Source : PC Gamer

GNOME 51 « A Coruña » est officiellement disponible. Cette version améliore la fluidité, les performances et propose plusieurs nouveautés.

Cet article GNOME 51 : Linux gagne en fluidité et simplifie le support des GPU NVIDIA a été publié en premier par GinjFo.

Pour votre système d'exploitation, une archive c'est juste un fichier. Un seul gros fichier bien opaque qu'il faut ouvrir avec un outil dédié, ou décompresser quelque part avant de pouvoir travailler dedans.

C'est pour cela que je vous présente aujourd'hui l'outil fuse-archive qui prend le problème à l'envers en présentant ce fichier comme un dossier ordinaire, en lecture seule, que vous pouvez parcourir avec ls, cat, grep, votre éditeur ou votre visionneuse d'images.

En gros, vous lui donnez l'archive, un nom de dossier, et c'est tout. Ensuite, il le monte comme une partition normale :

fuse-archive foobar.tar.gz mnt
tree mnt
umount mnt

La liste des formats supportés, c'est celle de libarchive, donc elle est assez longue : ZIP, 7z, RAR, TAR compressés de toutes les façons, ISO, paquets DEB et RPM, archives WARC du web.

Vos DOCX, vos EPUB et vos APK étant des ZIP sous un autre nom, ils se monteront pareil, et quand l'extension ne sera pas reconnue, l'outil ira lire les premiers octets pour trancher tout seul.

Et puis vous n'êtes pas obligé de vous arrêter à une archive. Si vous lui en passez trois d'un coup, il les fusionne en une seule arborescence sous le même point de montage, comme si leur contenu avait toujours été rassemblé. Avec le paramètre -o nomerge, il donnera aussi à chaque archive son propre sous-dossier, et quand deux fichiers portent le même nom, il numérote le second en file (1).txt.

Là où je trouve ça trop cool, c'est sur les archives chiffrées. En effet, un ZIP protégé par mot de passe se montera sans souci, AES-256 compris. L'outil vous demandera simplement son mot de passe. Ça permet donc de consulter un document confidentiel sans en laisser de copie déchiffrée derrière vous.

Deux limites quand même sur le chiffrement... Le format chiffré des 7z et des RAR n'est pas géré, et un fichier à double couche comme un tar.gz.gpg réclamera le paramètre -o maxfilters=2, puisque l'outil n'en traite qu'une seule par défaut.

Maintenant, cette lecture sans copie en clair nécessite que fuse-archive décompresse l'archive entière dans un fichier temporaire anonyme, posé dans votre TMPDIR ou, à défaut, dans votre /tmp. Ça peut donc prendre beaucoup de place sur le disque, et votre document confidentiel s'y retrouvera en clair jusqu'au démontage, où le fichier sera supprimé. Toutefois, avec le paramètre -o lazycache, il ne décompressera que ce que vous ouvrez vraiment, et le temporaire grossira alors au fil de vos lectures de fichiers au lieu de tout remplir d'avance. Et avec le paramètre -o nocache, il ne gardera rien sur le disque (au prix de relectures plus lentes).

Notez que ce mode lazycache ne vous fera gagner du temps et de l'espace disque que sur les formats à accès direct, du genre ZIP, 7z ou RAR. Un tar.gz, comme une archive chiffrée, sera parcouru en entier de toute façon, rien que pour lister ses fichiers.

Maintenant pour du vrai accès direct sur ces formats, je vous invite plutôt à jeter un oeil à ratarmount qui relève la position de tous les fichiers du TAR pour sauter droit à celui que vous demandez (et lui s'installe d'un simple pip install).

Ah et j'ai failli oublier, le dépôt s'appelle mount-archive, mais la commande, elle, s'appelle toujours fuse-archive.

Debian 13.7 est disponible : cette version apporte une centaine de correctifs de sécurité, voici les principaux à ne pas ignorer et les nouveautés.

Le post Debian 13.7 : plus de 100 correctifs de sécurité, voici ceux à ne pas rater a été publié sur IT-Connect.

Vous voulez vérifier un truc dans une vieille version de Python, du genre celle de 2017, histoire de voir si le bug que vous traquez vient de là. Normalement ça veut dire chercher une image Docker ou un vieux binaire de python, pour faire vos tests. Mais avec trynix, vous cliquez un lien et hop, vous avez un shell avec votre outil.

Ce site est signé Farid Zakaria, qui bricole autour de Nix depuis des années et appelle ça son "magnum opus". En gros, une machine Linux x86_64 démarre dans votre onglet, avec le paquet demandé déjà accessible dans le PATH. Rien à installer et pas de compte à se créer, ça marche direct dans le browser.

J'ai essayé ce matin avec python3 en version 3.6.2 . Le navigateur va chercher les chemins du store, vérifie leurs signatures, et au bout d'une trentaine de secondes le prompt s'affiche. Je tape alors python3 --version, il me répond Python 3.6.2, avec la glibc 2.25 et l'OpenSSL 1.0.2l de l'époque livré avec. Et voilà comment je me retrouve avec un Python de 2017 dans un Chrome de 2026, sans rien toucher à ma machine.

Le terminal de la machine virtuelle, dans l'onglet : Python 3.6.2 répond, et les seize chemins du store sont vérifiés juste au-dessus.

Et ce ne sont pas trois démos préparées à l'avance puisque l'index recense les 310 000 et quelques versions que nixpkgs a livrées en treize ans. Toutes ne démarrent pas, attention, il n'y en a que 274 729 avec un binaire x86_64 dans le cache, et le reste est non libre, cassé, ou hors du lot.

Ce qui rend la chose possible, c'est en fait une simple ligne d'en-tête HTTP. Le cache binaire de Nix sert un access-control-allow-origin: *, donc votre navigateur a le droit d'aller y piocher tout seul. Et le plus drôle, c'est que Zakaria avait lui-même réclamé cet en-tête en 2021, pour un tout autre projet. Et 5 ans plus tard, il s'en sert pour démarrer des machines virtuelles... Qui aurait pu prédire comme dirait l'autre !

Pour l'émulation, après il n'a rien réinventé. Il a tout simplement repris prend qemu-wasm , le QEMU compilé en WebAssembly de ktock, et la machine virtuelle ne boote même pas vraiment, mais reprend un instantané figé à l'avance. En tout cas, c'est bien pensé et très pratique.

Du Linux dans un navigateur, je vous avais d'ailleurs déjà montré ça ici avec cette machine virtuelle x86 . Sauf que ces trucs-là chargent une image figée à l'avance, alors qu'ici, on choisit vraiment son contenu en 1 clic.

Niveau vitesse, le projet annonce un lancement en 3 secondes, mais c'est le temps d'obtenir le shell quand tout est déjà dans le cache du navigateur. Chez moi, lors de mes tests, au premier passage, il a fallu 30 secondes, puis 7,5 secondes au suivant. Et une fois dedans ça reste poussif, parce que chaque binaire est traduit du x86 vers le WebAssembly à son premier lancement, ce qui peut faire monter le chargement à deux minutes sur les gros binaires.

Et il y a aussi un plafond puisque tout doit tenir dans la mémoire de l'onglet, soit environ 1,5 Go. Et c'est une console série, donc vous ne pourrez rien lancer de graphique, pas de fenêtre, pas de souris... Bref, que les outils en ligne de commande et rien d'autre ! Mais bon, vous êtes de vrais barbus qui n'ont peur de rien à part du déo, donc je ne suis pas inquiet ^^.

Ce qui est vraiment cool avec Trynix surtout, c'est l'action GitHub que son dev a sortie dans la foulée. Si votre intégration continue pousse déjà ses compilations dans un cache, un bot colle un lien sous la pull request et le relecteur lance le code au lieu de le lire. Comme ça, fini le clone, la compilation et le "*ça marche chez moi pourtant *" invérifiable. Même topo pour faire essayer un truc à quelqu'un qui n'a ni Nix ni Docker... Suffit de lui envoyer le lien.

Un petit point sécu quand même que je tiens à vous signaler : L'URL transporte à la fois les caches supplémentaires et les clés qui les valident, du coup la signature vous prouve bien que le binaire vient du cache annoncé... mais pas qu'il vient de quelqu'un de fiable. En effet, cliquer sur un lien trynix inconnu, ça revient à lancer le programme d'un inconnu, et même si ça se passe dans la sandbox de l'onglet du navigateur (ce qui limite les dégâts), c'est quand même mieux d'en avoir conscience !

Bref, voilà encore un chouette projet sous licence MIT et si ça vous chauffe, ça se passe sur trynix.dev .

Source : Simon Willison

Asahi Linux prend en charge les Mac M3, M3 Pro et M3 Max. Webcam, Wi-Fi, USB et décodage AV1 fonctionnent, mais pas le GPU et la mise en veille.

Le post Apple : Asahi Linux prend officiellement en charge les Mac M3, mais pas encore le GPU a été publié sur IT-Connect.

Le projet Asahi Linux vient enfin de fusionner le support des Mac M3 dans son installateur. En clair, ça veut dire que si vous avez un MacBook Air, un MacBook Pro ou un iMac équipé d'un M3, d'un M3 Pro ou d'un M3 Max, vous pouvez y installer Linux dès maintenant.

Et la liste de ce qui fonctionne est plus longue que ce que je pouvais craindre. La webcam, les micros internes, le WiFi, le Bluetooth, l'USB 3 jusqu'aux 10 Gb/s permis par la machine, et le décodage vidéo accéléré, AV1 compris.

Le Thunderbolt aussi, est même arrivé cet été. Apple avait troqué, sur les M3 Pro et M3 Max, son vieux contrôleur de ports USB contre une puce ACE3 posée sur un bus SPMI au lieu de l'I2C. Il a donc fallu reverse tout ce petit monde afin que l'USB 3 et le Thunderbolt marchent sur l'ensemble de la gamme M3.

Si vous voulez vous lancer, l'installation doit encore passer par le mode Expert de l'installeur, parce que c'est encore tout frais. Mais quand la bêta de Fedora Linux 45, sera implémentée d'ici quelques semaines, ça devrait fonctionner en install normale.

Après le gros manque, c'est la 3D. N'attendez ni performances, ni accélération 3D économe en énergie puisque tout est géré par la partie CPU du M3. Et ce n'est pas de la mauvaise volonté de la part des dev puisque le GPU du M3 s'écarte nettement de celui des M1 et M2 : ray tracing matériel, mesh shaders, et le Dynamic Caching maison d'Apple. Il y a donc énormément à refaire et même si le chantier a commencé, pour le moment, on n'a pas de date.

Les autres limites ont l'air nettement moins définitives comme pour la mise en veille qui ne fonctionne pas et le port HDMI des MacBook qui est coupé. Cela s'explique par le fait que le composant DCP qui gère ces 2 aspects là c'est pas encore piloté par Asahi, mais ça ne devrait pas tarder.

Le Mac Studio, lui, reste à la rue. Le M3 Ultra n'est pas supporté, et les M4 et M5 en sont au tout début, avec le stockage, le PCIe et le démarrage multicœur qui tournent mais pas grand-chose d'autre. Donc plus votre machine est récente, plus il va falloir être patient...

Perso, j'avais un iMac M3 et franchement, j'ai été très déçu par cette machine. Pour de la bureautique ça allait très bien, mais dès qu'on bidouille un peu fort, ça pédale dans la semoule. Je suis donc passé au Mac Studio depuis et je ne le regrette pas une seconde.

En tout cas, je sais que si je veux recycler ce "vieil" iMac M3, je peux maintenant lui installer Linux... ça vaut peut-être le coup, à condition d'assumer un desktop sans la moindre accélération 3D ^^.

Source : le billet d'annonce d'Asahi Linux et Neowin .

Télécharger un fichier depuis Internet ne garantit pas à lui seul qu’il provient bien de la source attendue ni qu’il n’a pas été modifié. Sous Linux, deux mécanismes complémentaires permettent d’effectuer ces vérifications : les sommes de contrôle pour l’intégrité et les signatures GPG pour l’authenticité.

GPG (GNU Privacy Guard) utilise la cryptographie asymétrique avec une clé privée et une clé publique. Une distribution Linux, un développeur ou un projet peut ainsi signer un fichier, une archive ou un fichier de sommes de contrôle comme SHA256SUMS. L’utilisateur peut ensuite vérifier cette signature avec la clé publique correspondante.

Dans ce guide, vous allez voir comment installer GnuPG sous Linux, importer et vérifier une clé publique, contrôler la signature d’un fichier avec gpg, vérifier une signature .sig ou .asc, valider une image ISO avec SHA256SUMS et comprendre les messages comme “Good signature”.

Nous verrons également comment distinguer intégrité et authenticité, et pourquoi il est important de vérifier l’empreinte de la clé publique avant de lui faire confiance.

Guide connexe : Vérifier la somme de contrôle d’un fichier sous Linux (MD5, SHA1, SHA256)

Qu’est-ce qu’une signature GPG ?

Une signature GPG permet de vérifier qu’un fichier ou un message provient bien de la personne ou de l’organisation qui affirme l’avoir publié, et qu’il n’a pas été modifié depuis sa signature.

GPG (GNU Privacy Guard, ou GnuPG) repose sur la cryptographie asymétrique, avec une paire de clés :

• une clé privée, conservée secrètement par son propriétaire et utilisée pour créer la signature ;
• une clé publique, distribuée aux utilisateurs afin qu’ils puissent vérifier cette signature.

Lorsqu’un développeur ou une distribution Linux signe un fichier, GPG calcule une empreinte du contenu puis crée une signature à l’aide de la clé privée.

L’utilisateur peut ensuite vérifier cette signature avec la clé publique correspondante.

Par exemple :

gpg --verify fichier.iso.sig fichier.iso

Si la vérification réussit, GPG indique que la signature est valide et précise quelle clé a été utilisée.

Une signature GPG apporte donc deux informations importantes :

• l’intégrité : le contenu signé n’a pas été modifié depuis la création de la signature ;
• l’authenticité : la signature a été créée avec la clé privée correspondant à la clé publique utilisée pour la vérification.

Cela va plus loin qu’une simple somme de contrôle SHA256. Un hash permet de vérifier qu’un fichier correspond à une empreinte donnée, mais si un attaquant parvient à remplacer à la fois le fichier et le hash publié, cette comparaison ne suffit plus.

Avec une signature GPG, l’attaquant devrait également disposer de la clé privée du signataire pour produire une nouvelle signature valide.

Il reste toutefois une étape essentielle : s’assurer que la clé publique utilisée pour la vérification appartient réellement à l’éditeur. Pour cela, il faut notamment vérifier son empreinte (fingerprint) à partir d’une source officielle.

Les signatures GPG sont ainsi couramment utilisées pour vérifier des images ISO Linux, des archives, des paquets logiciels ou des fichiers de sommes de contrôle comme SHA256SUMS.

Installer GnuPG sous Linux

GnuPG est disponible dans les dépôts de la plupart des distributions Linux. Le paquet s’appelle généralement gnupg ou gnupg2.

Sous Debian, Ubuntu et leurs dérivées :

sudo apt update
sudo apt install gnupg

Sous Fedora :

sudo dnf install gnupg2

Sous Arch Linux et dérivées :

sudo pacman -S gnupg

Une fois l’installation terminée, vérifiez que GPG fonctionne avec :

gpg --version

La commande affiche la version installée ainsi que les principaux algorithmes pris en charge.

Vous pouvez ensuite afficher le contenu du trousseau de clés avec :

gpg --list-keys

Si aucune clé n’a encore été importée, la liste peut être vide.

Pour la vérification de signatures, il n’est pas nécessaire de créer votre propre paire de clés. Il suffit généralement d’importer la clé publique de l’éditeur ou de la distribution dont vous souhaitez vérifier les fichiers.

La prochaine étape consiste donc à récupérer puis importer cette clé publique dans GnuPG.

Importer une clé publique GPG

Pour vérifier une signature GPG, vous devez disposer de la clé publique du signataire. Cette clé permet à GnuPG de vérifier qu’une signature a bien été créée avec la clé privée correspondante.

Il existe principalement trois façons de récupérer cette clé publique.

Télécharger directement le fichier de clé publique

De nombreux projets publient leur clé sous la forme d’un fichier .asc, .gpg ou similaire.

Par exemple :

gpg --import cle-publique.asc

C’est souvent la méthode la plus simple lorsque le site officiel fournit directement la clé.

Après l’import, vérifiez sa présence avec :

gpg --list-keys

Récupérer la clé depuis un serveur de clés

Voici les étapes pour récupérer la clé publique avec cette méthode :

Si vous connaissez l’identifiant de la clé, vous pouvez la télécharger depuis un serveur de clés :

gpg --keyserver hkp://keyserver.ubuntu.com --recv-keys ID_DE_LA_CLE

Le serveur de clés à utiliser dépend du projet. Il vaut mieux utiliser celui indiqué par la documentation officielle plutôt qu’un serveur choisi au hasard.

Dans le cas d’Ubuntu, par exemple, le serveur keyserver.ubuntu.com peut être utilisé.

Si vous ne connaissez pas encore l’identifiant de la clé, tentez d’abord de vérifier la signature :

gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

GPG peut alors afficher :

gpg: Signature faite le jeu. 27 août 2026 22:43:09 UTC
gpg:  avec la clef RSA 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: Impossible de vérifier la signature : Pas de clef publique

La ligne using RSA key indique l’identifiant de la clé manquante. Vous pouvez ensuite la récupérer :

gpg --keyserver hkp://keyserver.ubuntu.com \
    --recv-keys 843938DF228D22F7B3742BC0D94AA3F0EFE21092

Une fois la clé importée, vérifiez son empreinte :

gpg --fingerprint 843938DF228D22F7B3742BC0D94AA3F0EFE21092

Suivre la méthode indiquée par le projet

Certains projets ne passent pas par un serveur de clés et fournissent leurs propres instructions : téléchargement direct d’une clé, paquet contenant le trousseau de clés, dépôt officiel, ou autre mécanisme.

Dans ce cas, suivez de préférence la méthode publiée par l’éditeur ou la distribution. C’est la meilleure façon d’éviter d’importer une clé non officielle ou périmée.

Quelle que soit la méthode utilisée, ne faites pas confiance à la clé uniquement parce qu’elle a été importée avec succès. Vérifiez ensuite son empreinte numérique avec :

gpg --fingerprint ID_DE_LA_CLE

Puis comparez-la avec celle publiée sur une source officielle.

Vérifier l’empreinte d’une clé publique

Avant d’utiliser une clé publique GPG pour vérifier une signature, il est important de contrôler son empreinte numérique, appelée fingerprint.

Cette empreinte est un identifiant unique associé à la clé. Elle permet de vérifier que la clé importée est bien celle publiée par l’éditeur, la distribution Linux ou le développeur concerné.

Pour afficher l’empreinte d’une clé :

gpg --fingerprint <ID_DE_LA_CLE>

Vous pouvez aussi afficher les empreintes de toutes les clés présentes dans votre trousseau :

gpg --fingerprint

GPG affiche alors une longue suite de caractères hexadécimaux, par exemple :

0123 4567 89AB CDEF 0123  4567 89AB CDEF 0123 4567

Comparez cette valeur avec l’empreinte publiée sur une source officielle : site du projet, documentation de la distribution, page de téléchargement ou autre canal de confiance.

Les deux empreintes doivent correspondre exactement.

Cette vérification est importante, car télécharger une clé depuis un serveur de clés ne suffit pas à prouver qu’elle appartient réellement à la personne ou au projet attendu. Un serveur de clés permet surtout de distribuer les clés, pas d’en garantir l’identité.

Une fois l’empreinte vérifiée, vous pouvez utiliser cette clé publique pour contrôler les signatures GPG des fichiers téléchargés.

Par exemple, pour afficher également l’identifiant court et l’empreinte dans un format plus lisible pour les scripts :

gpg --with-colons --fingerprint <ID_DE_LA_CLE>

Si l’empreinte ne correspond pas à celle publiée officiellement, n’utilisez pas la clé et récupérez-la à nouveau depuis une source fiable.

Vérifier la signature GPG d’un fichier

Une fois la clé publique du signataire importée et son empreinte vérifiée, vous pouvez utiliser GnuPG pour contrôler la signature d’un fichier.

Le cas le plus courant est celui d’une signature détachée, fournie dans un fichier séparé comme .sig, .asc ou .gpg.

Par exemple, si vous disposez de :

fichier.iso
fichier.iso.sig

utilisez :

gpg --verify fichier.iso.sig fichier.iso

GPG vérifie alors que la signature correspond bien au contenu du fichier et qu’elle a été créée avec la clé privée associée à la clé publique présente dans votre trousseau.

Si la vérification réussit, vous obtenez un message du type :

gpg: Good signature from "Nom du signataire"

Cela signifie que le fichier n’a pas été modifié depuis sa signature.

Attention toutefois : un message Good signature confirme que la signature est techniquement valide, mais il faut encore s’assurer que la clé utilisée appartient bien à la personne ou au projet attendu. C’est pourquoi la vérification préalable de l’empreinte de la clé publique reste indispensable.

Si le fichier a été modifié ou si la signature ne correspond pas, GPG affiche au contraire un message comme :

gpg: BAD signature from "Nom du signataire"

Dans ce cas, n’utilisez pas le fichier avant d’avoir vérifié son origine ou effectué un nouveau téléchargement.

Vérifier une signature détachée .sig ou .asc

Lorsque la signature est intégrée directement dans un fichier signé, GPG peut parfois déterminer automatiquement le contenu à vérifier, mais pour les téléchargements logiciels et images ISO, la signature détachée reste le cas le plus fréquent.

Une signature détachée est stockée dans un fichier séparé du fichier d’origine. Elle porte souvent l’extension .sig, .asc ou parfois .gpg.

Par exemple :

logiciel.tar.xz
logiciel.tar.xz.asc

ou :

image.iso
image.iso.sig

Pour vérifier une signature détachée, utilisez :

gpg --verify fichier.sig fichier

Par exemple :

gpg --verify logiciel.tar.xz.asc logiciel.tar.xz

ou :

gpg --verify image.iso.sig image.iso

GPG contrôle alors deux éléments :

• que la signature correspond bien au fichier ;
• que cette signature a été créée avec une clé privée correspondant à une clé publique présente dans votre trousseau.

Si la signature est valide, GPG affiche un message comme :

gpg: Good signature from "Nom du signataire"

Si le fichier a été modifié ou si la signature ne correspond pas :

gpg: BAD signature from "Nom du signataire"

L’extension .asc indique généralement une signature encodée en ASCII, tandis qu’un fichier .sig peut contenir une signature binaire. Dans les deux cas, la commande gpg --verify fonctionne de la même manière.

Il est également fréquent que la signature porte simplement le même nom que le fichier d’origine avec une extension supplémentaire. Cela facilite l’identification du fichier à vérifier.

Enfin, même avec une Good signature, vérifiez toujours que l’empreinte de la clé publique correspond bien à celle publiée par l’éditeur. Une signature valide n’est utile que si vous faites confiance à la bonne clé.

Vérifier une image ISO Linux avec SHA256SUMS et GPG

Certaines distributions Linux publient plusieurs fichiers permettant de vérifier leurs images ISO :

• l’image ISO elle-même ;
• un fichier de sommes de contrôle, par exemple SHA256SUMS ;
• une signature GPG de ce fichier, par exemple SHA256SUMS.gpg ou SHA256SUMS.sign.

La vérification se fait alors en deux étapes.

Commencez par vérifier la signature du fichier SHA256SUMS :

gpg --verify SHA256SUMS.gpg SHA256SUMS

Si la signature est valide, GPG indique qu’elle a été créée avec une clé connue de votre trousseau.

Vous pouvez ensuite vérifier l’image ISO avec :

sha256sum -c SHA256SUMS

Si l’empreinte correspond :

ubuntu.iso: OK

Cette procédure apporte deux niveaux de vérification :

• GPG permet de vérifier que le fichier SHA256SUMS a bien été signé avec la clé privée correspondant à la clé publique importée ;
• SHA256 permet de vérifier que l’image ISO correspond exactement à l’empreinte contenue dans SHA256SUMS.

Il faut toutefois avoir vérifié au préalable que l’empreinte de la clé publique GPG correspond bien à celle publiée par la distribution Linux.

Le flux complet est donc :

Cette méthode est plus robuste qu’une simple comparaison du hash affiché sur une page web, car elle ajoute une vérification cryptographique de l’origine du fichier contenant les sommes de contrôle.

La procédure exacte peut varier selon la distribution. Certaines utilisent SHA256SUMS.gpg, d’autres .sig, .sign ou .asc, mais le principe reste le même.

Vérifier manuellement la signature d’un dépôt APT avec GPG

APT vérifie normalement automatiquement les dépôts configurés avec apt update, en contrôlant la signature du fichier Release ou InRelease. Il est néanmoins possible de reproduire cette vérification manuellement avec GPG, ce qui peut être utile pour comprendre la chaîne de confiance d’un dépôt.

Commencez par récupérer les métadonnées du dépôt, par exemple :

wget https://exemple.org/dists/stable/Release
wget https://exemple.org/dists/stable/Release.gpg

Vous devez ensuite disposer de la clé publique utilisée pour signer le dépôt. Importez-la dans votre trousseau GPG, par exemple :

gpg --import depot-public-key.asc

Vérifiez ensuite son empreinte :

gpg --fingerprint ID_DE_LA_CLE

Comparez cette empreinte avec celle publiée sur le site officiel du dépôt.

Une fois la clé validée, vérifiez la signature du fichier Release :

gpg --verify Release.gpg Release

Si tout est correct, GPG affiche notamment :

gpg: Good signature from "Nom du dépôt"

Certains dépôts utilisent plutôt un fichier InRelease, qui contient directement les métadonnées et leur signature OpenPGP. Dans ce cas :

gpg --verify InRelease

APT effectue normalement cette vérification automatiquement. Pour les dépôts tiers modernes, il est recommandé d’associer explicitement leur clé avec Signed-By et de placer les clés gérées localement dans /etc/apt/keyrings/, plutôt que d’utiliser apt-key, désormais déprécié.

Par exemple :

deb [signed-by=/etc/apt/keyrings/exemple.gpg] https://exemple.org/debian stable main

Ainsi, APT n’accepte ce dépôt que si ses métadonnées sont signées avec une clé présente dans le trousseau indiqué.

Que signifient « Good signature » et les avertissements GPG ?

Lors d’une vérification avec gpg --verify, GnuPG affiche plusieurs messages qui permettent de savoir si la signature est valide et si la clé utilisée est considérée comme fiable.

Le message le plus important est :

gpg: Good signature from "Nom du signataire"

Cela signifie que la signature correspond bien au fichier vérifié et qu’elle a été créée avec la clé privée associée à la clé publique présente dans votre trousseau.

En revanche, cela ne signifie pas automatiquement que vous pouvez faire confiance à cette clé.

GPG peut par exemple afficher :

gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.

Ce message signifie que la signature est techniquement correcte, mais que GPG ne peut pas garantir que la clé publique appartient réellement à la personne ou au projet indiqué.

C’est pourquoi il faut vérifier l’empreinte de la clé publique auprès d’une source officielle.

À l’inverse, si GPG affiche :

gpg: BAD signature from "Nom du signataire"

la signature ne correspond pas au fichier. Celui-ci a pu être modifié, corrompu ou ne pas correspondre à la signature téléchargée.

Vous pouvez aussi rencontrer un message du type :

gpg: Can't check signature: No public key

Dans ce cas, la signature est présente, mais la clé publique nécessaire à sa vérification n’a pas encore été importée.

Enfin, GPG affiche généralement l’identifiant ou l’empreinte de la clé utilisée. Vérifiez cette valeur avec :

gpg --fingerprint ID_DE_LA_CLE

En résumé :

Une Good signature est donc nécessaire, mais elle doit être associée à une clé publique dont l’empreinte a été vérifiée auprès d’une source de confiance.

Supprimer ou gérer les clés du trousseau GPG

Au fil du temps, votre trousseau GPG peut contenir plusieurs clés publiques importées pour vérifier des signatures. Vous pouvez les afficher, exporter ou supprimer selon vos besoins.

Pour lister les clés publiques présentes dans le trousseau :

gpg --list-keys

Pour afficher également leur empreinte :

gpg --fingerprint

Si vous souhaitez obtenir plus de détails sur une clé précise :

gpg --list-keys ID_DE_LA_CLE

Pour supprimer une clé publique devenue inutile :

gpg --delete-key ID_DE_LA_CLE

GPG vous demande une confirmation avant de retirer la clé du trousseau.

Si vous gérez aussi vos propres clés privées, leur suppression doit être effectuée séparément :

gpg --delete-secret-key ID_DE_LA_CLE

Attention : supprimer une clé privée peut vous empêcher de déchiffrer d’anciens fichiers ou de créer de nouvelles signatures avec cette identité. Sauvegardez-la avant toute suppression si elle vous appartient encore.

Vous pouvez également exporter une clé publique afin de la sauvegarder ou de la transférer vers une autre machine :

gpg --export --armor ID_DE_LA_CLE > cle-publique.asc

Pour une clé privée :

gpg --export-secret-keys --armor ID_DE_LA_CLE > cle-privee.asc

Conservez évidemment les exports de clés privées dans un emplacement sécurisé.

Enfin, si vous avez importé plusieurs clés portant des noms similaires, utilisez toujours leur empreinte complète pour les identifier sans ambiguïté avant de les supprimer ou de les exporter.

Intégrité et authenticité : quelle différence ?

Lorsqu’on vérifie un fichier téléchargé, il faut distinguer deux notions : l’intégrité et l’authenticité.

L’intégrité consiste à vérifier que le fichier n’a pas été modifié ou corrompu. Pour cela, on utilise généralement une somme de contrôle comme SHA256.

Par exemple :

sha256sum -c SHA256SUMS

Si le résultat affiche :

ubuntu.iso: OK

cela signifie que le fichier correspond bien à l’empreinte enregistrée dans SHA256SUMS.

Mais cette vérification ne prouve pas que le fichier SHA256SUMS lui-même provient bien de l’éditeur officiel.

C’est là qu’intervient l’authenticité.

Une signature GPG permet de vérifier que le fichier de sommes de contrôle, ou le fichier lui-même, a été signé avec la clé privée correspondant à une clé publique connue.

Par exemple :

gpg --verify SHA256SUMS.gpg SHA256SUMS

Si la signature est valide et que vous avez vérifié l’empreinte de la clé publique auprès d’une source officielle, vous pouvez alors avoir davantage confiance dans l’origine du fichier.

On peut résumer ainsi :

Pour une image ISO Linux, la méthode la plus complète consiste donc à :

• vérifier l’empreinte de la clé publique GPG ;
• vérifier la signature GPG du fichier SHA256SUMS ;
• vérifier ensuite l’image ISO avec sha256sum -c.

Ainsi, SHA256 vérifie le contenu, tandis que GPG permet de vérifier l’origine de la référence utilisée pour ce contrôle.

Ressources utiles et articles liés

• Qu’est-ce qu’une somme de contrôle (checksum) et à quoi cela sert ?
• Vérifier la somme de contrôle d’un fichier sous Windows 11/10 (MD5, SHA1, SHA256)
• Vérifier la somme de contrôle d’un fichier sous Linux (MD5, SHA1, SHA256)
• 10 meilleurs logiciels pour calculer le hash d’un fichier sous Windows
• hashcat : cracker des hashs, empreintes MD5, SHA1, SHA256
• Certificats électroniques et signatures numériques : fonctionnement et sécurité
• Signature numérique des fichiers sur Windows et sécurité
• Le chiffrement (cryptage) des données : comment ça marche et pourquoi l’utiliser
• Résoudre CMOS checksum error au démarrage du PC

L’article Vérifier la signature GPG d’un fichier sous Linux : gpg, clés publiques et empreintes est apparu en premier sur malekal.com.

Trois actualités à retenir cette semaine dans le cyberespace : une cyberattaque qui prive de télésurveillance les nouveaux pacemakers d'un géant de la santé, l'infrastructure de Linux à bout de souffle face aux scrapers IA, et des sessions Claude piratées qui alimentent un marché parallèle.

Trois actualités à retenir cette semaine dans le cyberespace : une cyberattaque qui prive de télésurveillance les nouveaux pacemakers d'un géant de la santé, l'infrastructure de Linux à bout de souffle face aux scrapers IA, et des sessions Claude piratées qui alimentent un marché parallèle.

Linux, une série de correctifs apporte un premier support USB 4 et Thunderbolt aux puces M1, M2 et M3 d'Apple.

Cet article Linux et les processeurs Apple, l’USB4 et le Thunderbolt arrivent sur les puces M1, M2 et M3 a été publié en premier par GinjFo.

De nouveaux correctifs Linux détaillent la gestion CPPC des futurs Ryzen Zen 6. AMD utilise trois valeurs de fréquence de référence, 5025, 3524 et 2399 MHz.

Cet article Zen 6 : Linux révèle l’écart de performances entre les trois types de cœurs d’AMD a été publié en premier par GinjFo.

Une série de 19 patchs apporte l'USB4 et le Thunderbolt aux Mac M1, M2 et M3 sous Linux. Mais les écrans externes et les boîtiers PCIe devront encore patienter.

Le post Le Thunderbolt arrive sur les Mac sous Linux, mais pas pour tous les modèles a été publié sur IT-Connect.