ErrTu a écrit 108 commentaires

Encore une très bonne cuvée que nous livre les développeurs d'OpenBSD. La prochaine version s'annonce très alléchante aussi avec la prise en charge du WPA pour le wifi, du MPLS, peut-être une stabilisation de DRI/DRM pour avoir de l'accélération 3D et plein d'autres choses...

Euh, même sous lynx ça passe impeccable, c'est pour dire.

Cela vient d'une police incorrecte pour afficher les champs HTML dans ton navigateur ou alors que pour une raison inconnue il bouffe les espaces alors qu'il ne devrait pas.

Plus simplement, on peut aussi générer une chaine de caractère aléatoirement et la passer à banner[1] ou à figlet[2]. Ça fait des capchas lisibles assez facilement. Bon d'accord la protection offerte est plutôt faible mais pour le moment elle reste efficace.

C'est ce qui est utilisé pour s'enregistrer sur undeadly[3].

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=banner
[2] http://www.figlet.org/
[3] http://undeadly.org/cgi?action=register

Mencoder (l'outil de codage de mplayer) code via le projet x264 (celui que tu cites). En revanche Mplayer décode le h264 via les bibliothèques du projet ffmpeg ( http://ffmpeg.mplayerhq.hu/ ).

Euh, il me semble que c'était plutôt le contexte de la chanson d'OpenBSD 4.2 ça.

La chanson de la 4.3, c'est uniquement à cause d'RMS qui a fait son gros lourd sur misc@ et a confirmé ce que beaucoup pensaient déjà.

On est bien d'accord que tout est une question confiance envers le constructeur dans le cas où on accepte d'utiliser son matériel. Mais traficoter les paquets wifi, une carte avec le firmware de cablé en dur ou dans une ROM sur la carte peut aussi le faire.

L'idéal serait bien évidement d'avoir les schémas de la carte (comme au bon vieux temps du matos électronique) et le code source du firmware publiés sous une licence libre pour pouvoir en faire vraiment ce que l'on veut après.

Bien sûr que si il y a un intérêt (je vous laisse imaginer lequel, si vous n'en voyez pas c'est que vous n'en avez pas besoin), même si c'est rarement le cas.

De plus il est fort probable que le code source de ce micrologiciel soit inexploitable en l'état, incompréhensible et impossible à compiler avec nos compilateurs libres. Mieux vaut une bonne documentation sur le fonctionnement de la carte qu'un code source de micrologiciel.

Du moment qu'il est redistribuable, qu'il soit libre ou non, il n'empiète pas sur ma liberté.

Le nouveau "board of directors" de la fondation xorg comprend un "commiter" OpenBSD (Matthieu Herrb, mainteneur d'xorg dans OpenBSD) et un FreeBSD (Eric Anhold, mainteneur de DRI dans FreeBSD). Ils sont inscrits à titre personnel et non pas au nom de ces *BSD, mais gageons qu'ils prendront des décisions de sorte de ne pas les négliger.

D'ailleurs Matthieu Herrb a fait récemment une présentation sur les changements dans xorg et les *BSD (BSD and X.Org: changes ahead) au FOSDEM. On peut récuppérer le diaporama associé par ici : http://www.openbsd.org/papers/fosdem08-xorg.pdf

Oui, je n'en doute pas. C'était pour illustrer l'importance du contexte dans lequel le système se trouve.

Plutôt à OpenBox 2 non ?
http://icculus.org/openbox/2/

Qu'est ce que tu appelles exactement "tout le système" ?

Tout ce qui a dans le dépôt CVS du projet : en gros tout /usr/src (le noyau, l'userland, openssh, httpd (apache), sendmail...) et xenocara (xorg).

Qui a dit que les problèmes de fiabilité peuvent être traité avec zèle et que l'on peut les prendre à la légère ? surement pas moi, ni toi d'ailleurs. On est bien d'accord là dessus.

La sécurité et la fiabilité sont deux de mes préoccupations principales pour un serveur. Dans certain contexte, qu'elles soient intimement liées est un fait. Mais cela ne veut pas dire que je ne peut pas pas en faire clairement la distinction.

Juger de sa sécurité personnelle (dans la vraie vie) n'est pas la même chose que de juger la sécurité d'un système d'exploitation en lui-même.

C'est bien le problème de stabilité _qui implique_ ton problème de sécurité. Donc à la base cela reste un problème de stabilité.

Ton serveur aurait très bien pu planter dans les même condition avec un client plein de bonne volonté, mais ayant juste un comportement bogué ou légèrement différent des autres.

Je n'ai pas dis le contraire, et j'espère que tout le monde en est bien conscient. Ce n'est pas parce qu'on utilise un système d'exploitation qui se veut « sécurisé » que l'on est à l'abri.

Et ce serait un doux euphémisme d'avoir une méthode ultime pour mesurer la sécurité de n'importe quel système et ce avec précision.

Je ne dis pas qu'il ne faut pas prendre en compte le contexte dans lequel le serveur tourne, au contraire.

Mais si on reste au niveau du système d'exploitation en lui-même, sans se préoccuper de ce qui tourne dessus et autour, un plantage reste un plantage. Tout ce qui importe est de corriger ce problème pour que ce plantage ne se reproduise plus. Les développeurs écrivent des correctifs de stabilité et de fiabilité pour ça !

Ce n'est pas aux développeurs du système d'exploitation de se préoccuper si éventuellement peut-être dans un certain contexte cela poserait un problème de sécurité.


Après si toi, administrateur des machines qui contrôle l'aéroport, tu n'es pas capable de voir que si une machine qui n'est pas stable ni fiable cela va compromettre la sécurité des passagers (dans cet environnement bien particulier), je souhaite ne jamais monter dans un de tes avions.

Mais moi, si mon pauvre serveur plante, ben il ne se passera rien de dramatique : aucune donnée n'aura été volée, aucun programme malveillant n'aura été exécuté, la sécurité de mes autres machines n'aura pas été compromise non plus, ... et il n'y aura pas mort d'homme. Bref vraiment pas une faille de sécurité pour moi.

Exactement, si mon serveur plante, ce n'est pas un problème de sécurité, c'est un problème de stabilité.

un DoS peut compromettre la sécurité d'une architecture (fait un DoS sur un serveur de syslog, et ensuite vas dire "mais non c'est qu'un problème de fiabilité" au sysadmin). Il est donc aussi tout a fait normal de les déclarer en tant que faille de sécurité
Oui et heureusement, cela ne s'est pas encore produit. Dans les failles de fiabilité ou de stabilité, on retrouve les kernel panics, les freezes, les boucles infinies, certaines bases de données corrompues, ...
Il faut bien évidement noter que ces failles n'entrainent pas de failles de sécurité !

En même temps un DoS ne compromet pas la sécurité du système. Ce genre d'attaque se contente de rendre un service non disponible (en faisant planter un processus par exemple) donc il n'a pas lieu de les déclarer en temps que faille de sécurité. Ce sont bel et bien des failles de fiabilité.

Et puis pourquoi ne pas être fier de n'avoir eu qu'un faible nombre de faille de sécurité dans l'installation par défaut, même si cela réduit ce que l'on peut faire avec. C'est bien connu, moins il y de services qui tournent, moins il y a de sources potentielles de failles mais si ça ne les élimines pas toutes. Au moins, je sais que l'installation par défaut et une bonne base pour construire quelque chose par dessus.

Chaque faille d'OpenBSD est annoncée et un patch est toujours disponible en même temps pour corriger le problème (et ce pour tout le système, pas uniquement pour l'installation par défaut !). Je ne sais pas ce qu'il vous faut mais moi ça me convient parfaitement pour tenir à jour mes machines.

À ce jour il y a eu 8 correctifs pour OpenBSD 4.2 : 3 de sécurité, 4 de fiabilité et 1 pour corriger un problème de boot sur CD sur certaines machines. Je ne vois vraiment pas ce qui vous chagrine dans ce décompte.

en plus, du BSD peut devenir GPL...

Non, on ne peut pas changer la licence du code sous BSD pour la transformer en GPL. Rien ne nous empêche d'inclure du code BSD dans un projet GPL mais cette portion de code reste malgrès tout sous licence BSD (et elle ne devient donc pas miraculeusement du code sous GPL). C'est marqué dans les trois lignes de la licence BSD.

(Seul le détenteur du copyright a le droit de changer la licence du code.)

Nautilus, pour ouvrir un fichier ou parcourir l'arborescence il faut « double-cliquer » sur le dossier ou le fichier en question. Pourquoi ne pas mettre par défaut l'option « simple click » et se débarrasser une bonne fois pour toute de cette monstruosité qu'est le double clic.

Enfin je dis ça mais c'est pas pour autant que j'utiliserai nautilus... la bonne veille ligne de commande répond à tous mes besoins et ce sans souris.

Personnellement je ne signerai pas cette pétition.

Des pilotes potables ? non, ce n'est vraiment pas ce qui est important. Avoir des pilotes sous GPL, développés sous NDA ou pire des blobs fournis par VIA, ce n'est pas ce que j'appelle du respect pour les utilisateurs d'un logiciel libre.

Ce qui est réellement important c'est qu'ils fournissent _la documentation_ de leur matos. Ensuite tout le monde peut potentiellement développer des pilotes potables et ce pour tous les systèmes d'exploitation (pas uniquement pour linux).

non, Toute l'explication de ce flame war est dans le titre.

À chaque nouvel album du trappeur, c'est que du bonheur.

Déçu par l'album du TMX Band, revoilà David en plus grande forme que jamais.

Il y a hotplugd(8) qui permet d'effectuer automatiquement des actions lorsqu'on branche une clé usb, un cable réseau, ... (il y a un exemple de script dans la page de man).

Il y aussi amd(8) pour monter automatiquement et de façon transparente un volume. Par exemple : "cd /le/point/de/montage" et le tour est joué.