Foxy a écrit 668 commentaires

Euh... les machines de tests vous connaissez ???

Perso, les développeurs kernel que je cotoie, ils testent pas leurs développements noyau sur la machine qu'il utilise pour développer. Ils bootent leur kernel à tester sur des machines de tests reservées à cela. Et on s'arrange pour avoir des solutions de réinstallation de ces machines : boot réseau, images de backup du système...

Mais bon, je ne sais pas quel distrib Linux Linus utilise.

Tu n'as qu'à contacter l'ALDIL (LUG lyonnais) http://www.aldil.org(...) sur leurs mailling-listes. Il y aura certainement quelqu'un pour te répondre à ce sujet.

Tiens ça me fait penser que ça fait bien longtemps que j'ai pas vu une discussion sur LinuxFr qui dérive au point qu'elle se conclue avec un magnifique point Godwin.

Ca doit être la maturité des lecteurs et rédacteurs sur le site qui veut ça ;-)

Par ailleurs pour ce qui est de remplacer les Catalyst (enfin plutôt les routeurs), c'est plutôt le travail de XORP.

Tout à fait et un des objectifs du projet OpenBSD est de très bien supporter XOrp sur OpenBSD.

En plus du développement des démons OpenBGPD et OpenOSFD, on peut aussi noter l'implémentation récente du Multipath Routing et du Protocol Independent Multipath (http://undeadly.org/cgi?action=article&sid=20050115003448(...))

exactement. d'autant plus que le copyright étant ce qu'il est, ils doivent "citer leurs sources", ce qui fait de la pub pour OpenBSD si un bon système propriétaire se base sur leurs logiciels (cf. Darwin, et d'autres).

Désolé mais ça fait bien longtemps que la clause de "publicité" de la licence BSD a été retirée de la licence BSD-like utilisée par le projet OpenBSD (et donc OpenOSPFD).

Donc quelqu'un qui utilise du code OpenBSD pour un projet "closed source" n'est pas obligé de le dire :-(

Oui, l'écriture d'un démon HTTP par l'équipe d'OpenBSD viendra certainement un jour pour remplacer Apache.

A l'heure actuelle, depuis les modifications de la licence Apache, le projet OpenBSD ne met plus les sources à jour mais corrigent seulement les problèmes de sécurité.

Allez pour mémoire relisez l'article d'ACM 85 de Ken Thompson sur la problématique de sécurité du code d'un compilateur compilé par lui-même.

Comme ça, ça fera encore plus de questions philosophiques ;-)

Modifiables, non, mais certains peuvent être éliminés (le statut UNCONFIRMED est desactivé par défaut, l'utilisation de VERIFIE D est facultatif, etc...)

Le Statut VERIFED, c'est mon préféré lorsque j'ai vérifié que les devs ont bien fait leur boulot et que leur correction est validée ;-)

Est-ce que tu as contacté le (ou les) mainteneur(s) Debian du package OpenLDAP ?

Ils seraient sûrement les plus qualifiés pour t'expliquer pour quoi le package Debian OpenLDAP l'est pas à jour.

Et si tu es courageurs, tu peux le mettre à jour toi-même et leur proposer ton aide ;-)

-Le tableau blanc du "codeur" : il est rempli de calcul combinatoire. Quelqu'un peut-il dire de quoi s'agit-il exactement?

Mouais, d'après mes vieux souvenirs de prépa et d'école, on aurait dit des équations de Stirling (truffés de racine carrée de 2*Pi, n factoriel...) => calcul combinatoire

Par contre, quand on voit son écran sous KDE, je suis quasi-sûr qu'il lit le code de GPG ou de OpenSSL (ça y ressemble grandement).

Le mieux restait quand même le geek aux cheveux longs (un employé sous contrat car il fait pas très DGSE ;-) ) ouvre la porte de la salle serveur et qu'il y a des montagnes de baies de serveurs => ça ressemble furieusement à un cluster de calcul maison.

PS: oui je sais, je suis beaucoup plus "joueur" avec un PC qu'avec mon Zaurus... je dois plus respecter mon Zaurus que les boites beiges diverses que l'on met sur mon bureau...

