free2.org a écrit 2367 commentaires

http://qa.debian.org/ c'est le "quality assurance". tu pourras y trouver quelques infos ,notamment, sur les paquets ayant des gros RC bugs non corrigés y'a plus qu'à soustraire ces mauvais mainteneurs du nombre total... mais bon c'est pas facile et ce n'est qu'une approximation ....

en effet je crois que tout ça n'a pas été exprimé clairement, je vais essayer de simplifier:

les paquets Debian passent d'abord par le stade "experimental", ils ne font alors pas partie du FTP officiel Debian (la plupart des sources APT "experimental" sont sur les sites des mainteneurs ou dans apt-get.org).

quand le mainteneur est suffisament satisfait, il peut tenter de l'uploader dans le FTP offciel "unstable", ce qui n'est effectif qu'après un certain nombre de vérifications de la part des FTP masters

après un délai d'au moins 15 jours (ou moins de 15 jours dans certains cas) si le paquet ou ses dépendances n'introduisent pas de nouveau bug important, et si les dépendances peuvent toutes faire partie de testing, alors il peut aller dans testing.

voila pourquoi une partie très importante (la majorité ?) des utilisateurs de Debian utilisent des paquets de testing ou unstable, qu'ils trouvent plutot stables...

ajoutons que grace à la gestion automatiques des dépendances de APT, on peut mélanger sans problème des paquets de stable/testing/unstable comme je l'explique sur ma page http://free2.org/d/(...)

on peut lire sur leur site que l'association sourcemage utilise un contrat social copié sur celui de Debian une question me vient alors: pourquoi sourcemage ne soutiendrait pas aussi le développement de apt-build ( APT avec recompilation des sources et optimisations) ?

tu as aussi le paquet equivs qui te permet d'installer des dépendances fictives sinon tu peux aussi installer des paquets de unstable ou utiliser apt-build http://free2.org/d/

à supposer que le fonds géré par l'ONU soit non corrompu (c'est pas évident, comme pour toutes les histoires d'argent), ce serait une meilleure solution qu'un gouvernement financé et armé par les US (solution la plus probable malheureusement, et de nombreux gouvernements sont deja dans cette situation...)

je pense que cela s'applique surtout à des brevets couvrant du code distribué avec du code GPL notons aussi qu'en Europe le problème ne se pose pas puisque les brevets logiciels sont interdits, à nous de faire pression pour que ça continue... ce qui n'empeche pas aussi de faire pression sur le W3C pour que ses normes soient toujours utilisables sans AUCUNE restriction (ce qui semble la moindre des choses pour un standard d'intéret général)

la clause 7 s'adresse à une personne particulière: "you" Donc si tu es dans un pays avec des restrictions incompatibles avec la GPL, alors tu n'as pas le droit de redistribuer du code GPL soumis à ces restrictions. De + tu as aussi la clause 8: 8. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

quand à la GPL: http://www.gnu.org/licenses/gpl.txt 7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. Donc si un brevet, comme autorisé par le W3C, empeche de modifier le programme de la façon dont on veux, ce qui contredit la GPL, alors je n'ai pas le droit de distribuer un tel programme contenant du code protégé par la GPL et dont je n'ai pas le copyright.

Si tu te places du point de vue des détenteurs de brevets, tu as parfaitement raison. Ce n'est pas du tout mon point de vue, en tant que programmeur et utlisateur de logiciels libres.

voici des points que je trouve litigieux issus de la dernière version:
http://www.w3.org/TR/2003/WD-patent-policy-20030319/(...)
W3C Royalty-Free (RF) Licensing Requirements:

