khivapia a écrit 2562 commentaires

Mais c'est certainement pareil ailleurs, il faut s'attendre à ce que le PC portable soit "emprunté" quelques dizaines de minutes aux contrôles à l'aéroport. Vu de mes yeux sur une personne (pas contente, du coup) qui était là pour affaires.

(de toutes façons c'est clairement de l'espionnage, mais n'ayant toujours pas récupéré son passeport à ce stade et après un interrogatoire qui peut être un peu pénible, surtout à un horaire décalé, c'est même pas la peine d'imaginer négocier ; tout juste protester).

De nombreux sites de VPC permettent d'acheter les supports en Allemagne ou en GB. En se mettant à plusieurs, on peut amortir les frais de port.
Oui, la libre circulation des biens & services que nous a apporté l'Europe a au moins cette utilité !

* #union_soviétique
Pourtant, un monopole imposé par la loi à une société, des tarifs et des taxes imposés, une redistribution à proportion fixée par la loi, la bureaucratie qui va avec et l'hypocrisie associée, c'est du typique de l'union soviétique ce système de copie privée !

Peut-être que le réparateur n'a pas suivi les demandes répétées de Microsoft d'être plus clair dans ses factures (préciser la carte mère de remplacement, préciser la licence)
En quoi ces factures concernent-elles Microsoft étant donné qu'il est tiers au réparateur et au client du réparateur ? Du coup, pourquoi le réparateur devrait-il obéir à Microsoft ?

Malheureusement, les cartes graphiques de Via sont très mal supportés sous Linux. La faute à Via.

Comprenant ton manque de ressources à consacrer à ça, le meilleur conseil que je peux te donner est de trouver une carte graphique AMD (Radeon). Elles marchent directement à l'installation, sans pilotes particuliers.
Il s'en trouve à partir de 25€ environ en neuf, il y a peut-être moyen d'en trouver des moins chères d'occasion.
Fais attention à la compatibilité de ta carte mère (tu as donné la référence de la carte réseau !) en termes de port (AGP pour les plus vieilles, PCI, PCI-Express) graphique.

bah, compte le nombre de clics pour arriver jusqu'à ca : http://cdimage.debian.org/debian-cd/7.5.0/ia64/iso-cd/
Et encore, tu es tombé sur les images iso d'installation pour Itanium. Peu de chance que tu réussisses à en tirer quoi que ce soit pour ton desktop.

Pas forcément si on compile plusieurs fichiers en parallèle avec make -jYYY. Chaque erreur arrête son propre fil sur les YYY demandés.

Le lien que tu pointes est une bibliothèque et le problème était qu'elle utilisait le standard troué de génération de nombres aléatoires.

Le plus souvent, le fait de faire un don du montant de son choix est fortement apprécié. Les fonctionnalités le sont donc également, mais par rapport au prix et à la facilité de prise en main du logiciel.

Le côté éthique est généralement reçu avec une indifférence polie.

et qui ne donne aucune info (donc pas de statistiques) a Coverity.
Même pas de statistiques anonymes ? Tu as vu le code ?

Après le DES (1978), la NSA a quand même promu des algos sûrs (AES, qui peut servir à chiffrer des données classifiées US, tout de même !) mais s'est concentrée sur les systèmes à clef publique, les générateurs d'aléa et la génération des clefs (DSA, bonjour !).

Qui parle d'Adobe, MS etc. dans l'article ? Et que sait-on des relations de clientèle entre Adobe et Coverity ?

Ensuite, si les enterprise projects sont bien ce que tu affirmes, il s'agit sans conteste de la plus grosse quantité de logiciels propriétaires : ce sont justement eux qui font vivre les SSII.
Il est donc vrai d'affirmer qu'en toute généralité, le logiciel libre est bien meilleur que le propriétaire. Après, on pourra toujours trouver un logiciel propriétaire de meilleure qualité qu'un logiciel libre on ne pourra jamais évaluer la qualité d'un logiciel propriétaire vu qu'on n'en a pas les sources.

Pour comparer la qualité des logiciels libres et propriétaires il faudrait sélectionner des logiciels fonctionnellement équivalents, avec également une popularité et une maturité relativement proches.
Ou alors suivre l'évolution d'un indicateur, fût-il imparfait.

L'intérêt principal de cette étude est qu'elle est faite tous les ans avec la même méthodologie, et qu'on peut en suivre l'évolution. Même s'il existe des biais, il est clair que le logiciel libre a fait de gros progrès.

Concernant les biais possibles, le nombre de logiciels testés (aussi bien libres que propriétaires) est tout de même très large.

ou mieux, un nœud de sortie Tor.

Non. L'affaiblissement du générateur d'aléa (EC_DRBG) est lié à un problème similaire à une clef publique : n'importe qui peut comprendre le problème, mais récupérer la solution qui l'affaiblit sans avoir l'info secrète de la NSA revient à résoudre un problème de logarithme discret sur courbe elliptique, c'est-à-dire à savoir péter à peu près tous les systèmes actuellement en cours de déploiement.
Cf les slides http://www.wired.com/images_blogs/threatlevel/2013/09/15-shumow.pdf (slide 8, deuxième point).

Dans ce cas, la NSA a affaibli le standard pour elle seule.

En abaissant la sécurité de tous, l'ennemi peut avoir autant voire plus d'informations qu'eux.

La NSA est plus maligne que ça : pour le générateur d'aléa troué, seule la NSA peut profiter de la vulnérabilité (en connaissant la clef privée, c'est un système quasi à clef publique). Les autres peuvent se brosser.
Dans l'affaiblissement de Notes il y a quelques années, c'était la même chose : les clefs 128 bits étaient séparées en 40 bits d'un côté, 88 autres qui étaient chiffrés sous une clef publique NSA. Seule la NSA pouvait déchiffrer, la sécurité du bousin restait de 128 bits pour le reste du monde.

