Bruno a écrit 270 commentaires

La FreeBox ca dechire

Aie, tu m'étonnes ! Meme avec de la vaseline... C'était ta première fois ?

[(c) fortunes de la tribune : http://quadaemon.free.fr/tribune.fortune(...) ]

->[jesors]

Contre le SdA, ya les Prservatfs ...
ok ->[jesors]

Gallery est pas trop mal : http://gallery.sourceforge.net(...)

De mémoire, une citation du "petit guide du francais correct" :

"2 personnes à un comptoir :
- Barman, une pinte de bière s'il-vous-plaît !
- Autant pour moi ! Euh ... au temps pour moi, un jus d'orange plutot"

Pour faire d'une pierre 2 coups, on nous ressort aussi un nouveau Commodore 64 dans un boitier ATX : http://c64upgra.de/c-one/(...) (cf. http://slashdot.org/articles/03/02/01/2035204.shtml?tid=127&tid(...))

On a déjà droit à une taxe sur les supports numériques, est-ce que ca veut pour autant dire qu'on devrait se faire taxer sur tout ce qui peut faire transiter du contenu non légalement acquis ? Dans cet ordre d'idées, pourquoi ne pas taxer :
* Les cartes réseau
* Les modems
* Les cables RJ45
* Les cartes-son
* Les claviers et les souris (le truc par lequel on tape les requêtes pour récupérer les mp3 via p2p)
* Le perchlorure de fer (ben oui, si je me construit un circuit imprimé, je peux y faire passer du son)
* Le plastique (on peut faire une boite de CD qui contiendra un CD avec des mp3 piratés)
* Le mètre cube d'air qui peut faire transiter des contenus illégaux jusqu'à nos oreilles

Et puis après tout, c'est bien "grâce" à FT qu'on a une ligne de téléphone chez nous, pourquoi on ne taxe pas les gens qui ont le téléphone non plus ? C'est vrai, ils peuvent y brancher un modem...

La dernière fois que j'ai cherché, c'était directement chez les "fondeurs", à savoir Schlumberger ou Oberthur, et il fallait compter 50-60 euros pour le lecteur et environ 80$ pour 5 cartes à puce avec cryptoprocesseur intégré. Maintenant ya le choix de la techno (souvent propriétaire) à l'intérieur, soit du java (cf. les javacard), soit du multos, soit du microsoft, soit... Coté soft, il me semble qu'il est prévu dans openssl de gérer des systèmes de crypto externes/hardware, mais je ne suis pas sûr que tout soit disponible, du moins sous linux...

En fait j'ai fait une bourde en parlant de "gros volume". Ce que je voulais évoquer, c'est surtout (par exemple) les sites https qui ont beaucoup de connexions et impliquent beaucoup de créations de clefs de session. Par contre, comme le fait justement remarquer Tselek, j'en étais resté à la norme iso7816 qui me semble-t-il limite les comms à 9600 bauds ... peut-être que maintenant on n'a plus besoin d'avoir des racks de cartes à puce pour augmenter les perfs.

L'inconvénient des cartes à puce c'est quand même leur débit : on ne peut pas se permettre de chiffrer des gros volumes avec une carte à puce, à moins de ne pas être pressé. Stocker les clés en lieu sur, ok. Le problème vient ensuite : des clés, appartenant à qui et pour quoi faire ? GPG pourrait bien reposer sur TCPA par exemple. Mais je ne crois pas que les gens qui ont sorti ce bousin l'ont fait pour GPG. Je vois aussi un gros avantage pour apache : combien de serveurs HTTPS ont aujorud'hui une clef privée en clair dans un fichier pour éviter que les admins aient à saisir leur passphrase à chaque redémarrage du serveur. Sans compter que même avec une protection par passphrase, la clef privée en clair réside quelque part dans l'espace mémoire du process, donc a priori visible pour quelques pirates acharnés...

Y'en a bien qui passe d'une version 6.0 à une version 95 ...

La reflexion se tient peut etre mais .... tu crois qu'il y aura un organisme assez con pour signer quelque chose qui ne garanti rien sur le soft derriere ?
Boarf, en rêvant un peu ;)

Mais cela amène à une autre question : sur quels critères un organisme certifiant va-t'il signer une application ?
- Plein de $$$ ? (ça m'étonnerait guère)
- La fourniture par le demandeur de tout le code source avec un audit de l'organisme certifiant, avec toujours la possibilité que le binaire ne corresponde pas aux sources ? (ou alors l'organisme certifiant recompile lui-même le source)
- une certaine confiance envers le code généré avec quelques tests pour vérifier que ça fonctionne et que c'est pas (trop) troué ?

Petite réflexion à voix haute, arrêtez moi si je me trompe (et je me trompe probablement, parce que ca me parait un peu simpliste comme approche) :
De ce que j'ai compris pour avoir accès aux fonctionnalités de TCPA, il faut booter sur un OS TCPA. Mais c'est quoi cet "OS" ? Le premier programme qui va être chargé en mémoire ? Plus précisément, le code binaire (signé) qui sera chargé par le bios au tout début ?
Du coup, si seulement LILO est signé, et que ce même LILO se contrefout de vérifier la signature de ce qu'il lance, on aura accès aux fonctions de TCPA, sans un OS TCPA ? Personnellement, je ne recompile pas lilo tous les jours...

