Bei freier Software gibt es einen relativ glatten Übergang zwischen rein internen Diskussionen und öffentlichen Bekanntmachungen. Das liegt zum Teil daran, dass die Zielgruppe immer schlecht bestimmbar ist: Angesichts, dass die meisten oder alle Nachrichten öffentlich zugänglich sind, hat das Projekt nicht die volle Kontrolle darüber, welchen Eindruck die Öffentlichkeit bekommt. Jemand—sagen wir ein heise.de Mitarbeiter— kann die Aufmerksamkeit von millionen Leser auf eine Nachricht richten, von dem keiner vermutet hätte, dass sie jemals außerhalb von dem Projekt gesehen werden würde. Das ist eine Tatsache des Lebens, womit alle Open Source Projekte leben müssen, in der Praxis aber, ist das Risiko für gewöhnlich klein. Im algemeinen, sind die Bekanntgaben die das Projekt am ehesten öffentlich verbreiten will, diejenigen die auch am ehesten bekannt werden, angenommen Sie nutzen die richtigen Mechanismen darauf hinzuweisen, wie berichtenswert es ist für die Öffentlichkeit ist.
Für großere Bekanntgaben, gibt es allgemein vier Hauptkanäle der Verbreitung, auf den Melungen so gleichzeitig wie möglich gemacht werden sollten:
Die erste Seite Ihres Projekts wird wahrscheinlich von mehr leuten gesehen, als irgend ein anderer Teil des Projekts. Wenn Sie eine wirklich große Ankündigung haben, schreiben Sie einen paar kurzen Sätze dorthin. Sie sollten eine kurze Zusammenfassung sein die auf die Pressemitteilung (siehe unten) für weitere Informationen verweist.
Gleichzeitig, sollten Sie auch einen "Nachrichten" oder "Pressemitteilungen" Bereich auf der Webseite haben wo die Bekanntgabe im detail erläutert werden kann. Der Sinn von einer Pressemitteilung liegt zum Teil darin, ein einziges kanonisches "Bekanntgabe Objekt" zu haben, auf dem andere Seite verlinken können, also stellen Sie sicher, dass es entsprechend strukturiert ist: entweder als eine Webseite für jede neue Version, als diskreten Eintrag in einem Blog, oder als irgend eine andere Art Entität auf dem verlinkt werden kann, und trotzdem eindeutig zu unterscheiden ist, von anderen Veröffentlichungen im selben Bereich.
Wenn Ihr Projekt einen RSS Feed hat, stellen Sie sicher, dass die Ankündigung auch dort veröffentlicht wird. Das mag automatisch passieren wenn Sie die Pressemitteilung erstellen, abhängig davon, wie Ihre Webseite eingerichtet ist. (RSS ist eine Methode, um Nachrichten Zusammenfassungen mit einer Menge Metadaten an "Abonenten" zu verteilen, zu verbreiten, also Leute die ein Interesse gezeigt haben, diese Zusammenfassungen zu bekommen. Siehe http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html für weitere Informationen über RSS.)
Wenn es in der Ankündigung um eine neue Version der Software geht, dann aktuelisieren Sie den Eintrag Ihres Projekts bei http://freshmeat.net/ (siehe „Bekanntmachung“ in dem es darum geht diesen Eintrag überhaupt erst anzulegen). Jedes mal, wenn Sie einen Freshmeat Eintrag aktuelisieren, geht dieser Eintrag auf die Änderungsliste von Freashmeat für den Tag. Die Änderungsliste wird nicht nur auf Freashmeat selber aktuelisiert, sondern auf verschiedenen anderen Portalen (inklusive slashdot.org) welches erwartungsvoll von einer Horde Menschen beobachtet wird. Freshmeat bietet auch die gleichen Daten mittels eines RSS Feed an, damit Leute die den RSS Feed von Ihrem projekt aboniert haben, die Ankündigung trotzdem durch den von Freshmeat sehen.
Schreiben Sie eine Email an den Verteiler für Ankündigungen (en. announcement) ihres Projekts. Der Name von diesem Verteiler sollte wirklich "announce" sein, d.h. announce@ihrprojekt.org, weil das mittlerweile so ziemlich zum Standard geworden ist, und Ihr Projekt sollte klarstellen, dass es einen sehr geringen Betrieb hat, ausschließlich für Projekt Ankündigunen. Die meißten dieser Ankündigunen werden sich um neue Versionen der Software drehen, gelegentlich aber andere Ereignisse, wie eine Spendaktion, die Entdeckung einer Sicherheitslücke (siehe „Bekanntgabe von Sicherheitslücken“) später in diesem Kapitel, oder eine größere Änderung in der Richtung des Projekts können dort auch gemeldet werden. Da es ein Verteiler mit geringem Betrieb ist und nur für wichige Sachen benutzt wird, hat der announce Verteiler typischerweise die höchste Anzahl an Anmeldungen von allen Verteilern in Ihrem Projekt (das bedeutet natürlich, dass Sie es nicht missbrauchen sollten—überlegen Sie genau vor Sie etwas schreiben). Um zu vermeiden, dass jeder beliebige, oder schlimmer noch, Spam durchkommt, muss der announce Verteiler immmer moderiert werden.
Versuchen Sie die Ankündigunen an all diesen Stellen zur gleichen Zeit zu machen, so nahe wie möglich. Manche werden vielleicht verwirrt, wenn Sie eine Ankündigung auf dem Verteiler sehen, aber keinen entsprechenden Eintrag auf der Webseite des Projekts oder seinen Pressemitteilungen, welches dem entspricht. Wenn Sie die die verschiedenen Änderungen (Emails, Bearbeitung der Webseite, usw.) aufreihen und alle in einem Zug abschicken, können Sie das Fenster der inkonsistenz sehr klein halten.
Bei einem weniger wichtigen Ereigniss, können Sie manche oder alle obigen Kanäle ausschließen. Das Ereigniss wird immer noch von der Öffentlichkeit entsprechend seiner Wichtigkeit bemerkt werden. Während zum Beispiel eine neue Version der Software ein großes Ereigniss ist, ist lediglich das Datum für eine neue Version festzulegen, wenn auch einigermaßen Berichtenswert, nich annähernd so wichtig wie die neue Version selbst. Ein Datum festzulegen ist eine Email an die täglichen Email Verteiler wert (nicht an den "announce" Verteiler), und eine aktuelisierung der Zeitplan oder der Status Seite, aber nicht mehr.
Sie werden vielleicht trotzdem dieses Datum in anderen Diskussionen im Internet auftauchen sehen, überall dort, wo Leute an dem Projekt interesiert sind. Leute die auf Ihren Verteilern herumschleichen, lediglich horchen und nie etwas sagen, sind nicht unbedingt an andern Stellen still. Mundpropaganda sorgt für eine sehr weite Verbreitung; Sie sollten darauf zählen, und selbst kleine Ankündigunen sorgfältig ausarbeiten, derart, dass eine korrekte übertragung der Informationen ermutigt wird. Insbesondere Nachrichten von denen Sie erwarten, dass sie zitiert werden sollten einen klaren für die Zitierung gedachten Anteil haben, genau so, als ob Sie eine formale Pressemitteilung schreiben würden. Zum Beispiel:
Nur eine Information über den aktuellen Stand: Wir planen die Version 2.0 von Scanley mitte August 2005 zu veröffentlichen. Sie können immer http://www.scanley.org/status.html auf Aktuelisierungen überprüfen. Die große neue Funtion wird die Suche mit Regulären Ausdrücken sein.
Andere neue Funktionen sind unter anderem: ... Es wird auch verschiedene Bugfixes geben, unter anderem: ...
Der erste Absatz ist kurz, gibt die zwei wichtigsten Informationen (Datum der Veröffentlichung und die wichtige neue Funktion), und eine URL die man für weitere Nachrichten besuchen kann. Wenn dieser Absatz das einzige ist, was über den Bildschirm von jemanden läuft, sind Sie immer noch auf einem guten Weg. Die übrige Email könnte verloren gehen ohne das wesentlich am Ihnalt zu beeinflussen. Manchmal werden Leute sowieso auf die ganze Email verlinken, aber genau so oft, werden Sie nur einen kleinen Teil zitieren. Wenn man letztere Möglichkeit bedenkt, können Sie es ihnen auch genau so gut einfach machen, und bei dem Geschäft etwas Einfuss darüber haben, was zitiert wird.
Eine Sicherheitslücke zu handhaben ist anders, als jede andere Art von Bug Meldung zu handhaben. Bei freier Software, ist es fast schon eine religiöse Überzeugung alles offen zu machen. Jeder Schritt der im Ablauf der normalen Bug handhabung ist für alle sichtbar, denen es interesiert: Das Eintreffen einer ersten Meldung, die darauf folgende Diskussion, und die letztendliche Behebung.
Sicherheitslücken sind anders. Sie können die Daten und möglicherweise die Rechner von Nutzer kompromitieren. Solch ein Problem offen zu Diskutieren käme gleich mit der Bewerbung seine Existenz an die ganze Welt—inklusive alle Parteien die vielleicht einen Böswilligen Nutzen aus dem Bug ziehen könnten. Selbst den Fix zu Commiten, kündigt effektiv die Existenz des Bugs an(es gibt potentielle Angreifer, welche die commit Kommentare von öffentlichen Projekten verfolgen, systematisch auf der Suche nach Änderungen, die auf Sicherheitsprobleme in dem noch nicht geänderten Code hinweisen). Die meißten Projekte haben sich auf ungefär die gleichen Schritte festgelegt, um diesen Konflikt zwischen Offenheit und Geheimhaltung zu handhaben, basierend auf folgende Richtlinien:
Reden Sie nicht öffentlich über den Bug bis ein Fix verfügbar ist; stellen Sie dann den Fix zu genau der selben Zeit zur Verfügung wie Sie den Bug bekanntgeben.
Denken Sie sich diesen Fix so schnell wie möglich aus—insbesondere wenn jemand von außerhalb des Projekts den Bug gemeldet hat, denn dann wissen Sie, dass es zumindest eine Person außerhalb des Projekts gibt, der in der Lage ist die Lücke auszunutzen.
In der Praxis, führen diese Prinzipien zu einer ziemlich standardisierte reihe an Schritten, welche in den Abschnitten weiter unten beschrieben werden.
Ein Projekt muss offensichtlich die Möglichkeit habem Meldungen über Sicherheitslücken von jedem zu bekommen. Die gewöhnlichen Adressen für Bug Meldungen reichen aber nicht aus, da sie auch von jedem beobachtet werden können. Führen Sie desshalb einen getrennten Email Verteiler um Bug Meldungen über Sicherheitslücken zu bekommen. Dieser Email Verteiler darf keine öffentlich zugänglichen Archive haben, und seine Anmeldungen müssen strengstens überwacht werden—nur langjährige, vertrauenswürdige Entwickler dürfen auf den Verteiler sein. Wenn Sie eine formale Definition darüber haben wollen was "vertrauenswürdig" ist, können Sie "jeder der seit zwei oder mehr Jahren commit Zugriff hat" verwenden, um Bevorzugung zu vermeiden. Das ist die Gruppe die Sicherheitslücken handhaben wird.
Im Idealfallm, sollte der Sicherheits Verteiler nicht vor Spam geschützt oder moferiert werden, da Sie nicht wollen, dass eine wichtige Meldung gefiltert oder verzögert wird, nur weil an dem Wochenende keine Moderatoren online waren. Wenn Sie doch Software zum automatischen Schutz vor Spam benutzen, versuchen Sie es mit einer hohen Toleranz zu konfigurieren; es ist besser ein paar Spam Emails durchkommen zu lassen, als eine Meldung zu verpassen. Damit der Verteiler effektiv ist, müssen Sie natürlich seine Adresse bewerben; in anbetracht, dass er nicht moderiert wird, wenn überhaupt, nur leicht vor Spam geschützt wird, versuchen Sie nie seine Adresse ohne irgend eine Art verschleierung der Adresse zu verbreiten, wie in „Verschleierung von Adressen im Archiv“ im Kapitel Kapitel 3, Technische Infrastruktur beschrieben. Glücklicherweise, muss die Verschleierung der Adresse sie nicht unbedingt unleserlich machen; siehe http://subversion.tigris.org/security.html, und schauen Sie sich den HTML Quellcode für die Seite als Beispiel an.
Was macht der sicherheits Verteiler also wenn es eine Meldung bekommt? Die erste Aufgabe ist zu evaluieren wie schwerwiegend und dringend es ist:
Wie ernst ist die Lücke? Erlaubt es einen böswilligen Angreifer den Computer von jemanden der Ihre Software benutzt zu übernehmen? Oder gibt es lediglich Informationen darüber, wie groß manche ihrer Dateien sind?
Wie leicht ist es die Lücke auszunutzen? Kann ein Angriff automatisiert werden, oder erfordert es Wissen über bestimmte Umstände, wohlbegründete Vermutungen und Glück?
Wer hat Ihnen das Problem gemeldet? Die Antwort auf diese Frage ändert natürlich nichts an der Natur der Lücke, aber es gibt Ihnen eine Idee davon, wie viele andere darüber bescheid wissen könnten. Wenn die Meldung von einem der eigenen Mitglieder des Projekts kommt, können Sie es etwas gelassener nehmen (aber nur ein bisschen), da Sie ihnen Vertrauen können, dass sie es keinen anderen gesagt haben. Wenn es andereseits in einer Email von anonymer14@globalehacker.net kam, dann sollten Sie lieber so schnell wie möglich etwas unternehmen. Die Person hat Ihnen einen Gefallen getan, indem sie Ihnen überhaupt über das Problem informiert hat, aber Sie haben keine Ahnung wie viele weitere sie darüber bescheid gesagt hat, oder wie lange sie warten wird, vor sie die schwachstelle in einem laufenden System ausnutzen wird.
Man merke an, dass die Unteschiede von denen wir hier reden oft nur eine enge Spanne zwischen dringend und extrem dringend ist. Selbst wenn die Meldung von einer bekannten, wohl gesinnten Quelle kommt, könnte es immer noch andere im Netz geben, die diesen Bug schon vor langem entdeckt haben, und es nur nicht gemeldet haben. Der einzige Fall bei dem es nicht dringen ist, ist wenn der Bug von sich aus die Sicherheit nicht ernsthaft Kompromitiert.
Das "anonyer@globalehacker.net" Beispiel ist im übrigen nicht schertzhaft gemeint. Es kann durchaus sein, dass Sie Bug Meldungen von anonymen Personen bekommen, die mit Ihren Worten nie ganz klar stellen ob sie auf Ihrer Seite sind oder nicht. Es macht keinen Unterschied: Wenn Sie eine Sicherheitslücke an Sie gemeldet haben, werden sie das gefühl haben Ihenen eine Gefallen getan zu haben, und Sie sollten entsprechend antworten. Danken Sie ihnen für die Meldung, geben Sie ein Datum an vor dem Sie vorhaben einen öffentlichen Fix freizugeben, und halten Sie sie den Kontakt. Manchmal werden sie Ihnen ein Datum geben—das heißt, eine implizite Drohung den Bug an einem bestimmten Datum bekannt zu geben, ob Sie bereit sind oder nicht. Das mag sich nach einschüchterndem Machtspiel anfühlen, aber es ist wahrscheinlich eher eine vorsorgliche Maßnahme die sich aus vergangener Enttäschung mit nicht reagierenden Software Produzenten, welche die Sicherheits Meldungen nicht ernst genug nahmen. In jedem Fall, können Sie es sich nicht leisten, dieser Person auf die Nerven zu gehen. Wenn der Bug ernst ist, hat er schließlich Wissen, welches Ihren Nutzern ernste Probleme bereiten könnte. Behandeln Sie solche Personen gut, und hoffen Sie darauf, dass sie auch gut behandelt werden.
Eine weitere Person die häufig Bugs meldet, ist der Sicherheits Profi, jemand der davon lebt Code zu überprüfen und sich auf den laufenden über die neusten Software Schwachstellen hällt. Diese Leute haben für gewöhnlich erfahrung mit beiden Seiten des Zauns—sie haben sowohl Meldungen gemacht als auch bekommen, wahrscheinlich mehr als die meisten in Ihrem Projekt. Auch sie werden wahrscheinlich ein Frist setzen, vor dem eine Lücke geschlossen werden muss, vor sie an die öffentlichkeit gehen. Die Frist mag etwas verhandelbar sei, das hängt aber vom Meldenden ab; Fristen sind under sicherheits Experten anerkannt geworden als so ziemlich die einzige Möglichkeit zuverlässig Organisationen dazu zu bringen sich um Sicherheitsprobleme zeitnahe zu kömmern. Behandeln Sie die Frist also nicht als unhöflich,; es ist eine altehrwürdige Tradition und es gibt gute Gründe dafür.
Sobald Sie wissen wie schwehrwiegend und dringend eine Lücke ist, können Sie sich an den Fix zu schaffen machen. Es gibt manchmal einen Kompromiss zwischen einen eleganten Fix und es schnell zu machen; das ist der Grund warum Sie sich vorher über die Dringlichkeit einigen müssen vor Sie anfangen. Halten Sie die Diskussion über den Fix natürlich auf die Mitglieder des sicherheits Verteilers beschränkt, sowie auf den ursprünglichen Meldenden (wenn die beteiligt sein möchte) und solche Entwickler die aus technischen Gründen herangezogen werden müssen.
Committen Sie den Fix nicht zu der Repository. Halten Sie es als Patch bereit, bis zu dem Datum der Bekanntgabe. Wenn Sie es committen würden, selbst mit einem unscheinbaren Kommentar, könnte jemand die Änderung bemerken und verstehen. Sie wissen nie wer Ihre Repository m Auge behällt und warum sie vielleicht interesiert sein könnten. Commit Emails abzuschalten würde nichts bringen; erstens weil sich die Lücke in der Reihe der Emails verdächtig aussehen würde, und die Daten wären immer noch in der Repository. Machen Sie einfach die ganze Entwicklung in einem Patch und halten Sie ihn an einem private Ort, vielleicht eine getrennte private Repository welche nur denjenigen bekannt ist, die schon über den Bug bescheid wissen. (Wenn Sie eine dezentralisierte Versionsverwaltung benutzen wie Arch oder SVK, können Sie die Arbeit mit kompletter Versionsverwaltung machen und diese Repository einfach den Zugriff für Ausenstehende ausschließen.)
Sie haben vielleicht eine CAN Nummer oder eine CVE Nummer im Zusammenhang mit Sicherheitsproblemen gesehen. Diese Zahlen sehen für gewöhnlich zum Beispiel so "CAN-2004-0397" oder so "CVE-2002-0092" aus.
Beide Zahlenarten representieren den gleichen Entitätstyp: Ein Eintrag in der Liste von "Common Vulnerabilities and Exposures" (de. "Verbreitete Schwachstellen und Aufdeckungen") die bei http://cve.mitre.org/ gepflegt wird. Der Sinn dieser Liste ist es standardisierte Namen für alle bekannte Sicherheitsprobleme zur verfügung zu stellen, damit jeder einen eindeutigen, kanonischen Namen bei der Diskussion eines solchen hat, und einen Zentralen Ort zu haben, um mehr Informationen zu bekommen. Der einzige Unterschied zwischen einer "CAN" Nummer und einer "CVE" Nummer ist, dass erstere einen Kandidaten Eintrag representiert, welches noch nichtbestätigt wurde, und letzteres einen bestätigten Eintrag representiert. Beide Typen sind jedoch für die Öffentlichkeit sichtbar, und die Nummer für einen Eintrag ändert sich nicht, wenn Sie bestätigt wird—der "CAN" Prefix wird einfach mit "CVE" ersetzt.
Ein CAN/CVE Eintrag entällt selber nicht eine vollständige Beschreibung von dem Bug und wie Sie sich vor ihm schützen. Statt dessen, enthällt es eine kurze Beschreibung und eine Liste von Verweisen auf externe Resourcen (wie die Archive des Verteilers) wo Leute detalliertere Infomationen nachschlagen können. Der wirkliche Sinn von http://cve.mitre.org/ ist einen wohl organisierten Ort zu haben, in dem jede Schwachstelle einen Namen haben und eine klare Route zu weiteren Daten haben kann. Siehe http://cve.mitre.org/cgi-bin/cvename.cgi?name=2002-0092 als Beispiel für einen Eintrag. Beachten Sie, dass Verweise sehr kurz gehalten sein können, mit Quellen die als kryptische Abkürzungen erscheinen. Ein Schlüssel zu diesen Abkürzungen befindet sich bei http://cve.mitre.org/cve/refs/refkey.html.
Wenn Ihre Schwachstelle die Kriterien für ein CVE erfüllt, kann es sein, dass Sie dafür eine CAN Nummer bekommen wollen. Der Prozess dafür ist absichtlich umständlich gehalten: Im Prinzip, müssen Sie jemanden kenne, oder jemanen kennen der jemand anderes kennt. Das ist nicht so verrückt wie es sich anhören mag. Damit die CVE Redaktion es vermeiden kann von unechten oder schlecht geschriebenen Vorschlägen überweltigt wird, nehmen Sie nur Vorschläge von Quellen, die sie bereits kennen und vertrauen. Damit Ihre Lücke in der Liste aufgenommen wird, müssen Sie desshalb einen Pfad von Bekanntschaften von Ihrem Projekt hin zu der CVE Redaktion finden. Fragen Sie bei Ihren Entwicklern nach; einer von Ihnen wird wahrscheinlich jemand anderen kennen der bereits durch den CAN Prozess gelaufen ist, oder der jemand kennt der es gemacht hat, usw. Der Vorteil dieser Methode ist auch, das irgendwo in der Kette, jemand sein kann der genug weiß, um Ihnen sagen zu können, dass a) es nicht als Lücke oder Aufdeckung nach den Kriterien von MITRE zählen würde, es also keinen Sinn hat es vorzuschlagen, oder b) dass die Lücke bereits eine CAN oder CVE Nummer hat. Letzteres kann passieren, wenn der Bug bereits auf einer andern Liste für Sicherheitsberatung veröffentlicht wurde, zum Beispiel bei http://www.cert.org/ oder auf dem BugTraq Email Verteiler bei http://www.securityfocus.com/. (Wenn das passiert ist, ohne das Ihr Projekt davon erfahren hat, dann sollten Sie sich sorgen machen, was noch möglicherweise abläuft worüber Sie nichts wissen.)
Wenn Sie eine CAN/CVE Nummer überhaupt bekommen, werden Sie es wahrscheinlich im frühen Stadium Ihrer Bug Untersuchung bekommen, damit alle weiteren Kommunikationen sich auf diese Nummer beziehen können. CAN Einträge stehen unter einem Embargo bis zu dem Veröffentlichungsdatum; Der Eintrag wird existieren als leerer Platzhalter (damit Sie den Namen nicht verlieren), es wird aber keine Informationen über die Lücke enthüllen, bist zu dem Datum an dem Sie den Bug und den Fix bekanntgeben.
Weitere Informatione über den CAN/CVE Prozess kann bei http://cve.mitre.org/about/candidates.html gefunden werden, und eine besonders klare Darstellung von dem Nutzen eines Open Source Projekts der CAN/CVE Nummern befindet sich auf http://www.debian.org/security/cve-compatibility.
Sobald Ihr Sicherheitsteam (also die Entwickler die auf dem sicherheits Verteiler sind, oder die zu einer bestimmten Meldung herangezogen wurden) eine Fix bereit hat, müssen Sie entscheiden wie Sie es Verbreiten wollen.
Wenn Sie den Fix einfach zu Ihrer Repository committen, oder sonstwie der Welt bekanntgeben, zwingen Sie effektiv alle die Ihre Software benutzen sofort zu aktuelisieren oder das Risiko einzugehen, gehacked zu werden. Es ist deshalb manchmal angemessen für bestimmte Nutzer eine Vorankündigung zu machen. Das gilt insbesondere bei client/server Software, bei dem es wenige wohl bekannte Server geben kann, die verlockende Ziele für Angreifer sind. Die Administratoren dieser Server wären dankbar darüber einen zusetzlichen Tag oder zwei für die Aktuelisierung zu haben, damit Sie bereits geschützt sind, wenn die Lücke öffentlich bekannt wird.
Vorankündigung bedeutet lediglich eine Email an diese Administratoren zu senden, vor dem Veröffentlichungsdatum, in dem Sie ihnen über die Lücke bescheid geben und wie sie es beheben können. Sie sollten eine Vorankündigung nur an Personen schicken, die Sie diese diskrete Information anvertrauen können. Die Qualifikation um eine Vorankündigung zu erhalten hat also zwei Bedingungnen: Der Empfänger muss eine große Instalation im Betrieb haben, wichtige Server bei dem eine Kompromitierung etwas ernstes wäre, und der Empfänger muss jemanden sein, der sich über das Sicherheitsproblem vor dem Veröffentlichungsdatum verplappert.
Senden Sie jede Email mit einer Vorankündigung einzeln (eines nach dem anderen) an jedem Empfänger. Senden Sie nicht an die komplette Liste von Empfängern auf ein mal, da sie dann ihre gegenseitigen Namen sehen würden—was zur Folge hat, dass Sie im Grunde genommen jedem Empfänger über die Tatsache aufmerksam machen, dass jeder andere Empfänger möglicherweise die Sicherheitslücke auf seinem Empfänger hat. Es an alle mittels einem blinden CC (BCC) zu schicken ist auch keine gute Lösung, da manche Administratoren ihre Email Konten mit Spam Filtern schützen, die entweder BCC Emails blockieren, oder ihre Priorität reduzieren, da heutzutage sehr viel Spam mit BCC verschickt wird.
Hier ist ein Beispiel Email für eine Vorankündigung:
Von: Ihr Name Hier An: admin@grosser-bekannter-server.de Antwort-an: Ihr Name Hier (nicht die Adresse des Sicherheits Verteilers) Betreff: Vertrauliche Meldung einer Scanly Sicherheitslücke. Diese Email ist eine vertrauliche Vorankündigung einer Sicherheitsmeldung in dem Scanley Server. Bitte leiten Sie keinen Teil dieser Email an irgend jemand weiter. Die öffentliche Bekanntgabe wird nicht vor dem 19ten Mai stattfinden, und wir würden die Information gerne bis dann unter Verschluss halten. Sie erhalten diese Email da (wir denken, dass) Sie einen Scanley Server betreiben, und wir ihn lieber gepatched hätten, vor die Sicherheitslücke am 19ten Mai bekannt gegeben wird. Verweise: =========== CAN-2004-1771: Scanley Speicher überlauf in Abfragen Sicherheitslücke: ============== Der Server kann dazu gebracht werden beliebige Befehle auszuführen, wenn die Locale des Servers falsch konfiguriert ist und der Client eine fehlerhafte Abfrage macht. Sicherheitsgrad: ========= Sehr ernst, kann die Ausführung von beliebigen Code auf dem Server zur Folge haben. Provisorische Lösungen: ============ Die 'verarbeitung-natürlicher-sprache' Einstellung in der scanley.conf auf 'aus' zu stellen, schließt die Sicherheitslücke. Patch: ====== Der folgende Patch gilt für Scanley 3.0, 3.1, und 3.2. Eine neu Version (Scanley 3.2.1) wird am oder kurz vor dem 19ten Mai veröffentlicht werden, damit es zur gleichen Zeit verfügbar istm wie die Bekanntgabe der Lücke. Sie können dem Patch jetzt anwenden oder einfach auf die neue Version warten. Der einzige Unterschied zwischen 3.2 und 3.2.1 wird diese Patch sein. [...Patch folgt hier...]
Wenn Sie eine CAN Nummer habe, geben Sie sie bei der Vorankündigung mit an (wie oben gezeigt), selbst wenn die Information unter Verschluss steht und die MITRE Seite desshalb leer sein wird. Die CAN Nummer erlaubt es dem Empfänger mit sicherheit zu wissen, dass der Bug über den sie eine Vorankündigung bekommen haben, der gleiche ist von dem sie später durch öffentliche Kanäle erfahren, also müssen sie sich keine Sorgen darüber machen, ob weitere Schritte notwendig sind, was genau der Sinn einer CAN/CVE Nummer ist.
Der letzte Schritt bei der Handhabung einer Sicherheitslücke, ist den fix öffentlich zu verteilen. Sie sollten in einer einzigen, umfangreichen Meldung, das Problem beschreiben, die CAN/CVE Nummer angeben, falls vorhanden, beschreiben wie das Problem zu umgehen ist, und wie es permanent 'gefixed' werden kann. 'Fix' bedeutet für gewöhnlich auf eine neuere Version der Software zu aktuelisieren, obwohl es manchmal die Anwendung von einem Patch bedeuten kann, insbesondere wenn die Software sowieso meistens vom Quellcode Format aus betrieben wird. Wenn Sie doch eine neue Version machen, sollte es sich von einer existierenden Version durch genau diesen sicherheits-Patch unterscheiden. So können konservative Administratoren, aktuelisieren, ohne sich sorgen zu machen, was sie noch beeinflussen könnten; sie müssen sich also keine Sorgen über zukünftige Upgrades machen, da der sicherheits Patch als Folge in allen zukünftigen Versionen enthalten sein wird. (Details der Abläufe für neue Versionen werden in „Sicherheits-Versionen“ im Kapitel Kapitel 7, Paket Erstellung, Veröffentlichung, und Tägliche Entwicklung behandelt.)
Ob der öffentliche Fix eine neue Version zur Folge hat oder nicht, machen Sie die Meldung mit ungefähr der der gleichen Priorität wie Sie eine neue Version machen würden: Senden Sie eine Email an den announce Verteiler des Projekts, machen Sie eine neue Pressemitteilung, aktuelisieren Sie den Freshmeat Eintrag, usw. Während Sie nie versuchen sollten, die Existenz einer Sicherheitslücke herunterzuspielen, aus Sorge um den Ruf des Projekts, können Sie durchaus den Ton und die Gewichtung der Sicherheitsmeldung anpassen, um den Ernst des Problems zu entsprechen. Wenn die Sicherheitslücke nur eine kleine Offenlegung von Informationen ist, nicht eine Lücke die es erlaubt den kompletten Computer des Anwenders zu übernehmen, mag es keinen all zu großen Wirbel gerechtfertigen. Sie können sich sogar Entscheiden den announce Verteiler damit abzulenken. Wenn das Projekt schließlich jedes mal Wolf schreit, werden sich die Nutzer denken, dass die Software weniger sicher ist, als das tatsächlich der Fall ist, und es möglicherweise nicht glauben wenn Sie wirklich ein riesiges Problem ankündigen müssen. Siehe http://cve.mitre.org/about/terminology.html als eine gute Einführung zu dem Problem der Beurteilung wie schwerwiegend eine Sicherheitslück ist.
Im allgemeinen, wenn Sie sich nicht sicher sind, wie Sie ein Sicherheitsproblem behandeln sollen, suchen Sie sich jemand erfahrenes und reden Sie darüber. Lücken zu handhaben und zu bewerten ist größtenteils eine angelernte Fähigkeit und es ist leiche die ersten paar Male Fehler zu machen.