Re: 1994

Tu me fais marrer, tu demandes de prouver l'innocence du code.

Tu veux quoi, un suivi des 500 millions d'instructions assembleur ?

Tu vois une faille/backdoor, montre la, pointe le code assembleur, montre en quoi il fait qqe chose de mal. Tu ne peux pas ? Alors comment oses-tu dires que c'est une backdoor ?

En tous cas les ingénieurs Microsoft côté Windows ont choisi d'implémenter ce standard, inefficace à la base (du retraitement d'aléa de type asymétrique pour un truc que tout le monde fait avec des méthodes du monde de la crypto symétrique, non mais franchement !), et qui s'est avéré troué.

LOL, ca oui c'est plus complique, plutot que passer 5 minutes faudra en passer 10.

Bref, une backdoor chez MS profite à MS avec pratiquement 0 inconvénients (car même si on la découvre, on dira que c'est une faille et puis c'est tout, les utilisateurs ne bougeront pas pour ça). Une backdoor dans un système open source ne profite qu'à une petite poignée de contributeur et a plein d'inconvénient (car même si on prétend que c'est une faille, le résultat est que s'il reste un soupçon, les clients migreront facilement et les réputations seront entâchées. Ça implique que les contributeurs qui ne profitent pas de la backdoor sont d'autant plus poussés à vérifier qu'elle n'existe pas car si elle existe, ils perdent beaucoup sans avoir rien gagné en échange).

Une backdoor chez Redhat profite a Redhat avec pratiquement 0 inconvenients (car meme si on la decouvre, on dira que c'est une faille et puis c'est tout, les utilisateurs ne bougeront pas pour ca)

Marrant comment ca marche des 2 cotes.