Toujours dans la même pensée : quid des exploit par buffer-overflow (par exemple) dans une application TCPA ? S'exécutent-t'ils dans un milieu "de confiance" ? Car à ce moment, en extrapolant un peu, il serait possible court-circuiter telle ou telle fonction et faire un peu tout ce qu'on veut, non ?

Tout ça rappelle un peu la license de Frontpage (r)(tm)(c):

[...] Vous n’êtes pas autorisé à utiliser le Logiciel avec des sites qui dénigrent Microsoft, MSN, MSNBC, Expedia ou leurs produits ou services, qui portent atteinte à leurs droits, notamment leurs droits de propriété intellectuelle [...]


cf. http://linuxfr.org/2001/09/22/5091.html(...)

"ou sur [mettre ici un site chez ovh ou autre]" Ben, le meilleur exemple : ftp.fr.debian.org (alias debian.proxad.net) :(

... tant qu'à faire, autant muter génétiquement les prochains nouveaux-nés, pour qu'ils aient une écoute sélective et n'entendent que ce qu'ils auront payé. A mon avis, l'ADN doit faire une belle clef de cryptage, non ?

Fastoche, ca doit se faire en 42 octets... même moins, puisque pour la même taille, y'en a qui auraient aussi réussi à lire de la vidéo, et à très bas débit en plus ;)

[-1] et je -->[]

Pour les medecins c'est Voici, Gala et autres trucs.
C'est trop tard alors, parce que vu l'age des Voici, Gala et autres qu'on trouve dans les salles d'attente, si l'article parait aujourd'hui, les gens le trouveront dans 5 ans chez leur toubib ...

Le Monde touche pas mal de "décideurs" comme on les appelle
L'idéal serait qu'un tel article passe dans le 01, mais bon faut pas rêver non plus ;)

[projection dans 5 ans^Wmois, avec Palladium TCPA bla blabla]

... et quand bien même tu aurais le source et (rêvons on peu) le compilateur et l'environnement qui vont bien, ca n'avancerait à rien puisque tu ne pourras pas signer ton OS pour qu'il soit accepté par notre cher ami Fritz.

Et puis si ce n'est pas compilable, ça va être super à analyser. Vous avez déjà cherché des failles sur un source imprimé sur du papier, sans pouvoir tester quoi que ce soit ?

Autre point : si le code est fourni aux gouvernements, c'est aux gouvernements que sera confié le rôle d'analyser/corriger les failles potentielles^W. Est-ce bien pertinent (en termes d'adéquation/compétence des personnes) ? Ce que je vois c'est qu'au final, c'est le brave contribuable qui financera le débogage des produits Microsoft :(

Extrait de Slashdot : "This story on Bloomberg.com details Microsoft's new program to open the source to parts of Windows in order to compete with Linux"
A priori c'est donc juste des parties de windows qui seront "ouvertes".

Depuis qu'on rabache à tout-va à Monsieur tout-le-monde qu'il ne faut se fier qu'à des organismes "de confiance" pour installer tel ou tel logiciel, qu'il faut se méfier des pièces jointes aux mails, qu'il faut bien lire les boites dialogue "attention, ce fichier contient des macros. Les désactiver ?" ou "Ce fichier provient de l'internet et peut contenir un programme malveillant. l'exécuter quand même ?", et depuis que Monsieur tout-le-monde s'est choppé 3 mélissa et 2 nimda, je pense que le mot "sécurité informatique" fait tilt dans la tête de pas mal de gens, surtout quand le mot "virus" fait 5 cm de haut sur la première page d'un magazine. Ah, paranoïa, quand tu nous tiens ... et après on se demande comment TCPA/Palladium arrivera à passer, vu tout ce cela promet en apparence.

Maintenant je serais curieux de voir le nombre de "profanes" ayant acheté ces magazines sans les feuilleter, en pensant apprendre le remède ultime pour sécuriser leur machine, et qui se sont cassé les dents sur la technicité et le détail des articles ;)

Personnellement, je préfère UTSL à RTFS ;)
[-1]

STFW

Ca va coûter très cher à casser, et ca va aussi coûter très très cher en temps de calcul aux puces dédiées au chiffrement/déchiffrement (surtout en phase 2, avec les instruction cpu chiffrées). Je présens une chute de performances des machines... qui a dit que l'Atari ST était lent ? ;)
D'un autre coté ça incitera les codeurs d'usine à gaz à optimiser un peu leur code ;)

Super bon, c'est meme la 3.2.2 CVS qui n'est pas encore dispo officiellement (en stable j'entends).

Ca tombe bien, la 3.2.0 avait des petits soucis, notamment sur architecture arm. Une petite note tout de même : toolchain (package pour les cross-compilations) ne semble pas encore avoir migré en 3.2.2. Donc pour les cross-compilations du noyau sur arm il va falloir attendre encore un petit peu.