Ah tiens, moi les boites beiges, je les mets SOUS mon bureau mais chacun son truc ;-)

Et le port de NetBSD sur DreamCast, ça sert à quoi ?

Il ne faut pas toujours chercher une explication à tous les développements du monde open-source : certains codent des applis qui leur sont utiles et les diffusent, d'autres codent avant tout pour le challenge technique. Les ports d'OS libres sur plateforme "ésotérique" font plutôt partie de la 2ème catégorie.

Enfin, moi je serai quand même content d'avoir mon client SSH sous OpenSD sur mon Zaurus + Wifi pour me connecter depuis n'importe où chez moi par exemple.

D'après mon expérience perso au boulot (pas mal de matos Gigabit Ethernet différents) :

- switch 3Com (évite le DLink)

- carte Ethernet Intel 1000/MT (server ou desktop suivant utilisation) + driver e1000 développé par Intel.

==> avec ça, ça fonctionne nickel.

Et contrairement à ce qui est dit dans une réponse, y'a pas besoin de plus de RAM pour utiliser du Giga par rapport à du 10/100.

Le seul problème est qu'avec du Gigabit, lors d'un transfert de fichier, il faut un disque qui tienne la route pour écrire le fichier assez vite (vu que le réseau le transmet beaucoup plus rapidement).

Je confirme : TOR est un proxy anonymizer simple à utiliser pour tout type d'application "sockifiable".

Il faudrait qu'il y ait plus de noeud de routage pour que le réseau prenne de l'ampleur et soit vraiment efficace.

Je n'ai pas envis d'un OS type openBSD qui évolue tout doucement et est à 100 lieux de ce qu'on peut faire actuellement avec un OS "moderne".

OH, le gros troll kipue ;-)

OpenBSD n'est pas un "OS qui évolue tout doucement" : certes certaines fonctionnalités mettent du temps à être supportées (par exemple le SMP i386 seulement en 3.6) mais d'autres sont beaucoup plus mûres que celle existantes sous Linux (PF est bien plus utilisable que Netfiltter IMHO; OpenBGPD, OpenNTPD...).

L'objectif d'OpenBSD n'est pas le même : sécurité avant tout et cet OS a l'avantage de proposer quelques fonctionnalités de sécurité en standard (ProPolice, systrace, protection W^X, StackGuard...) qui ne sont que des patchs noyax épars sur Linux (GRSec, exec-shield...).

Chacun son choix suivant ses besoins : perso OpenBSD pour mes FW et serveurs courants (HTTP, mail...), desktop et laptop sous Linux 2.6

j'en vient à penser que les failles du noyau sont pas le pire problème du Linuxien, point de vue sécurité.

Oui mais ça fait plaisir à certains de croire qu'il suffit de suivre les alertes et de se mettre à jour pour les packages de leur distrib pour être "sécurisé".

Alors que cela commence pour une bonne application de sa politique de sécurité sur ses postes clients et serveurs.

Effectivement, ils ont dû s'en apercevoir et il y a maintenant une certificat valide.

Pour ce genre de tâches avec Mutt, la fonction la plus pratique est le tagging de messages.

Pour appliquer une même action (sauver, forwarder) à un ensemble de messages, tu taggues tes messages :

- avec la touche 't' tu taggues les messages un par un
- avec 'T', tu peux donner un pattern pour tagguer un ensemble de messages

Après tu peux vérifier la liste des messages taggués avec la fonction 'limit' :
- touche 'l' pour limit puis pattern '~T' pour restreindre le limit aux messages taggués (pattern '.' pour revenir à la liste de tous tes messages)

Ensuite une fois que tu as taggué un ensemble de messages, tu utilises la touche ';' pour que la fonction suivante s'applique aux messages que tu as taggués.

Par exemple :
- ';' puis 's' pour sauver l'ensemble des messages taggués
- ';' puis 'f' pour forwarder l'ensemble des messages taggués
- ';' puis 'd' pour supprimer l'ensemble des messages taggués

