free2.org a écrit 2367 commentaires

Ouais enfin la programmation avec des pipes est probablement la manière la plus simple de programmer des choses difficiles.
Tout le monde peut comprendre le principe des "boites noires" (processus) qui prennent des données en entrée, les traitent et les émettent en sortie.

Ca doit meme pouvoir se faire graphiquement pour les allergiques du clavier.

Sous linux, le type time_t est en fait un 'long int'.
Ouais enfin c'est pas bien dur de changer le typedef pour en faire ce qu'on veux !
C'est même d'ailleurs exactement pour cela que time_t est utilisé, et pas autre chose.

ok tu es donc en sid/unstable
c'est un peu bizarre que ces fichiers étaient immuables.... Il faudra peut-etre que tu demandes des explications aux autres admins de la machine.

il faudrait bien + d'informations car les causes peuvent être diverses:
ls -al des principaux répertiores concernés (dont /)
df
cat /e/mtab
cat /e/fstab
...

woody unstable
Cela n'existe pas.

woody = oldstable
sarge = stable
etch = testing
sid = unstable

Vérifie que toutes tes lignes sources.list ne contiennent que woody ou oldstable

Si tu as installé des paquets unstable en + des paquets woody, tu peux mettre à 1100 la priorité de oldstable dans /etc/apt/preferences pour essayer de les faire revenir à leur version woody avec apt-get upgrade. Voir ma page à ce sujet: http://free2.org/d/(...)

Je te conseille surtout de passer à sarge.

./usr/sbin/locale-gen
tout vient peut-etre du . dans cette ligne (et probablement d'une mauvaise config dans /etc/apt qui fait que ce . n'est pas / )
essaye de faire un cd /
avant de lancer apt-get

https://linuxfr.org/forums/36/9283.html(...)

Je crois que le principal problème vient de la confirmation qui est demandée par le nouvel apt en cas de non signature d'une archive.
Du genre "certains paquets n'ont pas de signature valide, voulez-vous continuer ?"

Cette confirmation n'est pas prévue par certains front-ends et peut les faire disjoncter.

De même certains front-ends ne sont pas prévus pour gérer les clés publiques permettant de vérifier les signatures.

en disant des développeurs, j'ai bien voulu dire la même chose que toi

les conteneurs APT sont à présent bien signés (cf. le Release.gpg)
Ils sont signés depuis des années pour stable/testing/unstable/experimental/security .

mais la version d'APT qui vient avec sarge est une vieille version qui n'utilise pas cette fonctionnalité...
La version d'experimental n'est pas compatible avec certains front-ends comme synaptic (cependant un aptitude compatible est maintenant aussi dans experimental).

unstable == sid , c'est comme ça et ca le restera ce sont les derniers paquets qui n'ont pas vraiment été testé.
A noter que des développeurs testent leur paquets dans experimental avant de les envoyer dans unstable.

il y a aussi testing, qui en + devrait disposer maintenant aussi de security.debian.org
http://secure-testing.alioth.debian.org/(...)
http://newraff.debian.org/~joeyh/testing-security.html(...)

La menace sur le libre est certes grave.
Mais il faut aussi penser à tous ceux qui vivent dans une dictature et qui ne pourront se connecter qu'en utilisant des OS et des applications aprouvées par le gouvernement, sans contrefaçon possible grâce à ces nouvelles puces.

mais c'est plus pratique avec qu'en utilisant de la crypto à passphrase, des flash en ROM, etc.
1. Avoir des données automatiquement accessibles, sans avoir à donner de passphrase, c'est pas recommandé. Même avec TCG.

2. De la meme manière que tcg n'est pas très pratique sans logiciels adaptés, un boot sur flash aussi. Mais il est très facile d'installer un logiciel de type tripwire sur une flash.

Que tu refuses de la reconnaitre libre à toi,
J'attends toujours que tu reconnaisses que la seule vraie nouveauté apportée par TCG est la remote attestation.

Des puces/cartes pour accélérer le cryptage ça existe depuis longtemps.
Des générateurs aléatoires hardware aussi.
Des roms flash avec mode read-only pour booter de manière secure, aussi.
Des partitions encryptés, aussi.

La seule application originale des puces de type TCG est le remote attestation.
Et le remote attestation ne peut se faire sans une puce de type TCG.

Tu oublies la technologie dite "PC"
La technologie PC n'est pas figée, et elle évolue aussi sous la pression des utilisateurs. Exemple: le numéro d'identification des pentiums 3 qu'Intel a été obligé de retirer sous la pression des utilisateurs qui ne voulaient pas être fliqués par leur logiciels.
C'est à nous d'obtenir la même victoire pour la remote attestation, car il s'agit d'une technique encore plus intrusive que le serial ID des p3.