"3. may be limited to implementations of the Recommendation, and to what is required by the Recommendation"
cette restriction n'est pas compatible avec l'esprit du libre (droit à modifier autant qu'on veut), ni avec les clauses de la GPL

7. "may include reasonable, customary terms relating to operation or maintenance of the license relationship such as the following: choice of law and dispute resolution;"
le breveteur peut donc choisir, entre autres, la juridiction qui jugera les litiges avec les utilisateurs. Il peut donc choisir un pays ou une organisation qui donne beaucoup de pouvoir aux détenteurs de brevets et de copyrights.
(ce type de clause a déjà été refusé par la FSF)

tu peux faire un coller des messages d'erreur STP ? pour l'instant je pense plutot à un probleme de xauth ...

précisons que en local les commandes passent par une socket UNIX moins gourmande qu'une socket IP, et que les graphismes passent par des segments de shared memory (donc pas de recopie inutile comme dans une socket)

Il ne faut pas tout mélanger. On parle ici de versions alpha ou beta. Il y a depuis des années des versions stables de Mozilla et Galeon qui fonctionnent très bien (rapidité et aucun crash sur le pentium 200 de ma copine avec 48 megas de ram, windows ne peut pas en dire autant...).

Quand à la difficulté des librairies, il y a des gestionnaires automatiques de librairies pour cela:
apt-get pour Debian dont je suis très content depuis des années: tout est automatique y compris le téléchargement et l'installation des librairies dont on a besoin. Windows devrait s'en inspirer pour gérer ses DLLs !

je connais deja la liste http://www.m-tech.ab.ca/linux-biz/(...)

quelqu'un connait-il une liste plus exhaustive et mise à jour ?
(de mémoire il me semble que des boites comme Auchan et FranceTelecom utilisent deja massivement Linux)

voir mes autres réponses sur l'identification de l'OS loader par le BIOS qui est obligatoire dans TCPA, et un hash doit etre stocké dans le PCR.

tiens au fait il y a une faille (une de +) dans ton histoire de BACKUP:
pourquoi utiliser 2 TPM si il est vrai que le blob de backup est crypté par une clé que l'on fournit ? Pas besoin de 2e TPM pour décrypter des algos standards comme RSA.

Je crois plutot que la clé DOIT etre authentifiable comme provenant d'un autre TPM.
Seul cet autre TPM pourra utiliser le blob de backup. Et il aura tout loisir de bloquer l'accès aux clés en utilisant le meme PCR. Tou ça n'étant possible que si le BIOS coopère avec luitilsiateur, alors que les spesc TCPA prévoient plutot que le BIOS coopère avec les applications DRM !

http://www.google.fr/search?q=cache:www.trustedcomputing.org/docs/1(...)
Cryptographic
hashing is employed to extend trust
from the BIOS to other areas of the
platform, in the following simplified
sequence:
1. The PC is turned-on.
2. The TCPA-compliant "BIOS Boot
Block" and TPM have a "conversa-
tion."This attests that the BIOS can
be trusted.
3. BIOS queries to ensure that user is
authorized to use the platform.
4. The BIOS then has a "conversa-
tion" with the operating system
(OS) loader and the TPM. This
attests that the OS loader can be
trusted.
---------------------------------------------
1.2.5 Initial Program Loader (IPL)
Start of informative comment:
This is the code that executes during the Post-Boot state. The purpose of this code is to load the
Post-Boot environment.
End of informative comment
page 9 du pdf PC
-------------------------
http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v(...)
Entities to be Measured:
· Each IPL that is attempted and executed.
page 20 du pdf
---------------------------
2.1.2 Transferring Control
Prior to transferring control an executing entity MUST measure the entity to which it will transfer
control.
pdf PC
------------
page 24 PC
In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code. The BIOS MUST not hash any data areas.

---------------------------------------------------

Proverbe: "Il n'est pire aveugle que celui qui ne veut pas voir..."

http://www.google.fr/search?q=cache:www.trustedcomputing.org/docs/1(...)
Cryptographic
hashing is employed to extend trust
from the BIOS to other areas of the
platform, in the following simplified
sequence:
1. The PC is turned-on.
2. The TCPA-compliant "BIOS Boot
Block" and TPM have a "conversa-
tion."This attests that the BIOS can
be trusted.
3. BIOS queries to ensure that user is
authorized to use the platform.
4. The BIOS then has a "conversa-
tion" with the operating system
(OS) loader and the TPM. This
attests that the OS loader can be
trusted.
---------------------------------------------
1.2.5 Initial Program Loader (IPL)
Start of informative comment:
This is the code that executes during the Post-Boot state. The purpose of this code is to load the
Post-Boot environment.
End of informative comment
page 9 du pdf PC
-------------------------
http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v(...)
Entities to be Measured:
· Each IPL that is attempted and executed.
page 20 du pdf
---------------------------
2.1.2 Transferring Control
Prior to transferring control an executing entity MUST measure the entity to which it will transfer
control.
pdf PC
------------
page 24 PC
In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code. The BIOS MUST not hash any data areas.

---------------------------------------------------

correctif: TCPA prévoit que le BIOS fasse un digest de l'OS. il n'y a donc rien à ajouter à TCPA pour faire du DRM !

désolé, mais c'est la norm TCPA qui prévoit que les BIOS devront réaliser un digest de l'OS loader

par conséquent c'est al norme TCPA qui va obliger les BIOS à devenir des outils de DRM !

tu conviendras qu'il n'y a quasiment rien à ajouter dans un BIOS pour que TCPA sopit un puissant outil de DRM: le danger est donc bien réel !

j'ai fait une page qui explique un peu comment gérer stable/testing/unstable http://free2.org/d/

j'ajoute un lien vers la page de Ross sur le site de son Université: elle montre bien l'étendue de ses recherches en matière de sacurité ainsi que son engagement pour le Libre: qui d'entre nous peut en dire autant ? http://www.cl.cam.ac.uk/~rja14/

reste à prendre en compte que:
- les clés de cryptage seront différentes sur chaque machine: les rendre publique ne servira à rien
- tout le monde n'aura pas 2 TPM pour faire des manipes
- les connexions permanentes à Internet couplées avec le mécansime d'idnetification d'OS à distance suffisent à ce que les clés de crypto ne soient pas stockées du tout dans ton ordinateur: elles sont envoyées à chaque fois par internet par le fournisseur de contenu (elles-meme cryptées par des clés jetables)

- un BIOS vicieux pourrait faire ceci: détection d' un OS loader encrypté de MS. Décryptage à la volé de cet OS loader qui contient de clés de cryptage seules connues de MS. Utilistion de ces clés en conjonction avec les informations de boot TCPA garantissant que le premier OS booté est bien un OS MS, pour crypter des fichiers en ayant la certitude qu'ils ne seront pas lisibles par un autre OS.

On ne se compred pas bien.
Le BIOS a la possibilité de stocker dans le TPM des informations concernant l'OS loader à qui il donnera la main. Mais le contenu de ces informations est laissé à la discrétion du BIOS ! Donc le BIOS peut tout a fait faire un digest RSA du petit excutable que constutue l'OS loader. Si l'OS loader de MS est bien fait, il aura toujours la meme signature quelque soit la version de l'OS MS qu'il boote ensuite.
D'où la possibilité ensuite pour un fournisseur de contenu distant de savoir si on utiliser Windows ou non.

dans cet environement la on ne peut pas accuser TCPA
la différence est que une fois booté, l'OS certifié pourra utiliser TCPA pour s'assurer de la signature du BIOS, pour s'assurer de la signature de l'OS loder, etc...
Les fournisseurs de contenu distants pourront faire de meme !