Matthieu Moy a écrit 3249 commentaires

Oups, j'avais pas vu que tu avais corrigé quelque chose. Effectivement donc ^_^

X: « Bonjour, je voudrais distribuer de la musique sous DRM »
Y: « Pas de problème »
X: « Vous avez quoi à me proposer »
Y: « Si vous voulez, je peux vous permettre de crypter votre musique et les gens ne pourront la lire qu'avec WMP. »
X: « Et quoi d'autre ? »
Y: « Bah, si vraiment vous y tenez, vous pouvez faire certifier d'autres players, mais de toutes façons, qui n'a pas Media Player chez lui ? »

J'ai employé le mot "vendre", j'aurais du dire "proposer" parce que ce n'est pas forcément payant pour Y, mais Y propose bien un service à X.

Par exemple,

http://msdn.microsoft.com/msdnmag/issues/01/12/DRM/default.aspx(...)

Qui explique comment être bien sur que le consommateur ne puisse pas lire sa musique sous Linux, en gros (ouais, j'interprête un peu, là ;-)...

> Le buffer overflow n'a pas servi à découvrir la clé

Le buffer overflow, c'est la deuxième fois. Je parlais de la première expérience, avec une Xbox modifiée au niveau matériel. Mais je ne connais pas les détails.

> Donc la seule solution pour les bloquer est de ne certifier aucune application sur serveur X et sur cet OS...

C'est bien le but. Par contre, l'OS modifié et le serveur X modifié pour gérer correctement la technologie pourraient s'identifier de manière sure auprès de l'application. Tu comprends pourquoi j'ai des doutes sur l'implémentabilité d'une solution de DRM basée sur NGSCB ou TCPA sur un système libre.

> il y aura bien un rigolo pour faire le m^eme coup avec ReactOs,
> donc on ne peut pas certifier sous Windows non plus, et ainsi de suite...

Si ReactOS n'est pas certifié, il ne pourra pas accéder aux fonctionalités DRM de la puce, donc, les logiciels qui tournent dessus ne pourront pas accéder au contenu, point barre.

Si ReactOS est certifié, c'est à l'autorité de certification de s'assurer qu'il n'y a pas de backdoor comme celle dont tu parle dedans. Et si tu essaie avec un ReactOS bricolé, tu te fais jetter parce que la signature n'est plus valide.

> Sauf si ce tra^itre de client boote le film dans un émulateur de PC...

Tu veux dire un émulateur de PC avec un émulateur de puce TCPA ou composant hardware de NGSCB, et avec un émulateur de clé secrete dedans ?

C'est bien ce que je dis un peu plus haut : Tu peux toujours récupérer la sortie analogique. C'est la copie numérique qui est vraiment plus difficile.

En résumé :

* Le mec malhonete qui a le lecteur certifié peut copier en qualité raisonnable

* Le mec malhonete qui veut télécharger sur Kazaa peut utiliser l'étape précédante

* Le mec honnete qui n'a pas le lecteur certifié l'a dans le c*l, parce que pour lui, le fait de mettre une caméra devant son écran ne lui apportera pas grand chose pour décrypter son DVD :-(

Oui, le développeur Linux peut écrire un logiciel qui utilise le driver tcpa.

Ensuite, disons que la société X distribue du contenu qu'elle souhaite protéger (musique ou autre). C'est un distributeur de musique, donc, ce n'est pas trop son role de certifier les lecteurs multimédia. Elle va donc demander à une société Y de certifier un certain nombre d'applications qui auront le droit d'accéder au contenu. Les applications sont signées avec une clé privée, et sont les seules a avoir accès à la clé qui permet de décrypter le contenu distribué par X.

Si Y est Microsoft par exemple, croit-tu qu'il mettront beaucoup de bonne volonté à certifier Mplayer, totem et xine ? Alors que justement, ils ont déjà un service de DRM basé sur WMP, clé en main, à vendre a Y ?

Par contre, ce qui peut être intéressant, c'est si X est le patron d'une entreprise, et que Y est l'administrateur système. Le patron t'envoie un truc super confidentiel et demande a l'admin de s'assurer que le document ne sortira pas de la boite. Ca, c'est une utilisation compatible avec le logiciel libre, oui.

> il lance l'application certifiée sur le nouveau serveur X...

Réponse de NGSCB : Si l'application accepte de se lancer sur un serveur X comme le tiens, elle n'aura pas la certification. Le principe de NGBSC comme de TCPA, c'est une chaine de confiance, qui part du hardware, et qui permet à chaque composant de s'assurer que les autres composants dont il dépend sont bien ceux qu'il croit.

En ce qui concerne NGSCB en tous cas, ils y ont pensé, rassures-toi :

http://www.microsoft.com/technet/security/news/ngscb.mspx(...)
• Secure path to and from the user. Secure channels allow data to move safely from the keyboard/mouse to nexus-aware applications, and for data to move from nexus-aware applications to a region of the screen.

Bref, derrière chaque argument technique contre les DRM avec support du hardware, il y a un argument pour t'imposer encore un logiciel certifié en plus :-(

> La Xbox aussi avait sa clef dans une puce.

A ma connaissance, c'était un simple checksum. Il y aurait eu un md5 à la place, la première tentative de crackage n'aurait pas été possible.

> Il suffit d'un simple buffer overflow dans la chaine...

Oui, mais là, c'est le deuxième argument massue pour faire gober le deuxième gros problème du DRM : Si un logiciel signée est jetté dans la nature, et qu'on se rend compte qu'il peut, à cause d'un buffer overflow, dumper le contenu en clair, il faut empêcher ce logiciel d'accéder au contenu, et forcer une upgrade. D'ou les clauses de la license de Media player (MS se reserve le droit de forcer une upgrade, sinon, plus moyen d'accéder au contenu protégé) par exemple, et la nécéssité pour que le système marche de pouvoir désactiver les droits d'accès à distance pour l'éditeur de logiciel.

Et puis tu devrais savoir que les gens qui exploitent les buffer overflows, c'est des terroristes, et ils méritent d'aller en prison, alors je vois pas pourquoi tu parles de ça a des gens honnetes ;-)

Ben moi, le discour de Doctorow ne me fait pas rire.

Tant qu'on reste dans le monde du logiciel, ou on peut étudier l'executable que l'on execute (c'est pas toujours facile quand c'est un binaire, mais c'est toujours "possible"), le discour est parfaitement valable. C'est comme ça d'ailleurs que CSS a été cracké, la clé privée étant distribuée avec le lecteur vidéo ...

Maintenant si on ajoute un support par le matériel, la clé secrete est *dans* une puce, et elle y reste. Il reste toujours la possiblité de passer par de l'analogique, mais pour faire une copie numérique, c'est *beaucoup* plus difficile de faire le décryptage.

Bien sur, il y aura toujours un mec sur terre qui aura à la fois 1) du super bon matériel de son/vidéo analogique 2) internet 3) un client P2P, donc, ça n'empêchera personne de se procurer les oeuvres sur internet, en qualité très raisonnable. Par contre, je pense qu'un bon "marketeux" pourra facilement vendre le concept aux majors et aux gouvernements qui votent les EUDC, DMCA, ...

