free2.org a écrit 2367 commentaires

The actual burning in K3b is done by the command line utilities cdrecord, cdrdao, and growisofs.
Tu devrais faire une recherche avec les références de ton graveur et "cdrecord" ou "growisofs", pour voir s'il est bien supporté et avec quelles astuces.

le libre vaincra
Ne te trompe pas de couscoussier :)

pour être précis, "d'aucune manière" s'écrit "no way" pas "any way"

La GPL dit que l'utilisateur du logiciel libre doit avoir accès aux mêmes libertés que celui qui le lui fournit.

Ca c'est ce qui est dit dans le préambule, qui n'a pas de valeur juridique.
La partie juridique parle surtout des devoirs en cas de distribution.

Et je ne voit pas dans aucune manière improbable que les vendeurs de propriétaires rempliront des niches spécialisées
and I don't see it as being in any way unlikely that proprietary vendors will fill specialized niches.
Et je ne vois pas ceci comme étant de manière improbable que les vendeurs propriétaires rempliront des niches spécialisées.

en effet, c'est là une erreur importante à corriger dans la news

En fait la freebox, qui tourne sous Linux je crois, ne nous appartient pas. Elle est louée par Free. Et je pense qu'ils peuvent jouer sur cette notion de location pour dire: on ne distribue pas, donc on est pas soumis aux clauses GPL concernant la distribution. D'ailleurs leur Linux customisé n'est pas publié à ma connaissance.

Ce genre de "faille" sera peut-être corrigé par la GPLv3.

Le raisonement est pourtant simple: le provider va exiger que les metrics se réduisent exacetemnt au bootloader d'un OS DRM. Ce PCR sera toujours le meme si le bootloader n'a pas été modifié par l'utilisateur. Et ce bootloader se chargera lui de vérifier l'intégrité de l'OS DRM avant de le booter.

Tu oublies que le provider a le droit d'exiger que le PCR signé soit établi uniquement avec le metric d'un bootloader qui lui vérifira l'intégrité d'un OS DRM.

Pour être précis, on sera dans une situation où le provider pourra exiger que l'utilisateur lui fournisse un PCR signé établi avec exactement le metric du bootloader d'un OS DRM.

Je pense que la version anglaise de wikipedia résume bien les 2 approches possibles en matière de sécurité:
1. utiliser un OS simple et démontré fiable avec de la crypto démontrée incassble
2. avoir un OS plus complexe et non démontré, composé de "maillons" ayant chacun des faiblesses, en essayant de faire en sorte que chaque maillon soit corrigé rapidement quand un exploit sort.
http://en.wikipedia.org/wiki/Computer_security(...)

J'ai bien plus confiance dans l'approche numéro 1 qu'en l'approche numéro 2.
TCPA n'est qu'un maillon faible de plus dont on ne pourra même pas vérifier l'absence d'erreurs ou de backdoors.

Bref TCPA a inventé une IA très puissante capable de détecter tous les failles d'un OS. Bravo !

Quand aux hashs envoyés à distance, c'est bien ce que disent les papiers officiels que j'ai cité ci-dessus.

Et ce qui ne t'intéresse pas, en fait, c'est les conséquences du remote attestation pour le grand public. C'est de l'irresponsabilité.

J'ajoute que cette phrase officielle a une explication simple: il suffit à un provider d'exiger que l'utilisateur distant utilise comme metric uniquement un bootloader précis, non modifié, qui lui se chargera de vérifier que l'OS est bien un OS précis avec DRM et non modifié. Le hash sera donc toujours le meme.

"ll est impossible de deviner l'OS"
unless a trusted operating system and application were in use

Pas besoin de rebooter non plus pour que TCPA choppe des changements dans les measurements.
Ca devient vraiment surréaliste. Maintenant le moindre bug dans un OS est détecté par TCPA...

Tu es incroyable ! Le hash fait partie des metrics et est donc envoyé !

Mais le provider NE PEUT PAS savoir quel OS j'ai.
Désolé mais le hash d'un OS drm non modifié est le meme tout le temps.

un OS compromis ne peut pas compromettre TCPA.
C'est ridicule. Il y a des failles dans les OS, tu es au courant ?
Pas besoin de rebooter pour exploiter la grand majorité des failles ! Donc TCPA ne sert à rien du tout dans cette grande majorité des failles. Point.

Mais le provider NE PEUT PAS savoir quel OS j'ai.
Bon apprends l'anglais et relis les documents que j'ai cité dans ce thread, dont
"The TCPA
system reports the metrics and lets the challenger make the final decision regarding the
trustworthiness of the remote platform."
Dans les metrics il y a le hash exact de l'OS. Dans le cas d'un OS drm non modifié, ce sera toujours le meme hash.

La encore tu fais exprès d'oublier que pour accéder aux informations issues d'une configuration (OS, etc), il faut booter dans cette configuration.
Par conséquent la remote attestation permettra bel et bien de savoir quel OS on utilise vraiment pour communiquer avec le remote provider afin que celui -ci puisse refuser de nous envoyer des fichiers si celle-ci ne lui plait pas (OS sans DRM strict)

Tu te connectes à un site ou un service et pour afficher le contenu tu dois prouver que tu utilises bien l'OS et l'appli qui sont connus de ce service
Ah enfin, tu admets que TCPA fait bien cela. Je te signales que tu as bien du poster + de 10 messages dans ce thread pour dire le contraire !

Et je ne vois vraiment pas le rapport avec DRM,
Cherche bien... D'autant plus que cela a déja été évoqué dans ce thread aussi: l'OS qu'on t'oblige à utiliser sera évidemment un OS qui va t'empecher de faire ce que tu veux avec ce contenu. Ce qui est la définition exacte de Digital Rights Management.

Et en ce qui concerne TCPA, les metrics ce sont les hash des matériels et logiciels utilisés sur l'ordinateur.
Il n'y a donc pas d'ambiguité.

D'autant plus que TCPA ne sert à rien sans OS et que par conséquent il faut avoir confiance dans TCPA et et dans l'OS.
Sa mauvaise foi est de plus en plus évidente.

"The TCPA system reports the metrics and lets the challenger make the final decision regarding the trustworthiness of the remote platform."
Au début je croyais que tu ne comprenais pas bien l'anglais ou que tu te cachais les yeux pour ne pas voir une vérité qui te dérange. Maintenant cela tourne à la mauvaise foi pure et simple.

via challenge response lequel s'appuie sur les metrics
Tu parles vraiment mal l'anglais !

"a provider
will need to know that the remote platform is trustworthy" "The TCPA
system reports the metrics and lets the challenger make the final decision regarding the trustworthiness of the remote platform."

Cela veut dire que les metrics sont envoyés au remote challenger qui décide en fonction de ces metrics.
La encore c'est clair pour tous sauf pour ceux qui préfèrent rester aveugle.