Juergen Descher schrieb: > Dort wird der Bug beschrieben, Datiert am: Date: 12 December 2002. > Ausprobiert - und :((( Mein vim ist anf�llig. In einer "stable"
In Unstable ist seit 26.11. ein work-around, der Fix seit 24.12. :-D > Also NIX resolved !!! F�r mich und alle anderen (uninformierten) > nicht. Und eine einfache Abhilfe bis zum eintreffenden Fix w�re die > Deaktivierung der modeline im rc-file - so einfach. Auch beachte man > die Zeitverz�gerung von ca. 1/2 Monaten! Die Ersten waren diesmal RedHat am 16.1., SuSE und Debian haben noch keinen Fix draussen. Der Grund d�rfte f�r beide �hnlich sein, dort die Zahl der Produkte und bei Debian die Zahl der Architekturen. Eine Verz�gerung von einigen Wochen bis Monaten ist nicht so ungew�hnlich. Der Wunsch, dass jeder Bug in 24h einen Fix hat ist unrealistisch. Und wie sich in den letzten Jahren gezeigt hat, auch nicht notwendig. Die ernsthaften Sicherheitsereignisse (W�rmer, etc.) basierten regelm�ssig auf L�cken die schon l�nger gefixt waren. Ebensfalls fast durchg�ngig ist der Trend, dass W�rmer offensichtlich auf Sicherheitswarnungen oder (wie z.B. bei SQL Slammer) entsprechenden Proof of Concepts der Sicherheitswarnungen aufbauen. Auch wenn ich ein Anh�nger der schonungslosen Ver�ffentlichung bin, muss man sagen, Wasser auf die M�hlen derjeniger, die bis zum Erscheinen eines Fixes lautloses Arbeiten empfehlen. Nicht ohne Grund hat diese Praxis (ganz lautlos :-) auch im OSS-Umfeld Einzug gehalten. > debian-security nicht abonniert. Dachte sec-announce w�rde reichen. > In so einen Fall k�nnten die doch eine Warnung herausgehen _obwohl_ > noch keine gefixte Version erh�ltlich ist - oder? W�re vielleicht nicht schlecht, aber wie soll das funktionieren? Was Du als bedrohlich empfindest, empfinde ich als unproblematisch. M�sste alles ver�ffentlich werden, was nur irgend jemand als bedrohlich empfinden k�nnte, hast Du eine Liste mit sehr hohem Volumen, wo sich jeder m�hsam das heraus picken muss, was f�r ihn selbst relevant erscheint. Solche Listen gibt es schon, z.B. bugtraq. Der Bug ist theoretisch sehr gef�hrlich, aber ist das auch in der Praxis realistisch? Jeder Schl�sseldienst verf�gt �ber Werkzeug 95% aller T�ren in weniger als 60 Sekunden spurlos zu �ffnen. Kann man es sich aufgrund dieses theoretischen Sachverhalts in Zukunft sparen abzuschliessen oder �berhaupt T�ren einzubauen? > Wieviele �hnliche und bekannte Grave functionality Bugs befinden sich > noch auf meinem woody? 42 > Muss ich jetzt alle Pakete abklappern ?-) Wenn nicht Du, wer sonst... -- [EMAIL PROTECTED] -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