Pour passer à la release suivante, il y a un peu plus de boulot que sur une Debian ;), car OpenBSD te laisse la charge de mettre à jour tout ce qui n'est pas binaire (/dev, users systèmes, config, etc)

Tout à fait, l'upgrade d'OpenBSD vers une version supérieure fonctionne très bien mais il y a une peu de travail à faire "à la main" : MAJ des /dev, des users, groups et surtout MAJ des fichiers de /etc

Pour l'upgrade en 3.6, il y a ce document qui reprend tous les points pour cela : http://openbsd.org/faq/upgrade36.html(...)

Sur OpenBSD, après la sortie d'une release, la branche STABLE est maintenue pendant un an et des patchs sont publiés pour les MAJ de sécurité (annoncés ici : http://openbsd.org/errata.html(...)).

Il vaut mieux récupérer ces patchs "à la main" et recompiler en conséquence. Il y a un système officieux de publication de ces MAJ en binaire mais non supporté par l'équipe de dev OpenBSD.

Pour les ports, ils sont mis à jour au fil de l'eau sur le CVS suivant le travail des mainteneurs. Mais seuls certains d'entre eux sont recompilés et les packages mis à jour sur les serveurs FTP (généralement en cas de problème de sécurité important sur une appli).

Sauf que quand on sait pas faire la différence entre un OS et une distribution avec desktop graphique préconfiguré (comme pour les distributions Linux majaures), on évite de poser la question.

Ca en est malheureusement au point qu'avec mon Firefox 1.0PR sous Linux (pas le problème sous Windows 2000), je n'ose plus voter sur LinuxFR de peur de prendre nu crash et que je me méfie aussi des sites ouvrant des pages dynamiques :-(

Espérons que ce bug soit corrigé dans cette version RC.

On verra à l'utilisation si le bug que j'avais noté (l'ouverture de 10/15 tabs et d'une fenetre pouvait entrainer le plantage de Firefox) a disparu.

Je ne sais pas si c'est le même bug mais perso, sur une fenêtre avec beaucoup de tabs (mon dada, surtout avec l'utilisation de l'extension "SessionSaver"), si j'ai un site qui ouvre une autre fenêtre dynamiquement (par ex. fenêtre dynamique lors d'un vote sur LinuxFR), mon Firefox 10.0PR (0.10.1) crashe quasiment à chaque fois :-(

J'espère que ce bug a été corrigé pour cette release.

non, il ne faut pas abandonner la notion de web of trust mas la faire reposer sur un reseau de connaissance et pas autre chose, personellement je n'attribut pas ou peut de valeur a des signatures de gens que je ne connais pas.

C'est d'ailleurs pour cela que dans GPG, tu peux donner un niveau de confiance (de 1à 4) aux clés que tu signes :

- niveau 1 : on ne fait pas de tout confiance à la personne à qui appartient cette clé (i.e. il signe vraiment n'importe quelle clé sans même avoir rencontré physiquement les possesseurs de clés)
- niveau 4 : c'est un très bon copain, j'ai entièrement confiance en lui et je sais qu'il est très rigoureux dans la vérification des clés qu'il signe

Avec ces indicateurs, on peut reconstruire un "web of trust" avec un niveau de confiance pour un "chemin" de signatures entre 2 clés.

Le problème est qu'avec les systèmes d'authentification d'utilisateurs (que ce soit par clé GPG ou par certificats X509), à un moment ou un autre, il faut se fier à une preuve physique de l'identité.

Pour GPG, on fait généralement ça lors de keys-signing parties où chacun présente ces papiers et valident ses clés par ses fingerpints.

Pour les certificats numériques, les fournisseurs de certificats (Thawte, Verisign) font de même avec une présentation de preuve d'identité.

Néanmoins, il faut bien à un moment prendre cette preuve pour argent comptant.

Personne (ni une personne physique, ni un organisme de certification) n'a la possibilité de vérifier l'authenticité de cette preuve. Seul un Etat peut vérifier l'authenticité de papier d'identité.

Si on accepte pas ce postulat de base, autant abandonner directement la notion de "web of trust" pour les clés GPG.