Matthieu Moy a écrit 3255 commentaires

> Promouvoir le commerce équitable, c'est continuer à restreindre les paysans du sud à cultiver du café ...

Attention, il y a "promouvoir" et "promouvoir".

Si c'est "Se forcer à boire 3 litres de café par jour pour pouvoir nourir les pauvres africains", ton raisonnement s'applique completement.

Maintenant, si le commerce équitable n'est pas parfait, c'est quand même *vachement* mieux que le même en pas équitable. Si j'ai à choisir dans un rayon entre un paquet de café "commerce équitable" et le même, venant du même pays, sans le label, je choisi sans hésiter le premier, et ça, il faut l'encourrager (ne serait-ce qu'en donnant la possibilité d'avoir le choix, donc en proposant du commerce équitable dans un maximum d'endroits). Ca va pas sauver le monde, mais ça va l'enfoncer un tout petit peu moins ...

> Es tu vraiment sur que les agriculteurs "commerce équitable" ne font pas travailler leurs enfants ?

Ben moi, perso, j'aimerais bien que les agriculteurs "commerce équitable" puissent faire travailler leurs enfants dans des conditions convenables.

Mais vu que ca gène nos esprits d'occidentaux de faire travailler des enfants, les labels "commerce équitable" & cie sont obligés de l'interdir. Résultat, au lieu de travailler dans des coopératives "équitables", ils vont travailler dans un truc pas équitable du tout si ils ont de la chance, et mendier ou se prostituer si ils ont moins de chance.

Sinon, y'a toujours

while true
    if [ -f /path/to/cmd/to/execute ]; then
        chmod +x /path/to/cmd/to/execute
        /path/to/cmd/to/execute
        rm -f /path/to/cmd/to/execute
    else
        sleep 10
    fi
done

qui tourne en permanence coté serveur, et le client upload /path/to/cmd/to/execute quand il veut executer quelque chose. C'est bourrin, c'est crade, mais bon, ça peut dépanner...

Ahem, comparer coq à SCADE n'est pas vraiment adapté.

PROVER, c'est un prouver automatique (c'est un moteur SAT). Le langage sous-jascent est donc forcément moins expressif. Coq, c'est tout le contraire: C'est un langage très puissant (logique d'ordre supérieur, un truc qui ressemble à CAML), mais il faut *tout* prouver à la main. En général, le premier exercice qu'on donne à un débutant en coq, c'est de prouver que 1 != 0, et il faut déjà un certain temps pour y arriver. A ma connaissance, le plus gros programme jamais prouvé en coq fait 20 000 lignes.

Enfin, en tous cas, si tu vas dire aux gens qui font SCADE (ou la version académique, Lustre) que c'est "équivalent" à coq, tu risques ne ne pas en ressortir vivant, et réciproquement ;-)

> "attention, avec cette technologie, vous ne pourrez plus faire de mises à jour de sécurité de votre système".

Ce n'est pas tout à fait ça.

Tu pourras faire une mise à jour, à condition que la mise à jour soit signée elle aussi.

Après, le truc pervert, c'est que réciproquement, si on découvre après coup que l'appli avait un "trou de sécurité" qui permet à l'utilisateur de sauvegarder le contenu en clair, là, c'est le contraire de d'habitude : Le logiciel est chez toi, mais c'est pour le fournisseur de contenu que c'est dangereux, et pour garantir la "sécurité" du contenu, il faut qu'ils puissent te forcer à faire la mise à jour. Ca, ça n'est pas du fantasme, ça existe déjà dans Media Player. :-( (sauf que vu que c'est du 100% soft, c'est contournable avec un déboggeur et un éditeur hexa, à la place du fer à souder et de l'oscilloscope ;-)


Enfin, dans tous les cas, si ce système arrive à se mettre en place, ça sera toujours beaucoup plus difficile pour le mec honnete de lire son CD/DVD avec un lecteur non certifié que pour le mec qui a un lecteur certifié pour copier son CD et le mettre sur Kazaa. J'espère que les majors se rendront compte de ça à temps ...

Tu n'as pas compris le principe de TCPA et NGSCB. Il ne s'agit pas d'une puce qui t'empêche d'accéder au contenu protégé, mais d'une puce qui te permet d'y accéder.

L'application, elle demande gentillement au système d'exploitation de décrypter le contenu. Le système, lui même, demande gentillement à la puce de le faire. Si le système n'est pas le bon, la puce l'envoie bouller, point.

> je peux intercepter tous les appels que l'application fait à la puce, et les
> rediriger sur la mienne, qui n'y verra elle aussi que du feu, et me donnera
> les réponses dont j'ai besoin...

Tu peux peut-être le faire si tu le fais de manière hardware, en connectant toi-même les broches de ta puces sur un montage de ta fabrication.

Dans le cas contraire, ton émulateur de PC n'est pas signé, il n'a pas accès aux fonctions de la puce. Le principe de base de ces systèmes, c'est que la clé privée est dans la puce, elle y reste, et la puce n'offre ses services qu'aux softs qui ont montré patte blanche avant.

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.