Pas sûr : le révéler et expliquer publiquement qu'on n'envisage aucunement de se suicider ni de faire des sports dangereux jettera un doute sérieux sur le commanditaire d'un éventuel assassinat… Les services d'espionnage restent toujours dans le déni plausible (en s'abritant par exemple derrière l'incompétence du NIST en matière de sécurité pour la NSA) et refusent de signer leurs forfaits.

Affirmer que le C++ est un langage sûr quand il est utilisé par des développeurs sûr ça n'a pas de sens.

Ce n'est pas ce que je disais. Je disais qu'il est facile d'éviter les constructions subtiles qui peuvent mener à des failles de sécurité en C++ (en particuliers les pointeurs nus).
Après comme partout un langage est aussi sûr que ses développeurs en ont l'expérience, pas plus, pas moins.

ils ai interdit l'utilisation des pointeurs nus.

Non : garder les pointeurs nus peut permettre un gain en performances dans des cas extrêmement particuliers (type HPC). Du coup pourquoi les retirer ?
Par contre ils ne devraient pas être utilisés dans un bout de code chargé de faire de la sécurité. D'une il n'y en a pas besoin dans ce cas, de deux, les utiliser se verra et aucun développeur ne pourra trouver de bonne raison de le faire dans ce cas là.
C++ permet donc de faire de la merde, comme tout langage, mais il faut vraiment faire exprès d'utiliser les mécanismes bas niveau quand le langage propose des solutions simples et sûres (à l'inverse du C qui nécessite une bonne dose de discipline personnelle).

figure-toi qu'il n'y en a pas non plus en C/C++

Pardon ? Chez moi j'ai un joli fichier wmmintrin.h fourni par GCC, qui contient les fonctions C à appeler sur des données C, que le compilateur remplace par l'instruction AES-NI si elle est présente.
Idem avec la quasitotalité des fonctions vectorielles.

et qu'il n'y en aura probablement jamais vu comment ces opcodes ont un usage très spécifique

Ce n'est pas comme s'il était impossible de générer des codes path différents à l'exécution si jamais l'instruction n'était pas présente sur le CPU.

la rotation de bit,

La rotation de bits s'écrit en une macro C ou une fonction template C++ avec 2 shift et un OR, et ce n'est pas comme si les compilateurs ne détectaient pas le pattern depuis au moins 10 ans pour le remplacer par l'instruction spécifique si besoin.

Ok, donc en pratique quel est le problème avec checkinstall ?

Je propose clairement une solution sans l'avoir testée. Toutefois, je pensais que la majorité des problèmes que tu soulèves (chemins d'install, numérotation des libs) sont résolus pas une standardisation du genre de LSB ?

quand j'achète un CPU, tu n'en offres 99 du même type
J'offre une implémentation bitslice qui permet de traiter le chiffrement 64 fois plus vite pour 64 clients en parallèle, ce qui est certainement plus efficace pour l'AES que les implémentations standard (l'AES n'a pas été inventé pour être spéclamement efficace pour les plate-formes logicielles 64 bits).

Qui va être aussi rapide que l'ASM avec AES-NI, oui ou non?
Sans aucun doute avec les intrinsics C/C++ de gcc, qui devraient être présentes dans les autres langages et permettent de faire de l'assembleur avec la rigueur d'un appel de fonction bien connue par le compilateur.

Je voulais dire qu'il y aura certainement en Rust des fonctions intrinsics qui permettent d'appeler directement les opérations assembleur d'un chiffrement AES, comme il y en a déjà en C/C++ avec gcc et d'autres compilateurs. Sinon ce serait une grosse limitation de Rust.
L'intérêt de ces fonctions est de pouvoir faire de l'assembleur avec la rigueur sémantique d'une fonction du langage.

comment Rust s'assurera qu'il n'y a pas de buffer underrun dedans:
Faire appel aux fonctions intrinsics ?