*X est inutile
*si X est massivement utilisé, alors Y (méchant, méchant !) arrivera forcément
Tu oublie 2 grosdétails.
1. X n'a pour seule utilité Y
2. Y n'est possible qu'avec X

Puisque tu aimes jouer au gros naïf... Une interface graphique ne permet pas la "remote attestation". Seules les puces de type de TCG le permettent.

tu m'imagine qu'un utilisation ( qui plus est irréaliste ) de TCPA, la distribution de contenue,
Ce n'est pas irréaliste puisque meme TCG/TCPA conviennent que c'est tout à fait possible. Cela offre la certitude que les logiciels et les matériels sont bien ceux que le distributeur veut. Hors sans une puce comme TCG, il est impossible d'avoir cette certitude.

Toutes les applications de TCG sont possibles sans une telle puce. Sauf le remote attestation.

si ont pouvait revenir sur le font du problème cad en quoi l'utilisation de TPM en tant que systéme de vérification d'intégrité, de module de sécurité et de cryptage est elle dangereuse dans une architecture logiciel libre, open source et maitrisée ?
1. On en a pas besoin puisque on peut avoir un OS dont le hash est vérifié et des données encryptées sur le disque, sans utiliser TCG
2. Parce que si tout le monde utilise TCG, alors il sera facile d'obliger les gens à faire du remote attestation.

allez en voici un très officiel pusique cela vient de TCG lui-meme:
remote attestation
capability to ensure that the user is employing a configuration that the provider
insists upon, even when there is no security reason for such a choice. Another
situation that can arise is where a significant portion of the providers of a particular
service could use their market clout (the fact that they constitute a majority of
providers of that particular type of service) to essentially force the use of TPM
technology. As a consequence, users who do not choose to employ TCG technology
would be essentially unable to access that service.
9
The TCG believes that such
behaviors are inappropriate uses of the TCG technology. The use of coercion
to effectively force the use of the TPM capabilities is not an appropriate use of
the TCG technology. However, preventing potentially coercive and anticompetitive
behavior is outside the scope of TCG

http://66.102.9.104/search?q=cache:https://www.trustedcomputinggrou(...)

Le partie en gras revient à dire: on regrette que ce soit possible, mais ça l'est et ce n'est pas notre role de l'interdire.

Pour ceux qui ont du temps (moi j'ai déja donné :) ) et qui veulent vérifier, tapez dans votre moteur favori les requetes suivantes:
tcpa "remote attestation"
tcg "remote attestation"
"trusted computing" "remote attestation"

Faites-nous part de vos meilleurs liens.

Pour les fainéants voici déjà un lien google:
http://www.google.fr/search?num=40&hl=fr&ie=ISO-8859-1&(...)

Si le prestataire ne veut travailler qu'avec windows media center, il le peut déjà il utilise du WMA protégé et il dit merde aux utilisateurs d'autre systéme c'est déjà ca qu'il ce fait
Rien n'empeche de retrouver la methode de cryptage utilisée par WMA et de l'utiliser avec un OS non DRM. WMA est programme qui peut être compris par un processeur donc par un humain aussi, en y mettant le temps qu'il faut (et avec les outils qu'il faut).

Ou encore de patcher WMA pour que le controle ne soit plus efficace. Mais dans ce cas un OS DRM enverra le hash du WMA modifié, ce qui sera détecté par le fournisseur.

Lors dune vieille discussion entre nous j'avais produit des liens vers des documents d'Intel parlant clairement d'identification à distance. Documents retirés depuis.
Même IBM dans son document en faveur de TCPA/TCG reconnait que c'est possible tout en disant "oui mais c'est dur car il faudrait stocker les hashs des OS et des hardware dans une grosse base de donnée". Ce dernier argument n'est pas sérieux avec la puissance actuelle des clusters de PC bon marchés. (cf les clusters de Google).

plus il y a des gens utilisant TCG, plus il sera facile pour un prestataire distant d'exiger son activation afin de vérifier l'OS et le matériel du client distant.

Donc il n'y a qu'en refusant au maximum cet technologie qu'on pourra lutter efficacement contre elle.

transmettre la confiance jusqu'au kernel
L'expression est mal trouvée. Il s'agit pour le code exécuté avant l'OS, de stocker un hash de cet OS dans la puce TCG. De façon à ce que si un prestataire de services exterieur nous demande de vérifier notre OS, on puisse lui envoyer le hash de l'OS signé par la puce TCG, prouvant ainsi que l'OS n'a pas été modifié.

J'appelerais plutot ça une chaine de mouchards qu'une chaine de confiance.