Vote aux législatives

Chargement du lecteur...

Les autorités russes se méfient des distributions Linux « pures » open source internationales car leur code est développé par une communauté mondiale (largement occidentale) qu’elles ne contrôlent pas entièrement : risque de portes dérobées, d’influence étrangère ou de sanctions (comme l’exclusion récente de mainteneurs russes du noyau Linux). Elles privilégient donc des forks nationaux durcis (Astra Linux, ALT, RED OS), certifiés par le FSB et conformes aux normes cryptographiques russes, tout en restant souvent dépendantes de Windows pour des raisons de compatibilité logicielle et d’habitude des utilisateurs.​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​

Envoyé par Flaneur le 19 septembre 2026 à 11h44

+ 14 -

Patou Jeune asticot

Se méfier d'un truc open source ? Il n'y a que moi qui trouve ça bizarre ?
Il me semble que si quelque chose est open source, cela veut dire que tu peux passer au crible tout le code, que ce soit pour l'améliorer, le personnaliser... ou pour vérifier s'il y a des fonctionnalités indésirables.
Se méfier d'un truc open source, pour moi c'est juste un aveu d'incompétence, non ?
+ -9 -

KukuLele En réponse à Patou Vermisseau

...ou du bullshit anti-russe qu'on abreuve régulièrement depuis un moment.
Au passage la vidéo...
Image de KukuLele
+ 2 -

Flaneur En réponse à Patou Ver TikToké

En fait c’est étonnant qu’ils utilisent une version pirate de Windows plutôt que un système open source
+ 0 -

pyjman En réponse à Patou Vermisseau

As-tu juste une idée du temps et du nombre d'observateurs (à fortiori compétents) nécessaires pour analyser une distribution Gnu Linux entière ? :-D
+ 7 -

Bidon85 En réponse à pyjman Vermisseau

Sans doute inférieur au temps nécessaire pour analyser les binaires de Windows produit par une boite américaine qui a l'obligation d'intégrer des backdoors pour les services de renseignements.

Sachant qu'ils doivent quand même analyser ces codes pour que leurs services de renseignement puisse pirater les autres machines;
+ 1 -

jeanbb En réponse à Patou Vermisseau

L'important ici, c'est "standard cryptographiques russes".
En traduction c'est "contient des autorités de confiance non approuvées et reconnues qui permettent au sous réseau russe d'internet de faire du man in the middle et décrypter le traffic https/ssl sans que les russes disposent d'une alerte sur leur navigateur
+ 1 -

Bidon85 En réponse à jeanbb Vermisseau

Parce que tu crois que les grosses boites américaines n'ont pas l'obligation de refiler les clés privées des certificats pour pouvoir le faire ?
+ -1 -

GruikMan En réponse à Bidon85 Vermisseau

Ben non.. vu récemment Apple refusant de filer les mots de passe pour décrypter un téléphone saisi par la police
+ 1 -

Bidon85 En réponse à GruikMan Vermisseau

Récemment, c'était 2016 que cette histoire a éclaté.

Mais c'est peut-être juste "pour la pub". On ne donne pas les clés mais on laisse une faille qui servira de porte dérobée et que l'on aura donné au service de renseignement/police ou que l'on ne comblera pas.
+ 0 -

jeanbb En réponse à Bidon85 Vermisseau

Bah non, vu que les autorités racines y'a pas que 1 boîte aux US qui les fournies.
Et que chaque certificat a sa propre clé privée/public donc tu peux pas remplacer avec du man in the middle. Les mecs qui font les rfc sont pas des idiots...
Mais si tu ajoute une autorité foireuses et que tu te mets au milieu... T'as le navigateur qui détecte... Sauf si l'autorité foireuse (qui remplace le certificat original) est validé sur le poste client.
Et pour ça sauf a gérer la chaîne crypto du poste tu peux pas.. filer la clé privée d'une autorité racine permet juste de générer des certificats validé, pas connaître la clé privée. Tu génère la paire public/privée, et l'autorité signe ton certificat pour garantir qu'il est authentique.
+ 1 -

Bidon85 En réponse à jeanbb Vermisseau

Sauf que toutes les boites américaines et étrangères travaillant avec les USA sont soumise à la loi américaine et aux services de renseignements des USA donc si le gouvernement les veulent, ils n'ont rien a faire car la boite sait que les sanctions ne seraient pas à son avantage et la toucherait au niveau mondial.

Si tu es un service de renseignement avec les couples clé privé/public de la chaîne de certificat, tu n'as même plus besoin d'installer un certificat sur le poste client car les signatures sont les bonnes et déjà approuvées.
+ 0 -

jeanbb En réponse à Bidon85 Vermisseau

Avec les logs de gen de certif dans le cadre du CT, les protection DNS CAA et le pinning de certif dans les navigateurs... c'est bien compliqué.
Et si un CA était corrompu a ce point, ça partirait dans la poche des CA type suisse, et rien qu'avec let's encrypt + DNSSEC courage (bien sur fort du DoH ou DoT coté client).
+ 0 -

glurp En réponse à Patou LoMBriK addict !

Je te conseille les vidéo de Dave, ancien de chez Microsoft (Le gestionnaire des tâches, c'est son invention !) :
https://youtu.b...dhfWD&t=780

Pour résumer :
- Windows est programmé par quelques programmeurs connus et bien encadrés
- Linux est programmé par des milliers de purs inconnus, et parfois le code est à peine relu faute de temps ou de compétences avant d'être intégré à une distribution
+ 0 -

Boozy LoMBriK addict !

La fameuse faille XZ de 2024 sur linux, intentionnelle, et dévoilée par hasard par contre, en est l'exemple le plus connu.
Des niveaux de confiance acquis par de simple pseudonyme (donc anonymes) après plusieurs années de "patte blanche" laissent parfois un gout amer. Quand on confie sa sécurité a des anonymes, statistiquement, un jour, on se retrouve avec un poignard numérique entre les omoplates. Parce que les bonnes intentions remplissent moins les frigos sur la durée, les plus motivés seront toujours ceux qui ont l’appât du gain en objectif.
+ 2 -

GruikMan En réponse à Boozy Vermisseau

Il y a eu a peine 2 mois entre l'introduction et la détection/correction
https://en.wiki..._Utils_backdoor
Inscrivez-vous ou Connectez-vous pour envoyer un commentaire
14