Benoît Sibaud a écrit 9775 commentaires

C'est pas une question d'altération des paquets, mais de délai de propagation. Le temps de propagation des mises à jour sécurité sur les miroirs successifs augmente la fenêtre de vulnérabilité.

le mien (interne à ma boîte) a été victime d'une inondation lundi... Après l'eau et le feu, je prévois une chûte de météores (terre) sur les routeurs me reliant à Debian et un ouragan (air) sur le LIP6 :(

http://lists.debian.org/debian-security/2002/debian-security-200211(...)

« it has been confirmed that the Twente University server rooms have now
completely burned down. This means, {security,non-us,nm,qa}.debian.org
and ftp.snt.utwente.nl are now lost. Rest in peace... »

> la question c'est "est-ce que l'hébergeur savait ?"

Au passage, est-ce que le rédacteur du commentaire savait qu'il enfreignait la loi française (les serveurs étant en France) pour cause de propos racistes ou autres ? Sur LinuxFr, il y a des francophones de Suède, des Etats-Unis, du Japon, du Maroc, etc, où les lois sont différentes. La conséquence n'est pas trop grave cela dit, simplement son message sera rejeté/supprimé/masqué.

Si A et J sont colocalisés, le trafic du deni de service passe par les mêmes routeurs. On saturant le dernier routeur commun, on bloque les deux serveurs. S'ils sont physiquement éloignés, les deux chemins sont disjoints, et il faut saturer les deux. Ce n'est pas la panacée, mais ça évite de mettre ses oeufs dans le même panier. Dit autrement ça serait dommage de perdre A et J juste parce qu'une pelleteuse a sectionné la fibre optique amenant au dernier routeur (et oui ça arrive).

Il n'a été modéré qu'une seule fois, donc non il a toujours été en second page.

Vous préférez :
- une faille avec accès root distant ou trois avec un accès nobody local ?
- un débordement de tampon difficilement exploitable ou trois failles avec juste une URL à taper ?
- une faille qui marche partout ou seulement sur la version ARM d'une appli ?
- une faille sur des logiciels utilisés par 3% de la population utilisant le système concerné, ou une faille qui touche tous les utilisateurs d'un système donné ?
- ...

Bref, un peu de pondération me paraît indispensable.

J'ai eu effectivement en doute en modérant, j'ai vérifié sur granddictionnaire.com, qui dit bien versatile <=> polyvalent et j'ai bêtement sauté la note qui dit « En français, versatile qualifie une personne qui change souvent d'opinion ou de parti, qui est inconstante ou lunatique. »

Bref corrigé.

Mais alors c'est comme G*la, Paras Mitch, Vo*ci, Voilo, et Cie, tout le monde les critique, personne ne les lit mais tout le monde connaît leur contenu ?!? Pfff MISC c'est nul y a qu'une femme habillée cachée page 82...

> autant nous empêcher de vivre aussi...

J'aime les propos modérés. Salauds de militaires qui nous empêchent de manger, de boire et de nous loger !

> Quelqu'un connaît l'usage qu'en fait l'Armée. Je trouve étrange que Toulouse (31) soit exclu et pas le Tarn ou l'Aveyron, où l'Armée de Terre y fait régulirement des manoeuvres.

Une hypothèse : sur un vrai champ de bataille, on va pas demander à l'opposant de couper ses cartes WiFi ou d'éviter de parasiter les fréquences que l'on utilise pour nos communications. Donc si on décide d'autoriser ses fréquences quelquepart (ici dans 38 départements), je vois pas trop pourquoi on devrait exclure les endroits où l'armée s'entraîne. Et d'ailleurs le raisonnement s'étend même au cas où on décide de n'autoriser ses fréquences nulle part.

Templeet, pas daCode. Y a plus de daCode sur LinuxFr.

Les templates LinuxFr sont dans le cvs de templeet module linuxfr. Cf procédure cvs sur templeet.org.

sous le coude... (lapsus)

'Ils' (plutôt 'il' en fait vu qu'il y en a qu'un qui bosse vraiment sur le code LinuxFr actuellement) n'ont pas « viré » les XP. Ils ne les ont pas codés. ça fait une grosse différence. Et ils ont un projet de XP sous le code, mais ce n'est pas leur priorité. Donc si certains sont pressés, qu'ils filent un coup de main. Vas-y Hap, mors-y l'oeil !

> C'est pas beau :(
> Les écrans sont trop loins les uns des autres.

La solution est évidente : prendre une webcam pour filmer le mur, et remettre bout à bout les 16 images pour pouvoir les afficher sur un seul écran ! Pff z'êtes vraiment nuls ici.

D'abord merci pour la dépêche, la compilation de liens et la prise d'opinion. Il est bon de rappeler à tous l'arrivée de l'EUCD.

Quelques remarques sur la forme dans la partie opinion :

> procès si ils publiaient des articles portant sur des algorythmes de cryptage

"s'ils", "algorithmes" et "chiffrement".

> au contenu crée

"créé"

> et limite

"limitent"

> reduit

réduit

non je crois malheureusement qu'il parlait de la faute à conjugaison que j'ai faite :)

