Tu dis qu'il n'y a pas de rapport ensuite tu dis qu'il y en a un...
C'est dans el sens ou la puce TPM, bien qu'utilisé par Lagrande n'apporte rien du tout à la méccanique des systèmes de canaux cryptés. (A la limite ils apporteraient plutot une faille, vu que les clefs TPM challengeables sont exportables et qu'on pourrait peut-être "écouter le contenu d'un canal avec une autre puce TPM branchée en parallèle").
Tout le méccanisme de protection (ségementation hardware, test actifs, isolation, bloquages etc.) sont fait par du hardware dédié.
Et donc je veux etre sur que mes cles soient bien en secu c'est legitime non?
Pour tes clefs privées tu as le choix entre deux options : En clair sur ton ordinateur (même si c'est pour des temps très bref) ou enfermés dans uen puce coffre fort dans laquelle elle est née et d'ou elle ne peut théoriquement (et c'est pour la certitude qu'il faudrait le VHDL nous sommes d'accord) pas sortir sauf intervention lourde nécessitant une présence physique sur la machine.
L'existence d'une backdoor permettant la récupération de l'ensemble des clefs contenues dans une puce (et à distance de préférence) ets une pure hypothèse (même si on a déjà vu les américains forcer els constructeurs à ce genre de choses). Ceci étant comparé à "en clair sur le disque dur" (ou la clef USB) je ne peux m'empécher de penser qu'il y a un progrès.
Ne pas confondre la norme TCPA/TPM et els éventuelles implémentations.
En ce qui concerne la norme, on a un degré de sécurité difficilement égalable. La clef privée étant inaccessible et ne pouvant être déplacée que par des manoeuvres longues et complexes et seulement à destination d'un autre TPM.
Les contenus "sesnibles" sont protégéspar non accès extérieur. Pour lire uen clef directement, il faut ouvrir la puce et venir ce brancher sur les bus interne. C'est nettement plus compelxe que de percer un coffre fort.
Chaque "coffre" à clef (PCR) fait des mesures de huits points de matériels et du pré-boot pour générer la clef d'authentification. Même si la qualité de l'algo est faible, une suite de MD5 octuple imbriqués reste très difficile à casser. Donc même si la clef elle même est généré par un aléa douteux, la falsification d'une puce rsique d'être très complexe.
mais bon une puce qui sert de base a des techniques liberticides je ne lui accorde pas le benefice du doute .
C'ets justement le truc. La puce TPM ne sert absolument pas de base aux techniques liberticides. Seulement comme il est assez difficile de vendre un produit qui n'a d'autre utilité que de fliquer son utilisateur, on rajoute la puce à coté pour faire un bundle "attractif".
Il n'y a aucun rapport entre la puce TPM et (par exemple) les canaux sécurisés de La Grande. Le fait que La Grande utilise la puce TPM pour stoquer ses clefs est un plus, mais absolument pas une nécessité. Si un site web décide de stoquer ses clefs dans la puce TPM ca ne ferait pas de la puce un tueur d'internet non plus.
Je suis en train d'écrire un article.
En ce qui cocnerne les dépèches argumentés, les posts complets, les arguments contrés et les longs threads (notamment contre free2) j'ai très largement fait mon boulot.
Seulement je suis d'accord qu'il faut un article clair et simple. Mais c'est très long à faire. je susi dessus depuis deux mois, j'avance bien même si j'ai beaucoup de mal à obtenir les informations (sur La Grande notamment) sans signer de NDA.
Le gros problème est que l'amalgame TCPA/La Grande/Trusted Computing entretien l'illusion que l'on ne eput avoir l'un sans les autres, ce qui est faux. On peut avoir une puce de sécurisation sous le controle total de l'utilisateur sans se frapper toute la clique de matériel espion et limitatif.
TPM n'est pas dangereux (dans les normes 1.0, 1.1, 1.2 et 2.0). Il est inutilisable pour la tracabilité, les drm ou le blocage machine.
La Grande (La surcouche d'Intel) c'est nettement moins sur. Et si La Grande est dangereux, l'implémentation du Trusted Computing complet par Microsoft a de bonnes chances d'être une horreur.
Mais la puce TPM est une belle invention, partique, utile, sure et fiable.
Ce n'est pas tellement le coté "victoire du libre" que je voulais mettre en avant, mais la capacité à contourner les brevets qu'a le monde informatique.
Cette capacité fait qu'un groupe restreint qui essaye d'imposer le paiement de royalities pour son brevet se retrouve souvent le bec dans l'eau, même si il partait avec une avance considérable. L'exemple du MP3 est criant, conçu en trois versions (VoIP, Standard, Pro) le MP3 était seul sur le marché, universellement reconnu et très répandu. Aujourd'hui il n'en reste plus rien qu'une utilisation limité aux "jouets" et fort peu lucrative.
La baisse reccord de l'utilisation des algorithmes de type LZW (même si ils repassent dans le public). La mort idiote de rambus (qui avait déposé des brevets sur la SDRam, dans le dos du consortium).
Le monde informatique a une capacité assez forte à trouver une autre solution dès qu'on lui ferme la porte au nez.
Certes en cas de lutte contre tout un consortium la situation peut être différente. Mais génèralement les consortium ne se protègent pas à coup de brevets mais à coup de dispositifs anti-copies etd e lois qui en interdise le contournement. (probablement parcequ'ils ont compris depuis longtemps que le rôle des brevets avait été complètement perverti)
Tout celà pour dire que la bonne solution pour faire disparaitre les brevets ne consiste pas à avoir des brevets soit même mais à chercher des solutions qui ne sont pas couvertes par le brevet. Ca ne demande pas beaucoup plus d'énergie, c'est innarétable, et ça met mieux en exergue la futilité des brevets logiciels.
Comme disent les mongueurs : There Is More Than One Way To Do It
ce qui fait la force du logiciel libre, c'ets justement qu'il échappe a toutes les pressiosn auquelles sont contraintes normalement une entreprise classique. Les grosses entreprises aimeraient faire glisser l'Opensource vers le commercial (que ce soit de la part des boites qui agressent, comme des boites qui soutiennent), parceque c'est plus rassurant d'abord, et parceque c'est plus facile à controler aussi.
Mais l'opensource tire très bine son épingle du jeu avec une stratégie "run and hit" qui a porté ses fruits à plusieurs reprise.
Les procès aus ujet des brevets sont très rare, le brevet "mal justifié" étant par esence une arme à double tranchant. Si vous poussez au procès, vous pouvez tout aussi bien voir un concurrent génant disparaitre que de voir votre brevet invalidé. C'est quite ou double. Et pue de compagnies on réellement envie de prendre se risque, surtout si au final il n'y a rien à gagner.
Si vous vous attaquez à un projet OpenSource qui a du succès et qui vous fait de l'ombre, vous prenez nons eulement le risque de voir vos brevet invalidés, mais aussi le risque de voir deux autres projets sur le même thème apparaitre immédiatement. Les royalties sur le gif ont engendrées une foule de formats graphique tous meilleurs que le gif, aussi bien pour l'imaegrie web que pour le stockage de masse de doccuments noir et blanc. Et bien sur tous libres. Dès que Frauhenauffer a commencé à exiger des sommes indues pour les licenses MP3, il s'est retrouvé à devoir combattre un plétore de formats, certains libre, d'autres non qui ont fini par le balayer (le mp3 ne sert guère plus qu'au baladeurs numériques, et encore de moins en moins. Echec total en ce qui concerne la voix sur IP, les formats vidéos multipistes etc.)
Aller au clash (au sens ne pas obéir au injonctions d'une société et pousser jusqu'au tribunal) sans l'appui d'une grosse boite commerciale c'est quasiment perdre la bataille. Alors que fermer un projet et attendre qu'il soit repris est quasiment imparable. A partir du moment ou de l'argent est en jeu, il faut absolument être sur de son coup. Intenter 40 procès d'affiler à un projet n'effraie pas du tout les grosses boites (j'en ai révé, sony l'a fait !). Qu'il gagnent ou perdent le procès n'a pas grande importance à leur yeux. Du moment que leur équipe continue à programmer tandis que les devs Opensource sont à la barre en train de témoigner et que les éventuels supports commerciaux fondent comme de la neige au soleil.
L'opensource est à l'heure actuelle dans une bulle de protection. Juridiquement, socialement et ecconomiquement personen ne sait trop quoi faire de ce "truc" qu'est l'opensource. Et cette méconnaissance de l'opensource est uen des meilleures armes dont nous disposions. Si on commence à jouer avec les règles de l'équipe d'en face on risque de prendre une pilée. Tout d'abord parceque ca poussera la communeauté à la schyzophrénie grave (se défendre avec des brevets dont on clame haut et fort qu'ils n'ont aucune valeur) et ensuite parceque l'on a pas de bras de levier pour porcéder à un échange d'IP. Comment respecter la GPL et reconnaitre que l'on utilise un brevet est propiétaire ?
Normalement dans le réglement de litiges à "l'amiable" entre deux sociétés qui font du proprio sur les brevets l'accord est simple : 50 -50. Tu ne me casse pas les pieds, tu gardes mon secret au chaud, tu continues ton business dans ton coin et moi pareil. En échange de quoi on oublie cette histoire de brevets.
Mais entre l'Opensource et une société c'est très différent. On demande à la société d'en face de reconnaitre que son brevet est librement diffusable, utilisable à volonté dans toutes les applications imaginables et ce par l'ensemble de l'univers en échange de quoi on ne donne rien vu que l'on considère qu'à partir du moment ou un projet est en GPL, en BSD ou en MIT c'est forcément que l'ensemble des algos sont librement utilisables (Sinon il y a uen grave atteinte des droits de l'utilisateur qui brise la license de facto).
Bref on s'arme pour une guerre que l'on en peut pas perdre sauf si on s'arme.
a) le monde - Depuis le temps que l'opensource doit revolutionnariser nos vies, il serait temps qu'il se reveille
b) de slip - une string en UTF8 ca serait bien
c) de CAP - Je conseille l'ébénisterie sur contreplaqué, ca ouvre des BTS assez demandés
d) l'huile du reservoir, et revoir la pression des pneus. Ca serait dommage un accident de routage lors du départ en vacances
e) tous ses ¤uros contre des Yuans, il me remerciera plus tard quand il aura fait une plus value de folie sans bouger le petit doigt
f) d'air. Le sondage de linuxfR ca en jette quand même plus non ?
g) de disque. Car comme le disait hier encore Pierre Tramo à la réincarnation en moule de Charles Bronson : Moi je met toutes mes données en Raid 0, c'est plus sur.
Le principal inconviennient à tare les bzip2 est que chaque fichier bzippé va avoir son propre dictionnaire, alors que parfois de grosse ecconomies peuvent êtres faites sur un lot de fichiers similaires (typiquement des logs). Bref on va impacter sérieusement les performances de compression.
La bonne façon de faire est de concatener les fichiers et les compresser en même temps. On obtient ainsi un seul dictionnaire pour la compression et donc de bien meilleure taux. Ensuite il suffit de prendre le catalogue du concateneur et de chercher l'index de début du fichier qui nous interresse.
Ce qui se passait à l'époque sur ton Mac, ton Atari ou ton Amiga estd u au fait que els palteformes étaient subtilemetn différentes. La mémoire pas exactement semblable, le controleur pas tout à fait du même modèle etc.
Pour empécher d'installer un OS sur une plateforme, c'ets très simple. Il suffit de mettre n'importe ou sur la carte mère une puce dédiée, de préférence un DSP (parceque c'est très dur à émuler), dans une version modifiée introuvable dans le commerce (Par exemple on peut mettre un altivec). Ensuite il suffit de faire des appels à cet altivec un peut partout dans le code.
Résultat : Sur une carte mère qui n'a pas la dite puce, l'installation est plombée d'office, et el petit malin qui arriverait à émuler la puce aurait des perfs assez violamment impactée.
Ca marche redoutablement bien, coute nettement moins cher que d'appeler tout une archi sécurisée à la rescousse et beaucoup plus flexible (pas besoin de se conformer aux standards de totu un consortium)
En ne livrant qu'une version cryptée de MacOS (ou d'une partie vitale du système), dont la clé de décryptage se trouve dans la puce.
Pour celà il faudrait
a) Que la clef soit préchargée dans le TPM (ce qui est interdit par la norme).
b) Que l'utilisateur n'ait pas les droits owner sur la clef. Ce qui implique qu'il n'est pas owner du TPM (donc il ne pourra jamais rajouter ou changer des profils ou des clefs) et qu'il ne peut pas le devenir (ce qui est interdit par la norme.)
c) Un retour en usine (ou dans les mains de quelqu'un connaissant le mot de passe owner) à la moindre mise à jour du bios ou de tout autre périphérique compris dans le PCR (hash du boot) qui protège la clef. Un PCR contient 8 informations préboot faites d'offices au niveau de la ram, de la tension d'alim, du bios, de la carte mère et des différents bus. Le nombre de techniciens connaissant le "secret" du owner serait alors obligatoirement très élévé. Autant dire que le mot de passe owner des Mac x86 serait sur internet en 18 secondes.
En bref, on aurait un TPM qui casse la norme dans tous les sens, qui serait innutilisable en temps que coffre à clef pour l'utilisateur et qui en plus multiplierait par 10 le cout du SAV tout en apportant un gain de sécurité totalement illusoire vis à vis des petits malins....
La puce TPM est parfaitement supportée sous Linux, elle est même désormais supportée en natif.
Pour l'instant l'intégration avec les logiciels est très faible, mais elle peut déjà remplir certaines fonctions comme l'identication par uen autre machien TCPA sur le réseau.
Si tu parles anglais, je ne saurais que trop te recommander la lecture de cet article http://www.linuxjournal.com/article/6633(...)
Ne te laisse pas impressionner par le code en C. La programmation de la puce est assez simple.
Pour être tout à fait franc avec toi, je me demande depusi le début si la migration d'Apple vers l'archi x86 n'est pas en partie due à une volonté de profiter du système La Grande d'Intel.
Officiellement La Grande est uen surcouche de TPM (donc passif) avec un mode de séquentialisation des zones bus mémoires (Protégé/pas protégé) et une sécurisation du clavier et de l'écran (Via un système de canal sécurisé). La Grande met très en avant son coté OPT-IN (comme la puce TPM) à savori que toutes les fonctions sont désactivées par défauts jusqu'à ce que vous les activiez explicitement.
Cependant certains passage de leur doc laisse penser que non seulement le logiciel peut intérroger le matériel (ce dont on se fout royalement - il est techniquement impossibel de bloque un PC avec çà) mais aussi que le matériel peut interroger le logiciel (Et là par contre danger, parcequ'un périph capable de faire une requète sur les logiciels qui tourne est aussi capable de se bloquer si il aime pas la réponse renvoyée)
Si on ajoute celà au fait que les canaux sécurisés sont prédéfinis et non pas calculés en focntion de la machine, on obtient assez facilement un écran qui refuse de monter en résolution ou en fréquence si il n'aime pas la signature du boot. Bien sur on peut transposer çà un disque dur ou une carte réseau et tout de suite ca fait froid dans le dos.
J'ai posé la question à Intel, mais je n'ai pas eu de réponse. D'ailleurs si un techos Intel me lit, qu'il n'hésite pas à prendre contact, je susi preneur de toute info qui n'est pas "Yellow Paper"
Mais juste pour rappel : la puce TPM est une puce passive, elle ne permet pas de bloquer quoi que ce soit.
C'est ensuite par dessus que l'on peut éventuellement rajouter du matériel qui fait le blocage.
La puce TPM ne sait faire qu'une seule chose : répondre à un challenge venant de l'extérieur.
En moyenne 3 200 crimes et 420 000 délits dont les deux tiers sont liés au comportement sur routes, et un taux de réponse de 70%.
Les chiffres sont en baisse constante depuis 1998. (Soit 7 ans sur les 10 que tu cites...)
Sur les 11 000 000 de décisions pénales annuelles, 10 000 concernent des amendes forfaitaires majorées.
En justice civile (ie soiciétés) on a 2 milions de décisions prises chaque années, aucune ne donnan lieu à une condamnation pénale bien entendu.
Donc
a) On a jamais eu en France 26 000 000 de crimes et délits (je crois pas qu'on ait jamais officiellement atteind les 500 000)
b) En pénale on a 5 000 000 d'affaires par an, dont 1 350 000 sont poursuivables (ie on connait assez bien les faits pour donner suite, et les faits valent la peine de se pencher sur le cas).
Sur ces 1 350 000, on a 650 000 qui concernent des contraventions et 900 000 qui sont traités à l'amiables ou dans des tribunaux non pénaux (N.B : une affaire peut concerner une contravention ET être réglée à l'amiable).
reste entre 390 000 et 430 000 condamnations par an pour les crimes et délits.
Donc pour résumer, il y a en France 52 fois moins de crimes et délits que tu ne le dis et 13 fois plus de condamnations. (Et je tiens compte des crimes et délits liés au comportement, qui représentent les deux tiers des condamnations).
Bref tu te trompes dans un rapport de 1 à 676. Réjouis toi ! La situation est 676 fois moins grave que tu ne le penses.
J'ignore complètement qui te pourris la tête comme çà, mais la prochaine qu'il te sort de grande théorie appuyées sur des chiffres éloquants, prend des notes et vérifie par toi même. Tu vas tomber de haut...
D'habitude, j'aime pas les réponses toutes faites, mais là on va faire une exception :
Article premier
Tous les êtres humains naissent libres et égaux en dignité et en droits. Ils sont doués de raison et de conscience et doivent agir les uns envers les autres dans un esprit de fraternité.
Article 2
1.Chacun peut se prévaloir de tous les droits et de toutes les libertés proclamés dans la présente Déclaration, sans distinction aucune, notamment de race, de couleur, de sexe, de langue, de religion, d'opinion politique ou de toute autre opinion, d'origine nationale ou sociale, de fortune, de naissance ou de toute autre situation.
2.De plus, il ne sera fait aucune distinction fondée sur le statut politique, juridique ou international du pays ou du territoire dont une personne est ressortissante, que ce pays ou territoire soit indépendant, sous tutelle, non autonome ou soumis à une limitation quelconque de souveraineté.
Article 3
Tout individu a droit à la vie, à la liberté et à la sûreté de sa personne.
Article 5
Nul ne sera soumis à la torture, ni à des peines ou traitements cruels, inhumains ou dégradants.
Article 6
Chacun a le droit à la reconnaissance en tous lieux de sa personnalité juridique.
Article 7
Tous sont égaux devant la loi et ont droit sans distinction à une égale protection de la loi. Tous ont droit à une protection égale contre toute discrimination qui violerait la présente Déclaration et contre toute provocation à une telle discrimination.
Article 8
Toute personne a droit à un recours effectif devant les juridictions nationales compétentes contre les actes violant les droits fondamentaux qui lui sont reconnus par la constitution ou par la loi.
Article 9
Nul ne peut être arbitrairement arrêté, détenu ou exilé.
Article 12
Nul ne sera l'objet d'immixtions arbitraires dans sa vie privée, sa famille, son domicile ou sa correspondance, ni d'atteintes à son honneur et à sa réputation. Toute personne a droit à la protection de la loi contre de telles immixtions ou de telles atteintes.
Article 13
1. Toute personne a le droit de circuler librement et de choisir sa résidence à l'intérieur d'un Etat.
2. Toute personne a le droit de quitter tout pays, y compris le sien, et de revenir dans son pays.
Article 18
Toute personne a droit à la liberté de pensée, de conscience et de religion ; ce droit implique la liberté de changer de religion ou de conviction ainsi que la liberté de manifester sa religion ou sa conviction seule ou en commun, tant en public qu'en privé, par l'enseignement, les pratiques, le culte et l'accomplissement des rites.
Article 19
Tout individu a droit à la liberté d'opinion et d'expression, ce qui implique le droit de ne pas être inquiété pour ses opinions et celui de chercher, de recevoir et de répandre, sans considérations de frontières, les informations et les idées par quelque moyen d'expression que ce soit.
Je soupçonne pour ma part très fortement ton driver AGP.
Dasn l'ordre :
l'adressage mémoire foire, l'initialisation write combining foire, le chargement du module int10 (en charge de l'AGP dans Xorg) foire. Le chargement mémoire haute (dans lequel le mode VGA standard est placé le plus souvent) foire. L'énnumérations des ressources foire.
On va pas être méchant, mais entre ton kernel et ton Xorg il y en a un des deux qui se prend violament les pieds dans le tapis quand il charge l'AGP.
Mon intuition : ta distrib croit reconnaitre un port AGP qui est presque identique au tien mais comporte quand même des différences assez nette pour ne pas être compatible. A mon avis tu as un port AGP aux normes 1,2.5,3 qui est initialisé comme un port AGP aux normes 2 par ton kernel.
Comme c'est semblable, rien de choquant en vesa ou en frame buffer console (zone mémoire basse) par contre en initialisation graphique et en chargement mémoire haute c'est la fête.
Ca marche sous windows a cause du support du mode agp 1 et du fallback PCI.
Le problème est que si j'ai raison, ca va pas être évident du tout à régler sous Mandrake.
Malheureusement je n'ai as de solutions faciles à te proposer.
Dans ton xorg.conf ajoute la ligne
ModeLine "640x480" 25.175 640 664 760 800 480 491 493 525
dans a section monitor. ca va le forcer à prendre un mode 640x480 on ne peut plus standard, des fois que le roblème vienne de ligne du moniteur assez étranges.
Il me faut laussi la référence exacte de ton moniteur et de ton epia.
On vas se farcir tous les modelines à la main et voir si le problème vient de là.
Ce qui me gène dans un régime totalitaire, par exemple islamique, c'est que je perd toute liberté. Mes conversations et mes publications sont surveillés, mes pensées contraires me valent des séjours en prison, ma femme est obligé de porter un voile et je suis obligé d'aller à la mosqué de temps en temps pour faire montre de ma bonne volonté. Je serais un eternel suspect parceque je n'ai pas la bonne couleur de peau.
Les terroristes aimeraient bien nous imposer ce mode de vie.C'est pourquoi ils frappent au hasard pour utiliser la peur comme un argument pour transformer leurs idées en lois. Je n'adhère pas et je me battrais contre si il le faut.
Pour lutter contre le terrorrisme je vais perdre toute liberté. Mes conversations et mes publications vont être surveillés, mes pensées contraires me vaudront des séjour en prison, ma femme et moi seront obligés de porter uen puce identificatrice et je ne pourrais plus aller à la mosqué de temps en temps, ce serait faire montre de mauvaise volontée. Il y aura autour de moi des eternels suspects car ils n'auront pas la bonne couleur de peau.
Les gouvernement aimeraient bien nous imposer ce mode de vie. C'est pourquoi ils légifèrent au hasard pour utiliser la peur comme un argument pour transformer les idées en lois. Je n'adhérerais pas et je me battrais contre si il le faut.
a) Le bios:
Dans le bios si les options suivantes existent :
AGP apperture : 64Mo
AGP fast write : disabled
AGP write combining : Disabled
Agp mode : au minimum (probablement 2x)
b) la config XFree
Section "Files"
# Multiple FontPath entries are allowed (they are concatenated together)
# By default, Mandrake 6.0 and later now use a font server independent of
# the X server to render fonts.
FontPath "unix/:-1"
EndSection
Section "ServerFlags"
#DontZap # disable (server abort)
#AllowMouseOpenFail # allows the server to start up even if the mouse does not work
DontZoom # disable <KP_+>/<KP_-> (resolution switching)
EndSection
Section "Module"
#Load "dbe" # Double-Buffering Extension
#Load "v4l" # Video for Linux
Load "extmod" #needed to cut DGA and for eyes candy
Load "type1"
Load "freetype"
#Load "glx"
Après avoir fait une sauvegarde de l'ancien xorg.conf et modifié ce qui était modifiable dans le bios, il faut utiliser le xorg.conf que j'ai donné tel quel.
Ensuite faire un test. Sous reserve de fautes de frappe (je suis un pro à ce jeu) ca devrait passer. (On a une config safe de chez safe qui fait passer le mode sans echec windows pour un dangereux expérimentateur).
Ensuite :
1 - réactivation du DBE, retest (enlever la première coche à la ligne #Load "dbe" ...)
2 - passage en mode vesa :
Device "fallback" devient Device "device1" dans la section Screen identifier "screen1"
3 - passage en mode 16 bits (15 bits à éviter à tout prix, gros problèmes d'alignement mémoire pour cause de hardware hors normes dans 99,9% des cas) :
DefaultColorDepth 8 devient DefaultColorDepth 16
Ah, je ne sais pas, je ne suis pas tellement leur activité
Ca ce sent
... En fait, tout ce que je sais, à ce sujet, c'est qu'on m'a dit que le code d'openssh était assez horrible
Le mec qui t'a dit ca doit pas suivre tellement leur activité non plus.
et que c'était pour ça qu'on n'en faisait pas une bibliothèque.
On dirait que tu suis pas tellement la sécurisation des clients non plus.
Cela dit, pour en revenir sur la propreté du code, celui qui suit me semble parfaitement propre, malgré son dépassement :
int i[2];
[...]
/* This is an out-by-one, but it's volunteer, and we are sure there is enough place into memory for it. */
i[2]=0;
On en pleurerait
Je préfère quand même
void* i = calloc(2*sizeof(ulong));
int* j= (int*) i;
[...]
j[1] = (int) NULL;
Parceque ca compilera jamais deux fois de la même façon sur deux archis différentes. Même les warnings GCC changent à chaque compilation.... Ce qui est encore plsu drôle c'est la liste d'insultes que sort valgrind.
Bien sur c'est un bonheur pour tous les eptits malins en mal d'attaque par buffer overflow.
Et ca devient encore plus drole quand on passe j[1] en paramêtre d'une fonction.
Par exemple, comment espères-tu faire fonctionner une carte dual GE (4 Gbit/s) et deux cartes quad GE (16 Gbit/s) dans un PC où le bus le plus rapide fait 8,5 Gbit/s ?
Les cartes quads sont des 10/100. Le tout est en PCI-64, les versions PCI-Express sont prévues. On a donc environ 8Gbit/s de bande passante 4Gbit/s pris par la GE et encore 800Mbit/s pris par la quad 100E.
Quels processeurs va-t-il falloir pour commuter tout ça en software ?
Plus que les processeurs, c'est surtout la taille des bus et la réactivité des composants qui m'inquiéte. J'ai déjà fait tourner un agrégateur 5x100E <-> 1GE en software sur un OpenBSD. Les tests en charge simulées étaient convaincants, et la charge CPU loin d'être abhérante. Mais je n'ai pas pu le déployer professionellement (projet refusé).
Ceci étant tu es el second a me faire ces remarques. Je epnse donc qu'il est bon que je me remette en cause et que j'oublie l'émulation fonctionelle de 6500 avec un grille pain jusqu'à pouvoir prouver le contraire.
J'ai beau mieux connaitre FreeBSD que Cisco, j'ai eu plus de surprise de ce genre avec FreeBSD qu'avec un Cisco
J'ai eu de très mauvaises surprises sous Cisco, notamment une migration de cartes qui a viré à la catastrophe pour cause de firmware pas assez à jour (et pourtant le techos qui nous aidait était un consultant Cisco). Le hot plug "5 minutes chrono en main" s'est transformé en iterruption de service pendant 6 heures. (La manip avait été planifiée le soir et une fois le réseau mis par terre il était pas question ni d'aller télécharger le firmware récent, ni d'aller dans le bureau d'en face pour faire la même chose).
Sauf que tout l'intérêt d'un 6500, c'est avant tout d'être un commutateur filtrant ! Si tu veux surtout comparer la partie routage/filtrage, il vaudrait mieux le comparer à un 38xx ou un 7xxx...
L'utilisation que l'on fait de la bête est chez nous la suivante : 10 points entrants, 20 poinst sortant et un point "poubelle/log". Le système nous sert principalement à checker la validité des paquest quir entrent et qui sortent et à prévenir une éventuelle tentative de déni de service massif.
Il y a aussi des relations vLan à vLan mais ce n'est pas la majorité.
Il se peut cependant que l'on ait été mal conseillé.
Manifestement tu connais nettement mieux le sujet que moi. Je vais donc mettre de coté mes idées iconoclastes jusqu'au moment ou je pourrais monter un système suffisament important pour tester moi même.
Admettons donc que ma foi en OpenBSD m'a aveuglé et/ou que je ne me rend pas complètement compte de la puissance d'un 6500.
Ce qu'il me faudrait par contre c'est un cas d'école, un cas qui utilise pleinement un 6500 (6 ou 13 vu que le 3 a l'air d'être de base un exemple dégénéré) pour que je commence à me demander comment je vais tester pour voir si l'équivalent est réalisable en OpenBSD/x86.
Question bète : comment tu relies tes serveurs entre eux en fibre tout en assurant la redondance ?
En groupe de deux seulement.
Connection directe A vers B.
A étant le redondant hardware full de B et réciproquement.
Chacun des des PCS n'utilise donc qu'un seul des deux ports Gigabits a des fins de transmissions d'états/redondance/syncro PF.
Si A se pête la gueule B prendra immédiatement le relais et il utilisera ensuite calmement le réseau "standard" (ie un des ports 10/100) via carp pour recréer la redondance.
Si A et B se pêtent la gueule, carp sera obligé de faire le boulot tout seul via le réseau 100. Et là on se bouffer de la latence (surtout en forte charge) le temps que Carp remonte 2 interfaces virtuelles, les sync et les synchronise.
Pour le reste, tu parles bien de 80 ports 10/100/1000 comme les ports du 6500 que tu veux égaler, non ?
Malheureusement pas, je susi toujorus dans le bas de gamme avec la carte 48 ports 10/100 + 4 en 1000. J'ignorais qu'il existait une carte 48 ports en 1000 chez Cisco (et je vois pas bien l'interet avec un bus de 8gb/s par carte), déjà avec la 48x100 + 4x1000 on touche aux limites en forte charge.
Non.
Parce qu'en ce qui concerne la fiabilité du point de vue du port, elle reste égale à celle du compposant le moins fiable entre la carte quad, la carte mère et la carte fibre... redondance ou pas. Et chacun de ces éléments est autrement moins fiable que les cartes 48 ports cisco ou autre.
Idéalement tous mes ports sont full redundant.
Si on est dans le cas 48 ports, j'ai donc au maximum 24 points sur mon cisco (2x24 pour pallier à un débrassage à la con). Sur mon armoire je peux faire du 3x24 (2x24 en redondance directe via le cable en 1000 et encore 24 en fallback via carp). On arrive à 72 ports de pris.
Supposons que la probabilité qu'un des ports Cisco tombe en panne sur une période donnée soit de une sur un million. En supposant que les cables ait été bien placé et que Cisco fasse bien son boulot on peut considérer que la probabilité que le port de backup tombe en panne aussi n'est pas lié a la probabilité de panne du premeir port .
Donc P(Port1KO) et P(Port1bisKO) = P(Port1KO) x P(Port1bisKO)
Soit une chance sur mille milliards.
Maintenant si la probabilité pour qu'un port ethernet PC tombe en panne sur la même durée est de une sur 10 000 (donc cent fois moins fiable que Cisco). Avec le même calcul on a
P(Port2aKO) et P(Port2bKO) et P(Port2cKO) = (10 000)^3
Soit une chance sur mille milliards.
Ici on voit qu'avec uen triple redondance sur du hardware classique on peut battre une double redondance sur du hardware très haut de gamme. (Par contre au niveau cout de maintenance, on se fait un poil matraquer, vu qu'on risque d'avoir fréquamment à changer une carte ou l'autre.)
Or le 6503 fait 4U, donc plus de 10 fois moins que ta solution.
Mea culpa again. Je pensais que c'était 4U hors support des cartes. Soit en fait une taille de chassis de 7U environ. J'ai dit ca de bonne foi. Ici on a un 6506 et le bloc double alim à lui tout seul doit déjà faire 3U.
950W pour un 6503 sans PoE (suite de ton message), contre 300 à 400W par 20 machines, ça fait quand même un facteur 5 ou 6, c'est une GROSSE différence !!!
950 Watts seulement ? Je pensais que c'était beaucoup plus. Mea culpa. Ceci étant un serveur diskless/videoless sous openBSD a tendance à ne pas consommer beaucoup plus de 150watts en pointe et pas beaucoup plus de 50 watts en moyenne (a moins que le système ne soit utiliser comme commutateur de diffusion, mais alors il faut se reporter à ce que j'ai dit sur les commuts purs).
On va donc consommer entre 20x50 et 20x150 watts. Soit entre 1000 et 3000 watts.
Installation d'un 6500 : 0 minutes chrono (ben oui, c'est déjà installé)
Ca c'est la théorie, en pratique la config des cartes les upgrades de firmwares et le formatage des flashs peuvent réserver des surprises
Pour les trucs vraiment tordu, les règles sont plus simple sur pf, mais pour les règles de base, c'est aussi simple sous IOS lorsque l'on a l'habitude.
Ca vient de moi alors. Je dois manquer d'entrainement sous IOS, mais autant les règles de routages passent bien, autant je trouve que les règles de filtrage sont horribles.
Et accessoirement, si l'on prends une carte firewall, la différence de pris entre le chassis nu du 6503 et du 6506 est accessoire, on évitera donc de se retrouver trop court dès la mise en service en faisant des économies de bout de chandelles à coté...
HOULA ! Stop. OpenBSD peut arriver Un 6500 dans une optique routeur/firewall/switch. Plus on s'oriente vers un switch (et à plus forte raison vers un commut spécialisé), plus il va avoir du mal. C'est clair que si on retire l'étage firewall OpenBSD va avoir du mal.
Vu les problèmes de latences, j'y crois moyen à l'agrégation de lien entre 2 prises sur 2 PCs différents...
Je en vois pas en quoi celà va créer des latences. Tu tappes un ordinateur ou l'autre suivant le cas. C'est carp qui décide de l'interface active et c'ets donc vers celle là que tu tournes, exactement comem si tu étais en accès direct. A 60% (ou autre) de charge tu fait un sync "faible" via PFsync (si besoin) et tu changes l'interface. Niveau latence ca va être très très faible : un PFSync de temps en temps en surcharge.
Bref, soit tu te voiles volontairement la face pour ne pas voir les limimtations de ta solution, soit tu es d'une mauvaise foi à toute épreuve.
Disons surtout que pour essayer de pas trop partir en troll j'ai essayé de démontrer qeu l'on pouvait faire aussi bien que Cisco en utilisant les architectures réseaux type Cisco.
OpenBSD brille nettement plus dans des architecture éclatés, type Vauban que dans une topologie en étoile à forte centralisation. Mais là, les comparaisons déjà délicates seraient devenus impossibles.
Pour ce qui est de la mauvaise fois à toute épreuve il est clair que la comparaison se veut un poil provocatrice, néamoins honnêtement à ton avis peut-on ou ne peut-on pas remplacer un 6503+Superviseur+Firewall+48 Ports 10/100 par une grappe OpenBSD ayant un TCO inférieur ou égal et un degré de fiabilité comparable ?
Je pense très sincèrement que oui (et ce à peu près dans tous les cas).
Pour les modèle plus évolués c'est à étudier au cas par cas, notamment au niveau des besoins en commutation par rapport aux besoins en filtrage.
Mais OpenBSD est livré avec tout un tas de doccumentation, et là il va falloir la lire.
Premièrement tu dis que ton apache est chrooté, j'en déduis que pf, snort, snort2c et mons2c sont dans les chroot avec lui non ?
Existe-t-il un autre pf qui tourne en non chrooté ? Sur la même interface ? Mêmes questions pour snort ?
Deuxièmement sudo c'est mal. On a maintenant des ACL sous linux et sous BSD. Sudo devrait donc disparaitre. Garde le owner de pf/snort etc. à root, créé un groupe "netsecure" et fait un chwon de netsecure sur les programmes dont tu as besoins (de préférence avec des droits limités genre juste en execution quand c'est possible). Enuite lance ton programme en php si tu veux.
La solution du parano consisterait plutot à dire que php est un nid à bug et à failles de sécurité (c'est pas tout à fait vrai ). Dans ce cas là la solution est de faire un check de sécurité du repertoire de chroot via tripewire qui si il est valide lance la commande.
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 1.
C'est dans el sens ou la puce TPM, bien qu'utilisé par Lagrande n'apporte rien du tout à la méccanique des systèmes de canaux cryptés. (A la limite ils apporteraient plutot une faille, vu que les clefs TPM challengeables sont exportables et qu'on pourrait peut-être "écouter le contenu d'un canal avec une autre puce TPM branchée en parallèle").
Tout le méccanisme de protection (ségementation hardware, test actifs, isolation, bloquages etc.) sont fait par du hardware dédié.
Et donc je veux etre sur que mes cles soient bien en secu c'est legitime non?
Pour tes clefs privées tu as le choix entre deux options : En clair sur ton ordinateur (même si c'est pour des temps très bref) ou enfermés dans uen puce coffre fort dans laquelle elle est née et d'ou elle ne peut théoriquement (et c'est pour la certitude qu'il faudrait le VHDL nous sommes d'accord) pas sortir sauf intervention lourde nécessitant une présence physique sur la machine.
L'existence d'une backdoor permettant la récupération de l'ensemble des clefs contenues dans une puce (et à distance de préférence) ets une pure hypothèse (même si on a déjà vu les américains forcer els constructeurs à ce genre de choses). Ceci étant comparé à "en clair sur le disque dur" (ou la clef USB) je ne peux m'empécher de penser qu'il y a un progrès.
[^] # Re: On va se répéter une dernière fois
Posté par Jerome Herman . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 4.
En ce qui concerne la norme, on a un degré de sécurité difficilement égalable. La clef privée étant inaccessible et ne pouvant être déplacée que par des manoeuvres longues et complexes et seulement à destination d'un autre TPM.
Les contenus "sesnibles" sont protégéspar non accès extérieur. Pour lire uen clef directement, il faut ouvrir la puce et venir ce brancher sur les bus interne. C'est nettement plus compelxe que de percer un coffre fort.
Chaque "coffre" à clef (PCR) fait des mesures de huits points de matériels et du pré-boot pour générer la clef d'authentification. Même si la qualité de l'algo est faible, une suite de MD5 octuple imbriqués reste très difficile à casser. Donc même si la clef elle même est généré par un aléa douteux, la falsification d'une puce rsique d'être très complexe.
mais bon une puce qui sert de base a des techniques liberticides je ne lui accorde pas le benefice du doute .
C'ets justement le truc. La puce TPM ne sert absolument pas de base aux techniques liberticides. Seulement comme il est assez difficile de vendre un produit qui n'a d'autre utilité que de fliquer son utilisateur, on rajoute la puce à coté pour faire un bundle "attractif".
Il n'y a aucun rapport entre la puce TPM et (par exemple) les canaux sécurisés de La Grande. Le fait que La Grande utilise la puce TPM pour stoquer ses clefs est un plus, mais absolument pas une nécessité. Si un site web décide de stoquer ses clefs dans la puce TPM ca ne ferait pas de la puce un tueur d'internet non plus.
[^] # Re: On va se répéter uen dernière fois
Posté par Jerome Herman . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 10.
En ce qui cocnerne les dépèches argumentés, les posts complets, les arguments contrés et les longs threads (notamment contre free2) j'ai très largement fait mon boulot.
Si je regarde juste dans l'historique des commentaires de ma page perso (http://linuxfr.org/~khane/(...) ) on y trouve :
http://linuxfr.org/comments/609635.html#609635(...)
http://linuxfr.org/comments/609658.html#609658(...)
http://linuxfr.org/comments/609667.html#609667(...)
Dans une news récente, j'en ai pas mal soupé
https://linuxfr.org/2005/06/18/19158.html(...)
Seulement je suis d'accord qu'il faut un article clair et simple. Mais c'est très long à faire. je susi dessus depuis deux mois, j'avance bien même si j'ai beaucoup de mal à obtenir les informations (sur La Grande notamment) sans signer de NDA.
Le gros problème est que l'amalgame TCPA/La Grande/Trusted Computing entretien l'illusion que l'on ne eput avoir l'un sans les autres, ce qui est faux. On peut avoir une puce de sécurisation sous le controle total de l'utilisateur sans se frapper toute la clique de matériel espion et limitatif.
# On va se répéter uen dernière fois
Posté par Jerome Herman . En réponse à la dépêche Du respect de la vie privée et secrète du geek en milieu urbain. Évalué à 8.
La Grande (La surcouche d'Intel) c'est nettement moins sur. Et si La Grande est dangereux, l'implémentation du Trusted Computing complet par Microsoft a de bonnes chances d'être une horreur.
Mais la puce TPM est une belle invention, partique, utile, sure et fiable.
[^] # Re: Pas tout compris
Posté par Jerome Herman . En réponse à la dépêche L'OSDL annonce un projet de mise en commun de brevets. Évalué à 3.
Cette capacité fait qu'un groupe restreint qui essaye d'imposer le paiement de royalities pour son brevet se retrouve souvent le bec dans l'eau, même si il partait avec une avance considérable. L'exemple du MP3 est criant, conçu en trois versions (VoIP, Standard, Pro) le MP3 était seul sur le marché, universellement reconnu et très répandu. Aujourd'hui il n'en reste plus rien qu'une utilisation limité aux "jouets" et fort peu lucrative.
La baisse reccord de l'utilisation des algorithmes de type LZW (même si ils repassent dans le public). La mort idiote de rambus (qui avait déposé des brevets sur la SDRam, dans le dos du consortium).
Le monde informatique a une capacité assez forte à trouver une autre solution dès qu'on lui ferme la porte au nez.
Certes en cas de lutte contre tout un consortium la situation peut être différente. Mais génèralement les consortium ne se protègent pas à coup de brevets mais à coup de dispositifs anti-copies etd e lois qui en interdise le contournement. (probablement parcequ'ils ont compris depuis longtemps que le rôle des brevets avait été complètement perverti)
Tout celà pour dire que la bonne solution pour faire disparaitre les brevets ne consiste pas à avoir des brevets soit même mais à chercher des solutions qui ne sont pas couvertes par le brevet. Ca ne demande pas beaucoup plus d'énergie, c'est innarétable, et ça met mieux en exergue la futilité des brevets logiciels.
Comme disent les mongueurs : There Is More Than One Way To Do It
# A mon humble avis, ca n'est pas une bonne idée
Posté par Jerome Herman . En réponse à la dépêche L'OSDL annonce un projet de mise en commun de brevets. Évalué à 10.
Mais l'opensource tire très bine son épingle du jeu avec une stratégie "run and hit" qui a porté ses fruits à plusieurs reprise.
Les procès aus ujet des brevets sont très rare, le brevet "mal justifié" étant par esence une arme à double tranchant. Si vous poussez au procès, vous pouvez tout aussi bien voir un concurrent génant disparaitre que de voir votre brevet invalidé. C'est quite ou double. Et pue de compagnies on réellement envie de prendre se risque, surtout si au final il n'y a rien à gagner.
Si vous vous attaquez à un projet OpenSource qui a du succès et qui vous fait de l'ombre, vous prenez nons eulement le risque de voir vos brevet invalidés, mais aussi le risque de voir deux autres projets sur le même thème apparaitre immédiatement. Les royalties sur le gif ont engendrées une foule de formats graphique tous meilleurs que le gif, aussi bien pour l'imaegrie web que pour le stockage de masse de doccuments noir et blanc. Et bien sur tous libres. Dès que Frauhenauffer a commencé à exiger des sommes indues pour les licenses MP3, il s'est retrouvé à devoir combattre un plétore de formats, certains libre, d'autres non qui ont fini par le balayer (le mp3 ne sert guère plus qu'au baladeurs numériques, et encore de moins en moins. Echec total en ce qui concerne la voix sur IP, les formats vidéos multipistes etc.)
Aller au clash (au sens ne pas obéir au injonctions d'une société et pousser jusqu'au tribunal) sans l'appui d'une grosse boite commerciale c'est quasiment perdre la bataille. Alors que fermer un projet et attendre qu'il soit repris est quasiment imparable. A partir du moment ou de l'argent est en jeu, il faut absolument être sur de son coup. Intenter 40 procès d'affiler à un projet n'effraie pas du tout les grosses boites (j'en ai révé, sony l'a fait !). Qu'il gagnent ou perdent le procès n'a pas grande importance à leur yeux. Du moment que leur équipe continue à programmer tandis que les devs Opensource sont à la barre en train de témoigner et que les éventuels supports commerciaux fondent comme de la neige au soleil.
L'opensource est à l'heure actuelle dans une bulle de protection. Juridiquement, socialement et ecconomiquement personen ne sait trop quoi faire de ce "truc" qu'est l'opensource. Et cette méconnaissance de l'opensource est uen des meilleures armes dont nous disposions. Si on commence à jouer avec les règles de l'équipe d'en face on risque de prendre une pilée. Tout d'abord parceque ca poussera la communeauté à la schyzophrénie grave (se défendre avec des brevets dont on clame haut et fort qu'ils n'ont aucune valeur) et ensuite parceque l'on a pas de bras de levier pour porcéder à un échange d'IP. Comment respecter la GPL et reconnaitre que l'on utilise un brevet est propiétaire ?
Normalement dans le réglement de litiges à "l'amiable" entre deux sociétés qui font du proprio sur les brevets l'accord est simple : 50 -50. Tu ne me casse pas les pieds, tu gardes mon secret au chaud, tu continues ton business dans ton coin et moi pareil. En échange de quoi on oublie cette histoire de brevets.
Mais entre l'Opensource et une société c'est très différent. On demande à la société d'en face de reconnaitre que son brevet est librement diffusable, utilisable à volonté dans toutes les applications imaginables et ce par l'ensemble de l'univers en échange de quoi on ne donne rien vu que l'on considère qu'à partir du moment ou un projet est en GPL, en BSD ou en MIT c'est forcément que l'ensemble des algos sont librement utilisables (Sinon il y a uen grave atteinte des droits de l'utilisateur qui brise la license de facto).
Bref on s'arme pour une guerre que l'on en peut pas perdre sauf si on s'arme.
# Ce sondage doit changer
Posté par Jerome Herman . En réponse au sondage Ce sondage doit changer. Évalué à 4.
b) de slip - une string en UTF8 ca serait bien
c) de CAP - Je conseille l'ébénisterie sur contreplaqué, ca ouvre des BTS assez demandés
d) l'huile du reservoir, et revoir la pression des pneus. Ca serait dommage un accident de routage lors du départ en vacances
e) tous ses ¤uros contre des Yuans, il me remerciera plus tard quand il aura fait une plus value de folie sans bouger le petit doigt
f) d'air. Le sondage de linuxfR ca en jette quand même plus non ?
g) de disque. Car comme le disait hier encore Pierre Tramo à la réincarnation en moule de Charles Bronson : Moi je met toutes mes données en Raid 0, c'est plus sur.
[^] # Re: tar/zip
Posté par Jerome Herman . En réponse au journal Sauvegarder sur DAT en activant la compression. Évalué à 2.
La bonne façon de faire est de concatener les fichiers et les compresser en même temps. On obtient ainsi un seul dictionnaire pour la compression et donc de bien meilleure taux. Ensuite il suffit de prendre le catalogue du concateneur et de chercher l'index de début du fichier qui nous interresse.
C'est ce que fait DAR.
# J'ai une bonne et une mauvaise nouvelle pour toi
Posté par Jerome Herman . En réponse au journal Sauvegarder sur DAT en activant la compression. Évalué à 7.
http://dar.linux.free.fr/(...)
La mauvaise c'est que tu t'es donné beaucoup de mal pour quelque-chose qui existe déjà.
[^] # Re: MacOS uniquement sur les PC Apple ? Et alors, c'est pas nouveau !
Posté par Jerome Herman . En réponse au journal TPM et "matériel certifié". Évalué à 2.
Pour empécher d'installer un OS sur une plateforme, c'ets très simple. Il suffit de mettre n'importe ou sur la carte mère une puce dédiée, de préférence un DSP (parceque c'est très dur à émuler), dans une version modifiée introuvable dans le commerce (Par exemple on peut mettre un altivec). Ensuite il suffit de faire des appels à cet altivec un peut partout dans le code.
Résultat : Sur une carte mère qui n'a pas la dite puce, l'installation est plombée d'office, et el petit malin qui arriverait à émuler la puce aurait des perfs assez violamment impactée.
Ca marche redoutablement bien, coute nettement moins cher que d'appeler tout une archi sécurisée à la rescousse et beaucoup plus flexible (pas besoin de se conformer aux standards de totu un consortium)
[^] # Re: Comprends pas....
Posté par Jerome Herman . En réponse au journal TPM et "matériel certifié". Évalué à 7.
Pour celà il faudrait
a) Que la clef soit préchargée dans le TPM (ce qui est interdit par la norme).
b) Que l'utilisateur n'ait pas les droits owner sur la clef. Ce qui implique qu'il n'est pas owner du TPM (donc il ne pourra jamais rajouter ou changer des profils ou des clefs) et qu'il ne peut pas le devenir (ce qui est interdit par la norme.)
c) Un retour en usine (ou dans les mains de quelqu'un connaissant le mot de passe owner) à la moindre mise à jour du bios ou de tout autre périphérique compris dans le PCR (hash du boot) qui protège la clef. Un PCR contient 8 informations préboot faites d'offices au niveau de la ram, de la tension d'alim, du bios, de la carte mère et des différents bus. Le nombre de techniciens connaissant le "secret" du owner serait alors obligatoirement très élévé. Autant dire que le mot de passe owner des Mac x86 serait sur internet en 18 secondes.
En bref, on aurait un TPM qui casse la norme dans tous les sens, qui serait innutilisable en temps que coffre à clef pour l'utilisateur et qui en plus multiplierait par 10 le cout du SAV tout en apportant un gain de sécurité totalement illusoire vis à vis des petits malins....
Bref. Ca marchera moyen.
[^] # Re: Heureusement mon article avance
Posté par Jerome Herman . En réponse au journal TPM et "matériel certifié". Évalué à 4.
Pour l'instant l'intégration avec les logiciels est très faible, mais elle peut déjà remplir certaines fonctions comme l'identication par uen autre machien TCPA sur le réseau.
Sur les kernel récents, la puce est supportée nativement. Sinon les pilotes sont libres et disponibles ici :
http://www.research.ibm.com/gsal/tcpa/(...)
Si tu parles anglais, je ne saurais que trop te recommander la lecture de cet article http://www.linuxjournal.com/article/6633(...)
Ne te laisse pas impressionner par le code en C. La programmation de la puce est assez simple.
[^] # Re: Heureusement mon article avance
Posté par Jerome Herman . En réponse au journal TPM et "matériel certifié". Évalué à 9.
Officiellement La Grande est uen surcouche de TPM (donc passif) avec un mode de séquentialisation des zones bus mémoires (Protégé/pas protégé) et une sécurisation du clavier et de l'écran (Via un système de canal sécurisé). La Grande met très en avant son coté OPT-IN (comme la puce TPM) à savori que toutes les fonctions sont désactivées par défauts jusqu'à ce que vous les activiez explicitement.
Cependant certains passage de leur doc laisse penser que non seulement le logiciel peut intérroger le matériel (ce dont on se fout royalement - il est techniquement impossibel de bloque un PC avec çà) mais aussi que le matériel peut interroger le logiciel (Et là par contre danger, parcequ'un périph capable de faire une requète sur les logiciels qui tourne est aussi capable de se bloquer si il aime pas la réponse renvoyée)
Si on ajoute celà au fait que les canaux sécurisés sont prédéfinis et non pas calculés en focntion de la machine, on obtient assez facilement un écran qui refuse de monter en résolution ou en fréquence si il n'aime pas la signature du boot. Bien sur on peut transposer çà un disque dur ou une carte réseau et tout de suite ca fait froid dans le dos.
J'ai posé la question à Intel, mais je n'ai pas eu de réponse. D'ailleurs si un techos Intel me lit, qu'il n'hésite pas à prendre contact, je susi preneur de toute info qui n'est pas "Yellow Paper"
# Heureusement mon article avance
Posté par Jerome Herman . En réponse au journal TPM et "matériel certifié". Évalué à 9.
C'est ensuite par dessus que l'on peut éventuellement rajouter du matériel qui fait le blocage.
La puce TPM ne sait faire qu'une seule chose : répondre à un challenge venant de l'extérieur.
A bon entendeur..
[^] # Re: les temps on changés
Posté par Jerome Herman . En réponse à la dépêche Mobilisation européenne contre la rétention des données. Évalué à 7.
Parcequ'en France les chiffre sont là :
http://www.justice.gouv.fr/chiffres/chiffres.htm(...)
En moyenne 3 200 crimes et 420 000 délits dont les deux tiers sont liés au comportement sur routes, et un taux de réponse de 70%.
Les chiffres sont en baisse constante depuis 1998. (Soit 7 ans sur les 10 que tu cites...)
Sur les 11 000 000 de décisions pénales annuelles, 10 000 concernent des amendes forfaitaires majorées.
En justice civile (ie soiciétés) on a 2 milions de décisions prises chaque années, aucune ne donnan lieu à une condamnation pénale bien entendu.
Donc
a) On a jamais eu en France 26 000 000 de crimes et délits (je crois pas qu'on ait jamais officiellement atteind les 500 000)
b) En pénale on a 5 000 000 d'affaires par an, dont 1 350 000 sont poursuivables (ie on connait assez bien les faits pour donner suite, et les faits valent la peine de se pencher sur le cas).
Sur ces 1 350 000, on a 650 000 qui concernent des contraventions et 900 000 qui sont traités à l'amiables ou dans des tribunaux non pénaux (N.B : une affaire peut concerner une contravention ET être réglée à l'amiable).
reste entre 390 000 et 430 000 condamnations par an pour les crimes et délits.
Donc pour résumer, il y a en France 52 fois moins de crimes et délits que tu ne le dis et 13 fois plus de condamnations. (Et je tiens compte des crimes et délits liés au comportement, qui représentent les deux tiers des condamnations).
Bref tu te trompes dans un rapport de 1 à 676. Réjouis toi ! La situation est 676 fois moins grave que tu ne le penses.
J'ignore complètement qui te pourris la tête comme çà, mais la prochaine qu'il te sort de grande théorie appuyées sur des chiffres éloquants, prend des notes et vérifie par toi même. Tu vas tomber de haut...
[^] # Re: faux arguments
Posté par Jerome Herman . En réponse à la dépêche Mobilisation européenne contre la rétention des données. Évalué à 3.
Article premier
Tous les êtres humains naissent libres et égaux en dignité et en droits. Ils sont doués de raison et de conscience et doivent agir les uns envers les autres dans un esprit de fraternité.
Article 2
1.Chacun peut se prévaloir de tous les droits et de toutes les libertés proclamés dans la présente Déclaration, sans distinction aucune, notamment de race, de couleur, de sexe, de langue, de religion, d'opinion politique ou de toute autre opinion, d'origine nationale ou sociale, de fortune, de naissance ou de toute autre situation.
2.De plus, il ne sera fait aucune distinction fondée sur le statut politique, juridique ou international du pays ou du territoire dont une personne est ressortissante, que ce pays ou territoire soit indépendant, sous tutelle, non autonome ou soumis à une limitation quelconque de souveraineté.
Article 3
Tout individu a droit à la vie, à la liberté et à la sûreté de sa personne.
Article 5
Nul ne sera soumis à la torture, ni à des peines ou traitements cruels, inhumains ou dégradants.
Article 6
Chacun a le droit à la reconnaissance en tous lieux de sa personnalité juridique.
Article 7
Tous sont égaux devant la loi et ont droit sans distinction à une égale protection de la loi. Tous ont droit à une protection égale contre toute discrimination qui violerait la présente Déclaration et contre toute provocation à une telle discrimination.
Article 8
Toute personne a droit à un recours effectif devant les juridictions nationales compétentes contre les actes violant les droits fondamentaux qui lui sont reconnus par la constitution ou par la loi.
Article 9
Nul ne peut être arbitrairement arrêté, détenu ou exilé.
Article 12
Nul ne sera l'objet d'immixtions arbitraires dans sa vie privée, sa famille, son domicile ou sa correspondance, ni d'atteintes à son honneur et à sa réputation. Toute personne a droit à la protection de la loi contre de telles immixtions ou de telles atteintes.
Article 13
1. Toute personne a le droit de circuler librement et de choisir sa résidence à l'intérieur d'un Etat.
2. Toute personne a le droit de quitter tout pays, y compris le sien, et de revenir dans son pays.
Article 18
Toute personne a droit à la liberté de pensée, de conscience et de religion ; ce droit implique la liberté de changer de religion ou de conviction ainsi que la liberté de manifester sa religion ou sa conviction seule ou en commun, tant en public qu'en privé, par l'enseignement, les pratiques, le culte et l'accomplissement des rites.
Article 19
Tout individu a droit à la liberté d'opinion et d'expression, ce qui implique le droit de ne pas être inquiété pour ses opinions et celui de chercher, de recevoir et de répandre, sans considérations de frontières, les informations et les idées par quelque moyen d'expression que ce soit.
Je n'ai mis que les articles qui ont engagés un certain nombre de pays à ne jamais faire ce que tu suggère de faire.
Pour la suite :
http://www.un.org/french/aboutun/dudh.htm(...)
[^] # Re: PB EN BONNE PARTIE RESOLU
Posté par Jerome Herman . En réponse au message IMPOSSIBLE ENTRER EN MODE GRAPHIQUE SOUS LINUX. Évalué à 2.
Dasn l'ordre :
l'adressage mémoire foire, l'initialisation write combining foire, le chargement du module int10 (en charge de l'AGP dans Xorg) foire. Le chargement mémoire haute (dans lequel le mode VGA standard est placé le plus souvent) foire. L'énnumérations des ressources foire.
On va pas être méchant, mais entre ton kernel et ton Xorg il y en a un des deux qui se prend violament les pieds dans le tapis quand il charge l'AGP.
Mon intuition : ta distrib croit reconnaitre un port AGP qui est presque identique au tien mais comporte quand même des différences assez nette pour ne pas être compatible. A mon avis tu as un port AGP aux normes 1,2.5,3 qui est initialisé comme un port AGP aux normes 2 par ton kernel.
Comme c'est semblable, rien de choquant en vesa ou en frame buffer console (zone mémoire basse) par contre en initialisation graphique et en chargement mémoire haute c'est la fête.
Ca marche sous windows a cause du support du mode agp 1 et du fallback PCI.
Le problème est que si j'ai raison, ca va pas être évident du tout à régler sous Mandrake.
Malheureusement je n'ai as de solutions faciles à te proposer.
Dans ton xorg.conf ajoute la ligne
ModeLine "640x480" 25.175 640 664 760 800 480 491 493 525
dans a section monitor. ca va le forcer à prendre un mode 640x480 on ne peut plus standard, des fois que le roblème vienne de ligne du moniteur assez étranges.
Il me faut laussi la référence exacte de ton moniteur et de ton epia.
On vas se farcir tous les modelines à la main et voir si le problème vient de là.
[^] # Re: les temps on changés
Posté par Jerome Herman . En réponse à la dépêche Mobilisation européenne contre la rétention des données. Évalué à 9.
Les terroristes aimeraient bien nous imposer ce mode de vie.C'est pourquoi ils frappent au hasard pour utiliser la peur comme un argument pour transformer leurs idées en lois. Je n'adhère pas et je me battrais contre si il le faut.
Pour lutter contre le terrorrisme je vais perdre toute liberté. Mes conversations et mes publications vont être surveillés, mes pensées contraires me vaudront des séjour en prison, ma femme et moi seront obligés de porter uen puce identificatrice et je ne pourrais plus aller à la mosqué de temps en temps, ce serait faire montre de mauvaise volontée. Il y aura autour de moi des eternels suspects car ils n'auront pas la bonne couleur de peau.
Les gouvernement aimeraient bien nous imposer ce mode de vie. C'est pourquoi ils légifèrent au hasard pour utiliser la peur comme un argument pour transformer les idées en lois. Je n'adhérerais pas et je me battrais contre si il le faut.
# Ouhlà... Pas gagné ton histoire
Posté par Jerome Herman . En réponse au message IMPOSSIBLE ENTRER EN MODE GRAPHIQUE SOUS LINUX. Évalué à 2.
a) Le bios:
Dans le bios si les options suivantes existent :
AGP apperture : 64Mo
AGP fast write : disabled
AGP write combining : Disabled
Agp mode : au minimum (probablement 2x)
b) la config XFree
c) Pas à pas
Après avoir fait une sauvegarde de l'ancien xorg.conf et modifié ce qui était modifiable dans le bios, il faut utiliser le xorg.conf que j'ai donné tel quel.
Ensuite faire un test. Sous reserve de fautes de frappe (je suis un pro à ce jeu) ca devrait passer. (On a une config safe de chez safe qui fait passer le mode sans echec windows pour un dangereux expérimentateur).
Ensuite :
1 - réactivation du DBE, retest (enlever la première coche à la ligne #Load "dbe" ...)
2 - passage en mode vesa :
Device "fallback" devient Device "device1" dans la section Screen identifier "screen1"
3 - passage en mode 16 bits (15 bits à éviter à tout prix, gros problèmes d'alignement mémoire pour cause de hardware hors normes dans 99,9% des cas) :
DefaultColorDepth 8 devient DefaultColorDepth 16
Merci de me dire ce que tout celà fait.
[^] # Re: Un milliard?!
Posté par Jerome Herman . En réponse au journal 306 bugs dans FreeBSD. Évalué à 3.
Ca ce sent
... En fait, tout ce que je sais, à ce sujet, c'est qu'on m'a dit que le code d'openssh était assez horrible
Le mec qui t'a dit ca doit pas suivre tellement leur activité non plus.
et que c'était pour ça qu'on n'en faisait pas une bibliothèque.
On dirait que tu suis pas tellement la sécurisation des clients non plus.
Cela dit, pour en revenir sur la propreté du code, celui qui suit me semble parfaitement propre, malgré son dépassement :
int i[2];
[...]
/* This is an out-by-one, but it's volunteer, and we are sure there is enough place into memory for it. */
i[2]=0;
On en pleurerait
Je préfère quand même
void* i = calloc(2*sizeof(ulong));
int* j= (int*) i;
[...]
j[1] = (int) NULL;
Parceque ca compilera jamais deux fois de la même façon sur deux archis différentes. Même les warnings GCC changent à chaque compilation.... Ce qui est encore plsu drôle c'est la liste d'insultes que sort valgrind.
Bien sur c'est un bonheur pour tous les eptits malins en mal d'attaque par buffer overflow.
Et ca devient encore plus drole quand on passe j[1] en paramêtre d'une fonction.
[^] # Re: Terroriste!?
Posté par Jerome Herman . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 2.
Les cartes quads sont des 10/100. Le tout est en PCI-64, les versions PCI-Express sont prévues. On a donc environ 8Gbit/s de bande passante 4Gbit/s pris par la GE et encore 800Mbit/s pris par la quad 100E.
Quels processeurs va-t-il falloir pour commuter tout ça en software ?
Plus que les processeurs, c'est surtout la taille des bus et la réactivité des composants qui m'inquiéte. J'ai déjà fait tourner un agrégateur 5x100E <-> 1GE en software sur un OpenBSD. Les tests en charge simulées étaient convaincants, et la charge CPU loin d'être abhérante. Mais je n'ai pas pu le déployer professionellement (projet refusé).
Ceci étant tu es el second a me faire ces remarques. Je epnse donc qu'il est bon que je me remette en cause et que j'oublie l'émulation fonctionelle de 6500 avec un grille pain jusqu'à pouvoir prouver le contraire.
[^] # Re: Terroriste!?
Posté par Jerome Herman . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 2.
J'ai eu de très mauvaises surprises sous Cisco, notamment une migration de cartes qui a viré à la catastrophe pour cause de firmware pas assez à jour (et pourtant le techos qui nous aidait était un consultant Cisco). Le hot plug "5 minutes chrono en main" s'est transformé en iterruption de service pendant 6 heures. (La manip avait été planifiée le soir et une fois le réseau mis par terre il était pas question ni d'aller télécharger le firmware récent, ni d'aller dans le bureau d'en face pour faire la même chose).
Sauf que tout l'intérêt d'un 6500, c'est avant tout d'être un commutateur filtrant ! Si tu veux surtout comparer la partie routage/filtrage, il vaudrait mieux le comparer à un 38xx ou un 7xxx...
L'utilisation que l'on fait de la bête est chez nous la suivante : 10 points entrants, 20 poinst sortant et un point "poubelle/log". Le système nous sert principalement à checker la validité des paquest quir entrent et qui sortent et à prévenir une éventuelle tentative de déni de service massif.
Il y a aussi des relations vLan à vLan mais ce n'est pas la majorité.
Il se peut cependant que l'on ait été mal conseillé.
Manifestement tu connais nettement mieux le sujet que moi. Je vais donc mettre de coté mes idées iconoclastes jusqu'au moment ou je pourrais monter un système suffisament important pour tester moi même.
Admettons donc que ma foi en OpenBSD m'a aveuglé et/ou que je ne me rend pas complètement compte de la puissance d'un 6500.
Ce qu'il me faudrait par contre c'est un cas d'école, un cas qui utilise pleinement un 6500 (6 ou 13 vu que le 3 a l'air d'être de base un exemple dégénéré) pour que je commence à me demander comment je vais tester pour voir si l'équivalent est réalisable en OpenBSD/x86.
[^] # Re: Terroriste!?
Posté par Jerome Herman . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 2.
En groupe de deux seulement.
Connection directe A vers B.
A étant le redondant hardware full de B et réciproquement.
Chacun des des PCS n'utilise donc qu'un seul des deux ports Gigabits a des fins de transmissions d'états/redondance/syncro PF.
Si A se pête la gueule B prendra immédiatement le relais et il utilisera ensuite calmement le réseau "standard" (ie un des ports 10/100) via carp pour recréer la redondance.
Si A et B se pêtent la gueule, carp sera obligé de faire le boulot tout seul via le réseau 100. Et là on se bouffer de la latence (surtout en forte charge) le temps que Carp remonte 2 interfaces virtuelles, les sync et les synchronise.
Pour le reste, tu parles bien de 80 ports 10/100/1000 comme les ports du 6500 que tu veux égaler, non ?
Malheureusement pas, je susi toujorus dans le bas de gamme avec la carte 48 ports 10/100 + 4 en 1000. J'ignorais qu'il existait une carte 48 ports en 1000 chez Cisco (et je vois pas bien l'interet avec un bus de 8gb/s par carte), déjà avec la 48x100 + 4x1000 on touche aux limites en forte charge.
Non.
Parce qu'en ce qui concerne la fiabilité du point de vue du port, elle reste égale à celle du compposant le moins fiable entre la carte quad, la carte mère et la carte fibre... redondance ou pas. Et chacun de ces éléments est autrement moins fiable que les cartes 48 ports cisco ou autre.
Idéalement tous mes ports sont full redundant.
Si on est dans le cas 48 ports, j'ai donc au maximum 24 points sur mon cisco (2x24 pour pallier à un débrassage à la con). Sur mon armoire je peux faire du 3x24 (2x24 en redondance directe via le cable en 1000 et encore 24 en fallback via carp). On arrive à 72 ports de pris.
Supposons que la probabilité qu'un des ports Cisco tombe en panne sur une période donnée soit de une sur un million. En supposant que les cables ait été bien placé et que Cisco fasse bien son boulot on peut considérer que la probabilité que le port de backup tombe en panne aussi n'est pas lié a la probabilité de panne du premeir port .
Donc P(Port1KO) et P(Port1bisKO) = P(Port1KO) x P(Port1bisKO)
Soit une chance sur mille milliards.
Maintenant si la probabilité pour qu'un port ethernet PC tombe en panne sur la même durée est de une sur 10 000 (donc cent fois moins fiable que Cisco). Avec le même calcul on a
P(Port2aKO) et P(Port2bKO) et P(Port2cKO) = (10 000)^3
Soit une chance sur mille milliards.
Ici on voit qu'avec uen triple redondance sur du hardware classique on peut battre une double redondance sur du hardware très haut de gamme. (Par contre au niveau cout de maintenance, on se fait un poil matraquer, vu qu'on risque d'avoir fréquamment à changer une carte ou l'autre.)
Or le 6503 fait 4U, donc plus de 10 fois moins que ta solution.
Mea culpa again. Je pensais que c'était 4U hors support des cartes. Soit en fait une taille de chassis de 7U environ. J'ai dit ca de bonne foi. Ici on a un 6506 et le bloc double alim à lui tout seul doit déjà faire 3U.
[^] # Re: Terroriste!?
Posté par Jerome Herman . En réponse à la dépêche Comment des vendeurs essaient de breveter les solutions à des failles de sécurité qui leur sont fournies. Évalué à 2.
950 Watts seulement ? Je pensais que c'était beaucoup plus. Mea culpa. Ceci étant un serveur diskless/videoless sous openBSD a tendance à ne pas consommer beaucoup plus de 150watts en pointe et pas beaucoup plus de 50 watts en moyenne (a moins que le système ne soit utiliser comme commutateur de diffusion, mais alors il faut se reporter à ce que j'ai dit sur les commuts purs).
On va donc consommer entre 20x50 et 20x150 watts. Soit entre 1000 et 3000 watts.
Installation d'un 6500 : 0 minutes chrono (ben oui, c'est déjà installé)
Ca c'est la théorie, en pratique la config des cartes les upgrades de firmwares et le formatage des flashs peuvent réserver des surprises
Pour les trucs vraiment tordu, les règles sont plus simple sur pf, mais pour les règles de base, c'est aussi simple sous IOS lorsque l'on a l'habitude.
Ca vient de moi alors. Je dois manquer d'entrainement sous IOS, mais autant les règles de routages passent bien, autant je trouve que les règles de filtrage sont horribles.
Et accessoirement, si l'on prends une carte firewall, la différence de pris entre le chassis nu du 6503 et du 6506 est accessoire, on évitera donc de se retrouver trop court dès la mise en service en faisant des économies de bout de chandelles à coté...
HOULA ! Stop. OpenBSD peut arriver Un 6500 dans une optique routeur/firewall/switch. Plus on s'oriente vers un switch (et à plus forte raison vers un commut spécialisé), plus il va avoir du mal. C'est clair que si on retire l'étage firewall OpenBSD va avoir du mal.
Vu les problèmes de latences, j'y crois moyen à l'agrégation de lien entre 2 prises sur 2 PCs différents...
Je en vois pas en quoi celà va créer des latences. Tu tappes un ordinateur ou l'autre suivant le cas. C'est carp qui décide de l'interface active et c'ets donc vers celle là que tu tournes, exactement comem si tu étais en accès direct. A 60% (ou autre) de charge tu fait un sync "faible" via PFsync (si besoin) et tu changes l'interface. Niveau latence ca va être très très faible : un PFSync de temps en temps en surcharge.
Bref, soit tu te voiles volontairement la face pour ne pas voir les limimtations de ta solution, soit tu es d'une mauvaise foi à toute épreuve.
Disons surtout que pour essayer de pas trop partir en troll j'ai essayé de démontrer qeu l'on pouvait faire aussi bien que Cisco en utilisant les architectures réseaux type Cisco.
OpenBSD brille nettement plus dans des architecture éclatés, type Vauban que dans une topologie en étoile à forte centralisation. Mais là, les comparaisons déjà délicates seraient devenus impossibles.
Pour ce qui est de la mauvaise fois à toute épreuve il est clair que la comparaison se veut un poil provocatrice, néamoins honnêtement à ton avis peut-on ou ne peut-on pas remplacer un 6503+Superviseur+Firewall+48 Ports 10/100 par une grappe OpenBSD ayant un TCO inférieur ou égal et un degré de fiabilité comparable ?
Je pense très sincèrement que oui (et ce à peu près dans tous les cas).
Pour les modèle plus évolués c'est à étudier au cas par cas, notamment au niveau des besoins en commutation par rapport aux besoins en filtrage.
# Je vais être méchant.
Posté par Jerome Herman . En réponse au message sudo et apache chrooté [openbsd]. Évalué à 3.
Premièrement tu dis que ton apache est chrooté, j'en déduis que pf, snort, snort2c et mons2c sont dans les chroot avec lui non ?
Existe-t-il un autre pf qui tourne en non chrooté ? Sur la même interface ? Mêmes questions pour snort ?
Deuxièmement sudo c'est mal. On a maintenant des ACL sous linux et sous BSD. Sudo devrait donc disparaitre. Garde le owner de pf/snort etc. à root, créé un groupe "netsecure" et fait un chwon de netsecure sur les programmes dont tu as besoins (de préférence avec des droits limités genre juste en execution quand c'est possible). Enuite lance ton programme en php si tu veux.
La solution du parano consisterait plutot à dire que php est un nid à bug et à failles de sécurité (c'est pas tout à fait vrai ). Dans ce cas là la solution est de faire un check de sécurité du repertoire de chroot via tripewire qui si il est valide lance la commande.