Bref, le fait que les DRM softs ne marchent pas est en train de servir de prétexte pour la mise en place de DRM avec support du hardware.

C'est la que le Linuxien/BSDiste/ajouter-ici-votre-système-alternatif se fait ba*ser : Le principe même du DRM via NGSCB ou TCPA, c'est de n'autoriser que les applications signées à accéder au contenu protégé. Pour être certifiée, il faut que l'application n'ai pas la fonctionalité "sauvegarder une copie en clair", et donc forcément, qu'on ne puisse pas la rajouter. Pour quelqu'un qui veut faire un logiciel libre qui accède au contenu, on oublie : L'auteur pourra faire signer certaines versions particulières du logiciel, mais si l'utilisateur s'amuse à modifier le logiciel, ou bien à le recompiler avec d'autres options, paf, la signature n'est plus bonne, le soft n'a plus accès au contenu. Pour quelqu'un qui veut faire un logiciel non libre, techniquement, c'est faisable, mais politiquement, à la place de l'éditeur du logiciel, j'aimerais que çe soit moi qui décide si mon logiciel a le droit ou non de lire tel ou tel contenu. Avec les brevets, les grosses boites ont déjà des possiblités légales pour empêcher les concurents de faire des logiciels compatibles, et on va vers un système ou il y aura aussi de très bons moyens techniques.

En bref, l'interopérabilité avec certains logiciels propriétaires est déjà un problème aujourd'hui, mais si NGSCB ou équivalent se met en place, ça sera *nettement* pire demain.

Ca n'empêchera pas les gens de télécharger leurs DVD sur Kazaa pour les raisons évoquées plus haut, mais pour le mec qui ne veut pas passer par Kazaa, mais qui veut lire son DVD tranquilement, ça va être très chiant.

1) gv != ghostview

2) gv lit très bien du pdf

Bon, j'arrete d'être agressif et je retourne bosser ;-)

Si tu as encore le fichier tar:

tar tzf toto.tar.gz | xargs rm

Sinon, l'idéal c'est si tu connais le premier fichier créé:

find . -newer toto -exec rm {} \;

Sinon, bah, "man find" ...

> On a un réseau synchrone

s/synchrone/asynchrone/

Le consensus n'est impossible que quand tu ne peux pas borner les temps de transmissions.

> Un utilisateur unix à 2 attributs:

Pas tout à fait. Le GID n'est pas un attribut de l'utilisateur, un utilisateur peut faire partie de plusieurs groupes (c'est en général le cas).

Par contre, un fichier appartient à un utilisateur et à un groupe seulement.

C'est aussi très utile pour faire de la pub pour Qt auprès des gens qui choisissent leur langage et leur bibliothèque graphique dans un rayon de la FNAC ;-)

Ben tu prends une distrib Linux pas patchée depuis un an ou deux(pour rappel, une bonne partie des virus windowsien exploitent des failles corrigées depuis des lustres). Tu exploites une faille de mutt/pine/ajouter-ici-votre-mailer-avec-une-faille-connue, ensuite, tu exploite une faille du noyau (Un noyau d'il y a 1 an ou deux doivent avoir 4 ou 5 failles connues qui permettent de passer root), hop, tu es root.

Là, tu fais un "grep -r @ /" ou un peu plus évolué pour récupérer un max d'adresses email, et tu te forwardes à tout ce petit monde.

Pas besoin de chmod, suffit de lire son mail ...

Ben, c'est comme en C++, ça coute moins cher de ne pas fermer ses accolades, c'est prouvé scientifiquement.

==> []

En décembre 2003, on pouvait lire sur le site de free quelque chose du genre : « Le remplacement des sagems par des freebox pour les anciens abonnés sera fait début 2004 »

Maintenant, ils affichent sur leur site : « Le délai de livraison du modem Freebox est d'environ 20 jours dans la limite d'un envoi par Free de 5 000 renouvellements par mois. » et à mon avis, on peut attendre longtemps.

Free, ça reste un bon rapport qualité/prix, mais depuis qu'ils se sont lancés dans l'ADSL, ils abusent franchement de l'effet d'annonce, et je ne les ai pas vu souvent tenir les délais annoncés.

Sous Linux, tu as bien souvent un sshd ou autre qui permet aux gens de se connecter chez toi si ils ont un nom d'utilisateur et un mot de passe. Sans firewall, il faut être sur de la qualité des mots de passes (en particulier du root, bien sur)

C'est con, ce que je viens de dire, mais des gens qui mettent "toto" en mot de passe root et qui se connectent au net comme ça, y'en a plus qu'il n'en faudrait.

> Passer Gentoo sur RPM

Le LSB ne t'impose pas ça. Le LSB t'impose la _capacité_ d'installer des RPM, pas que ce soit le moyen d'installation par défaut.

Le '\0' n'est pas déconseillé mais interdit.

Le '/' est interdit, mais certains logiciels comme konqueror acceptent le '/' en l'encodant en '%2f' sur le disque.

Pour les autre caractères, ils sont tous autorisés. (Mais beaucoup sont déconseillés ...)

Crée le fichier vide `rm -rf ${HOME}`

;-)

Sinon, j'en avais un rigolo tout à l'heure sur mon compte (je sais pas comment il est arrivé là !) : ^A^K, mais les vrais caractères de controle, pas les 4 caractères imprimables ...

> Autant que je sache, le processeur est une puce.

Tiens, va expliquer ça aux organisateurs de la conférence MPSOC (un indice, ça veut dire "Multi-Processors Systems On Chip") ou je suis allé l'année dernière ;-).

Un processeur, c'est une entité electronique capable d'executer des instructions les unes après les autres. Oui, il y a du parallélisme dans les processeurs actuels (en fait, tout est fait en parallèle dans une puce, donc, bon ...), il peut y avoir plusieurs unités de calcul, mais du point de vue de ton application, la sémantique d'execution séquentielle des instructions est préservée.

Une puce à plusieurs processeurs (et il va y en avoir de plus en plus dans les années qui viennent), au contraire, contient plusieurs de ces entités. Elle est donc capable d'executer deux programmes en parallèle (et non en temps partagé comme le multitache sur un mono-processeur). Ce n'est pas transparent pour le développeur de logiciel, vu qu'il va devoir gérer le parallélisme, et éventuellemet l'hétérogénéité : Ce n'est plus rare aujourd'hui d'avoir 3 ou 4 processeurs différents (genre un processeur générique et un ou plusieurs DSP) sur la même puce.

> les commerciaux préfèrent qu'on dise multi-processeur

Je bosse dans un service de R&D sur les systèmes multi-proc. Les commerciaux, moins on en voit mieux on se porte, pourtant ...

En espérant avoir éclairci tes idées :-)

> une interface d'avance par rapport à Microsoft,

Je ne suis pas sur qu'on puisse parler d'avance. Microsoft a une version alpha ou beta (je sais plus) de l'interface de longhorn, ou il y a aussi de la 3D, de la transparence, ... Looking Glass est à peu près au même niveau dans le cycle de développement. Bref, je crois que ça permetra de ne pas être en retard, pas d'être en avance ...

> le client ne reste pas du tout dans la mémoire, semble quitter immédiatement
> sans aucune erreur (est-ce un comportement normal ???).

Essaye

strace htc -P proxy_uni:80 -F 22 mon_ip_chez_moi:80

pour le diagnostique. (D'une manière générale, strace est très pratique pour comprendre pourquoi un programme plante quand on n'a pas de message d'erreur explicite ...)

Il peut y avoir des choses dans /etc/emacs/site-start.el ou quelque chose comme ça.