GCC fait pareil pour maintenir le support d'architectures « obsolètes ».
Cf http://gcc.gnu.org/gcc-3.1/changes.html(...) bas de la page.

> Pour moi, il n'y a aucune raison à l'heure actuelle d'installer une Debian (à part l'immobilisme et l'attachement sentimental).

Mon avis perso qui n'engage que moi :
- 11 architectures supportées. Perso j'utilise i386 et Sparc (ça réduit déjà pas mal le nombre de distrib), et je réfléchis pour PPC.
- soutien à la seule distrib non commerciale (que des bénévoles)
- mise à jour facile
- qualité des paquets, stabilité au sens Debian
- équipe sécurité réactive
- aspect idéologique/éthique
...

> "tu" dis que l'ancienne ne vaut peut-être plus le coup de la supporter.
Pas exactement. C'est pas une question de « vaut-il le coup de » mais de « est-on capable de » (cf « the Debian Security Team cannot support potato security endlessly. »)

MS est payé pour assurer le support, pas Debian. Si quelqu'un veut du support pour sa Debian que Debian ne peut lui offrir, il peut payer une société de services pour ça. Ce n'est pas exactement comme si MS annonçait l'arrêt du support de Windows 2000, plantant tout le monde sans d'autre solution que la mise à jour.

Oui ça serait mieux si Debian pouvait assurer le support de la Potato pendant encore 12 ou 18 mois. Mais ce n'est pas possiblement humainement pour Debian. En plus cela poserait des problèmes de sécurité justement... (cf ssh 3 qui n'a rejoint la Potato que récemment).

Toutes les machines GNU/Linux dont je m'occupe (une douzaine en tout, i386 ou sparc) sont sous Debian Woody (sauf une en Sarge). La plupart ont été installées en Slink à l'origine puis mise à jour en Potato puis en Woody, à partir de notre miroir interne.

Comparer Debian à MS n'a pas grand sens ici. Le modèle du libre et le modèle propriétaire n'ont pas grand chose à voir.

« La preuve qu'on se rend bien compte que beaucoup de gens sont déjà passés en sid. »

Plus qu'avant ? En prod aussi ? Tu as des chiffres ou des infos pour étayer tes dires j'imagine ?

« Ne plus maintenir la potato ne vaudrait le coup que si les sorties des versions étaient plus fréquentes. »

Tu peux détailler stp ? Parce que là, on dirait un troll à deux balles.

il y a quand même une différence entre une mise à jour d'une distrib (apt-get upgrade) et la mise à jour vers la nouvelle distrib stable (apt-get dist-upgrade). Pour le reste je te laisse à ton troll stérile.

Il faut aussi prendre en compte la taille des effectifs de MS et ceux de Debian, la quantité de logiciels fournis par l'un et l'autre (plus de 10000 paquets dans une Debian) ainsi que les revenus de l'un et de l'autre. Dit autrement, les bénévoles de Debian ne peuvent pas assurer la maintenance sécurité pour les milliers de paquets et pour plusieurs distributions (Potato, Woody et parfois testing/sid si nécessaire).

Par contre il est plus facile de trouver une SSII pour assurer le suivi sécurité d'une Debian Potato (rétro-porter les correctifs sécurité) que d'un Windows (difficile de rétroporter du binaire...).

Sur un LAN avec 3 Debian, je vois pas trop en quoi sniffer mon réseau va m'aider à découvrir si MS met des portes dérobées dans ces logiciels... Maintenant si tu veux me filer un accès sur ton réseau et me signer un papier m'autorisant à le sniffer, oui pas de problème je veux bien regarder si MS le fait ou pas.