Re: Please review german translation of the security team FAQ
Liebe Kollegen,
On Sun, Mar 06, 2005 at 01:08:33PM +0100, Jens Seidel wrote:
> On Sun, Mar 06, 2005 at 11:10:39AM +0100, Marc Haber wrote:
> > Please review the translation.
> >
> > I'm willing to help. What can I do?
>
> Ganz einfach: Besorge dir den Quellcode aus dem Webseiten-CVS z.B.
> über
> http://cvs.debian.org/webwml/german/security/?diff_format=h&cvsroot=webwml
> und schicke uns einen Patch.
Done. Patch und neues Dokument hängen an. Von der ursprünglichen
Version ist nicht so viel übrig geblieben, und an einigen Stellen habe
ich mir sicher zu viel Freiheit vom Original genommen.
Grüße
Marc
Bitte Cc:, ich bin nicht subscribed.
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
#use wml::debian::template title="Debian Security-FAQ"
#use wml::debian::translation-check translation="1.46"
# $Id: faq.wml,v 1.61 2005/03/13 16:01:32 jseidel Exp $
# Translation: Marc Haber <mh+debian-packages@zugschlus.de> nach Vorarbeit von Gerfried Fuchs <alfie@debian.org>
#include "$(ENGLISHDIR)/security/faq.inc"
<p>Dieses Dokument enthält Antworten auf die folgenden häufig gestellte Fragen.</p>
<maketoc>
<toc-add-entry name=signature>Die Signatur eurer Advisories ist falsch!</toc-add-entry>
<p>A: Sehr wahrscheinlich handelt es sich um ein Problem auf Ihrer Seite. Es ist
technisch sichergestellt, dass nur Nachrichten mit der korrekten Signatur eines
Mitglieds des Security-Teams auf der Mailingliste
<a href="http://lists.debian.org/debian-security-announce/";>\
debian-security-announce</a> erscheinen können.</p>
<p>Die häufigste Ursache dafür sind zumeist durch ein Mail-Programm auf Ihrer
Seite durchgefährte leichte Änderungen an der Nachricht, durch die die Signatur
ungültig wird. Versichern Sie sich, dass Ihre Software keine MIME-Codierung oder
-Decodierung durchführt und auch keine Tabulator/Leerzeichen-Konvertierungen vornimmt.</p>
<p>Bekannte Übeltäter sind fetchmail (mit der Option mimedecode),
formail (von procmail 3.14) und evolution.</p>
<toc-add-entry name="handling">Wie werden sicherheitsrelevante Schwachstellen in Debian gehandhabt?</toc-add-entry>
<p>A: Wenn das Security-Team auf eine Schwachstelle aufmerksam wird, prüfen
dessen Mitglieder den Einfluss der Schwachstelle auf das Stable-Release von
Debian. So wird zum Beispiel ermittelt, ob die Schwachstelle überhaupt in
Debian Stable vorliegt oder nicht. Wenn unser System verwundbar ist, beheben wir die
Schwachstelle. Wir nehmen dann Kontakt mit dem Paketbetreuer auf,
wenn dieser sich noch nicht selbst mit dem Security-Team in Verbindung gesetzt hat.
Es werden neue Pakete vorbereitet, die nach einem Test dann auf allen
Stable-Architekturen übersetzt und anschließend in das Debian-Archiv geladen werden.
Nachdem dies alles geschehen ist, wird als letzter Schritt ein Advisory veröffentlicht.</p>
<toc-add-entry name=oldversion>Wieso basteln Sie an einer alten Version des
Pakets herum?</toc-add-entry>
<p>Unsere wichtigste Regel beim Erstellen eines neuen Pakets zur Behebung einer
Schwachstelle ist, so wenig Änderungen wie möglich vorzunehmen.
Unsere Benutzer und Entwickler vertrauen darauf, dass sich das Verhalten eines
Release nach dessen Freigabe nicht mehr ändert. Jede Änderung, die wir
durchführen, kann möglicherweise Systeme zerstören. Dies gilt
insbesondere für Bibliotheken: Es muss darauf geachtet werden, dass sich das
Anwendungs-Programm-Interface (API) oder Anwendungs-Binär-Interface (ABI)
niemals ändert, egal wie klein die Änderung ist.</p>
<p>Dies bedeutet, dass das Umsteigen auf eine neue Upstream-Version keine gute
Lösung ist und stattdessen die notwendigen Änderungen zurückportiert werden
müssen. Wenn das Debian Security-Team Unterstützung benötigt, sind die
Upstream-Autors üblicherweise hilsbereit.</p>
<p>In einigen Fällen - zum Beispiel, wenn ein großer Teil des Quellcodes modifiziert
oder neu geschrieben wurde - ist es nicht möglich, einen Patch zur Entfernung einer
Schwachstelle zurückzuportieren. In diesem Fall kann es notwendig werden, doch auf
eine neue Upstream-Version umzusteigen. Dies muss aber in jedem Fall zuvor mit dem
Sicherheits-Team koordiniert werden.</p>
<toc-add-entry name=policy>Was sind die Anforderungen für ein Paket mit einer security-relevanten Änderung für das Erscheinen auf security.debian.org?</toc-add-entry>
<p>A: Nur wenn ein neues Paket eine sicherheitsrelevante Schwachstelle behebt, kann es
dem Archiv auf security.debian.org hinzugefügt wird. Sonst nicht.
Dabei kommt es nicht auf die Schwere der Schwachstelle an. Üblicherweise bereitet das
Security-Team die Pakete gemeinsam mit dem Paketbetreuer vor. Auch sehr kleine
sicherheitsrelevante Patches können ein Grund für die Aufnahme nach security.debian.org
sein, wenn eine vertrauenswürdige Person das Problem analysiert, alle benötigten Pakete
übersetzt und diese an das Sicherheits-Team übermittelt. Weitere Informationen sind
im Rest dieses Dokuments enthalten.</p>
<p>Sicherheits-Updates dienen dem Zweck der Behebung von sicherheitsrelevanten
Schwachstellen. Sie sind keine Methode, um zusätzliche
Änderungen in das Stable-Release einzubringen, ohne diese die normale
Point-Release-Prozedur durchmachen zu lassen.</p>
<toc-add-entry name=version>Laut der Versionsnummer eines Pakets habe ich immer
noch eine verwundbare Version!</toc-add-entry>
<p>A: Anstatt auf eine neue Upstream-Version zu aktualisieren, portieren wir die
Security-Fixes auf die Version zurück, die mit dem Stable-Release
ausgeliefert wurde. Wir tun dies, um zu garantieren, dass die durch das das
Security-Update eingeführten Änderungen so gering wie möglich sind. Somit wird
sichergestellt, dass sich beim Security-Update nichts ändert und keine unerwarteten Probleme
verursacht werden. Wenn Sie wissen wollen, ob Sie eine fehlerbereinigte Version eines
Paketes verwenden, so lesen Sie in der changelog-Datei des Paketes nach, oder vergleichen
die exakte Versionsnummer mit der im Debian-Advisory referenzierten Version.</p>
<toc-add-entry name=testing>Wie wird die Security für <tt>Testing</tt> und
<tt>Unstable</tt> gehandhabt?</toc-add-entry>
<p>A: Die kurze Antwort ist: gar nicht. Testing und Unstable ändern sich ständig,
und das Security-Team hat nicht die für eine Unterstützung notwendigen Ressourcen.
Wenn Sie einen
sicheren (und stabilen) Rechner haben wollen, wird es Ihnen dringend empfohlen,
bei Stable zu bleiben. Die Mitglieder des Security-Teams und die
Package-Maintainer werden jedoch versuchen, die
Probleme in Testing und Unstable zu beheben, nachdem Sie im Stable-Release
behoben sind.</p>
<toc-add-entry name=testing-security>Wie bekommt <tt>Testing</tt>
Security-Updates?</toc-add-entry>
<p>A: Security-Updates gelangen über <tt>Unstable</tt> in die
<tt>Testing</tt>-Distribution. Pakete mit sicherheitsrelevanten Änderungen
werden mit Priority: high in das Archiv geladen. Dadurch verringert sich die
Wartezeit bis zur Migration nach <tt>Testing</tt> auf zwei Tage.
Nach dieser Zeit gelangen die Pakete automatisch
nach <tt>Testing</tt>, wenn sie für alle Architekturen gebaut worden
sind und ihre Abhängigkeiten in <tt>Testing</tt> erfüllt werden
können.</p>
<toc-add-entry name=contrib>Wie wird die Security für <tt>contrib</tt> und
<tt>non-free</tt> gehandhabt?</toc-add-entry>
<p>A: Die kurze Antwort ist: gar nicht. Contrib und non-free sind nicht
offizieller Bestandteil der Debian-Distribution, werden nicht released
und erhalten keine Unterstützung vom Security-Team. Einige Pakete aus
non-free sind nur ohne Quellcode oder unter einer die Verteilung von
geänderten Versionen nicht erlaubenden Lizenz erhältlich. In diesen Fällen ist
es überhaupt nicht möglich, sicherheitsrelevante Schwachstellen zu beheben.
Falls es möglich ist, das Problem zu beheben und der Paketbetreuer oder
jemand anderes korrekte, aktualisierte Pakete zur Verfügung stellt, wird
das Security-Team diese normalerweise bearbeiten und ein Advisory
veröffentlichen.</p>
<toc-add-entry name=mirror>Wieso gibt es keine offiziellen Mirror-Server für
security.debian.org?</toc-add-entry>
<p>A: Der Zweck von security.debian.org ist es, Security-Updates so
schnell und einfach wie möglich zur Verfügung zu stellen.</p>
<p>Inoffizielle Mirrors sind in aller Regel nicht notwendig, erhöhen die Komplexität
und können Probleme verursachen, wenn sie
nicht aktuell sind. Offizielle Mirrors sind jedoch für die Zukunft geplant.</p>
<toc-add-entry name=missing>Ich habe DSA 100 und DSA 102 gesehen, wo ist aber
DSA 101?</toc-add-entry>
<p>A: Einige Distributoren (hauptsächlich von GNU/Linux, aber auch von
BSD-Derivaten)
koordinieren die Herausgabe von Security-Advisories für Schwachstellen und
stimmen einem gemeinsamen Zeitplan zu. Damit soll ermöglicht werden, dass alle
Distributoren ihre Advisories zeitgleich veröffentlichen, um die Benachteiligung
einzelner, langsamerer Distributoren zu verringern (z.B. falls
der Distributor längere Qualitätssicherungs-Tests für die Pakete durchführt,
oder mehrere Architekturen bzw. Binär-Distributionen unterstützt). Unser
eigenes Security-Team bereitet oft Advisories vor, ohne sie sofort zu veröffentlichen.
Muss ein anderes Advisory vorgezogen werden, bleibt die für das verzögerte Advisory
bereits reservierte Nummer temporär unvergeben.</p>
<toc-add-entry name=contact>Wie erreiche ich das
Security-Team?</toc-add-entry>
<p>A: Sicherheitsrelevante Informationen können Sie per E-Mail an security@debian.org oder
team@security.debian.org senden. Unter beiden Adressen
erreichen Sie die Mitglieder des Security-Teams.</p>
<p>Falls gewünscht, können
die Mails an den GPG-Schlüssel des Debian-Security-Teams (Schlüssel-ID
<a href="http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&exact=on&search=0x363CCD95";>\
0x363CCD95</a>) verschlüsselt werden. Bitte lesen Sie auch die Informationen zu den
<a href="keys.txt">PGP/GPG-Schlüsseln des Sicherheits-Teams</a>.
</p>
<toc-add-entry name=discover>Ich glaube, ich habe ein Sicherheitsproblem
entdeckt. Was soll ich tun?</toc-add-entry>
<p>A: Wenn Sie von einem Sicherheitsproblem erfahren, setzen Sie sich bitte immer
mit dem Security-Team in Verbindung - unabhängig davon, ob die Schwachstelle
in Ihren eigenen Paketen oder in denen eines anderen Entwicklers vorliegt.
Wenn das Debian-Sicherheits-Team die
Schwachstelle bestätigt und andere Distributoren höchstwahrscheinlich
ebenfalls davon betroffen sind, wird es sich um die Weiterleitung kümmern.
Wenn die Schwachstelle noch nicht öffentlich bekannt ist, wird es
versuchen, die Security-Advisories mit den anderen Distributoren zu koordinieren, damit
alle wichtigen Distributionen synchron sind.</p>
<p><a href="#care">Weitere Informationen für Debian-Entwickler finden Sie weiter unten.</a></p>
<toc-add-entry name=care>Was soll ich bei einem Sicherheitsproblem in einem
meiner Pakete tun?</toc-add-entry>
<p>A: Wenn Sie von einem Sicherheitsproblem erfahren, setzen Sie sich bitte immer
mit dem Security-Team in Verbindung - unabhängig davon, ob die Schwachstelle
in Ihren eigenen Paketen oder in denen eines anderen Entwicklers vorliegt.
Sie
können es mit einer E-Mail an team@security.debian.org erreichen. Die
Mitglieder des Teams
haben die Übersicht über offene Sicherheitsprobleme, können den
Maintainern mit Sicherheitsproblemen helfen oder die Probleme selbst beheben
und sind verantwortlich für das Versenden der Advisories und die
Betreuung von security.debian.org.</p>
<p>In der <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
Entwickler-Referenz</a> erhalten Sie vollständige Informationen darüber, was zu
tun ist.</p>
<p>Es ist im Speziellen wichtig, dass Sie ohne Zustimmung des Security-Teams
keine Pakete in eine andere Distribution außer Unstable hochladen, da
Sie mit dem Übergehen des Security-Teams Verwirrung stiften und weiteren Aufwand
verursachen.</p>
<toc-add-entry name=enofile>Ich habe versucht, ein Paket herunterzuladen, das
in einem der Advisories aufgeführt war, aber ich bekomme dabei
einen `file not found' Fehler.</toc-add-entry>
<p>A: Immer, wenn eine neuere fehlerbereinigte Version ein älteres Paket auf
security.debian.org ersetzt, wird das ältere Paket bei der Installation
des neuen gelöscht. Daher erhalten Sie
diesen `file not found' Fehler. Wir wollen Pakete mit bekannten
Sicherheitslücken so schnell wie möglich aus der Distribution nehmen.</p>
<p>Bitte benutzen Sie immer die im neuesten Advisory genannten Pakete. Die Advisories
erhalten Sie über die Mailingliste
<a href="http://lists.debian.org/debian-security-announce/";>\
debian-security-announce</a>. Wenn Sie <code>apt-get update</code> aufrufen, bevor
Sie updates installieren, ist bei sonst sachgerechter Konfiguration Ihres Systems
sichergestellt, dass Sie die aktuelle Paketversion erhalten.</p>
<toc-add-entry name=upload>Ich habe einen Security-Patch. Kann ich direkt auf
security.debian.org hochladen?</toc-add-entry>
<p>A: Nein, das geht nicht. Das Archiv auf security.debian.org wird vom
Security-Team betreut, das alle Pakete genehmigen muss. Sie sollten
stattdessen Patches oder passende Source-Packages an das Security-Team
unter team@security.debian.org schicken. Diese werden dann nach Prüfung und
eventuell noch notwendigen Änderungen vom Security-Team hochgeladen.</p>
<p>Wenn Sie nicht mit der Vorbereitung von Security-Uploads vertraut sind und sich nicht 100%
sicher sind, dass Ihr Paket in Ordnung ist, verwenden Sie bitte diesen Weg und
laden Sie Ihr Paket nicht direkt in das incoming-Verzeichnis hoch. Das
Sicherheits-Team hat nur beschränkte Möglichkeiten, in einem solchen Fall mit
defekten Paketen umzugehen. Besonders ärgerlich ist es, wenn das eigenmächtig hochgeladene
Paket eine falsche Versionsnummer hat. Es besteht derzeit keine Möglichkeit, derartige
Pakete zurückzuweisen, und der
<acronym lang="en" title="Build Daemon">buildd</acronym> kann durcheinander kommen.
Bitte schicken Sie deswegen im Zweifel lieber eine Mail an das Security-Team, um
den Aufwand niedrig zu halten.</p>
<p>Vollständige Informationen über die Prozesse erhalten Sie in der
<a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
Developer's Reference</a>.</p>
<toc-add-entry name=ppu>Ich habe einen Security-Patch. Kann ich dieses
stattdessen nach proposed-updates hochladen?</toc-add-entry>
<p>A: Technisch gesehen geht das. Bitte unterlassen Sie dies jedoch, da hier
Konfliktpotenzial mit der Arbeit des Sicherheits-Teams besteht. Pakete von
security.debian.org werden automatisch in das proposed-updates-Verzeichnis
kopiert. Falls ein Paket mit der gleichen oder einer höheren Versionsnummer
bereits im Archiv ist, wird die Sicherheitsaktualisierung
vom Archiv-System zurückgewiesen. Auf diese Art wird die Stable-Distribution
die Sicherheitsaktualisierung für dieses Paket nur dann
enthalten, wenn das »falsche« Paket im proposed-updates
Verzeichnis zurückgewiesen wurde. Bitte setzen Sie sich anstelle eines eigenen
Uploads mit dem Sicherheits-Team in Verbindung, fügen Sie alle
Details über die Verwundbarkeit bei und hängen die Quelldateien (d.h.
diff.gz- und dsc-Dateien) an die E-Mail an.</p>
<p>Vollständige Informationen über die Prozesse erhalten Sie in der
<a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
Developer's Reference</a>.</p>
<toc-add-entry name=SecurityUploadQueue>Ich bin ziemlich sicher, dass meine
Pakete in Ordnung sind. Wie kann ich sie hochladen?</toc-add-entry>
<p>A: Wenn Sie sich sehr sicher sind, dass ihre Pakete nichts zerstören, dass
die Versionsnummer sauber ist (z.B. größer als die Version in Stable und kleiner
als die Version in Testing/Unstable), dass Sie bei der Behebung der Schwachstelle
kein Verhalten des Pakets geändert haben, dass Sie es
für die richtige Distribution übersetzt haben (das ist
<code>oldstable-security</code> oder <code>stable-security</code>), dass
das Paket den ursprünglichen Quellcode enthält, falls das Paket neu auf
security.debian.org ist, dass Sie bestätigen können, dass der Patch gegen
die aktuellste Version sauber ist und nur die Schwachstelle
(prüfen Sie mit <code>interdiff -z</code> die
beiden <code>.diff.gz</code>-Dateien) behebt, dass Sie den Patch zumindest
dreimal Korrektur gelesen haben, und dass <code>debdiff</code> keine
Änderungen anzeigt, dürfen Sie die Dateien in das incoming-Verzeichnis
<code>/org/ftp.root/pub/SecurityUploadQueue</code> auf security.debian.org
direkt hochladen. Bitte senden Sie auch eine Benachrichtigung mit allen
Details und Links an team@security.debian.org.</p>
<toc-add-entry name=help>Wie kann ich mit der Security helfen?</toc-add-entry>
<p>A: Bitte überprüfen Sie jedes Problem doppelt, bevor Sie sich an security@debian.org
wenden. Wenn Sie Patches zur Verfügung stellen können,
beschleunigt dies den Prozess erheblich. Bitte senden Sie uns keine Mails
von der bugtraq- und anderen Mailinglisten, da wir diese bereits empfangen.
Teilen Sie uns
stattdessen zusätzliche Informationen zu den Dingen mit, die auf den Mailinglisten
diskutiert wurden.</p>
<toc-add-entry name=proposed-updates>Was umfasst
proposed-updates?</toc-add-entry>
<p>A: Dieses Verzeichnis beinhaltet Pakete, die für die nächste Revision von
Debian Stable vorgeschlagen sind. Wann immer ein Paket von einem
Maintainer für die Stable-Distribution hochgeladen wird, wird dieses
im proposed-updates Verzeichnis abgelegt. Da Stable dafür gedacht ist,
stabil zu sein, werden keine automatischen Updates durchgeführt. Das
Security-Team wird die in den Advisories referenzierten fehlerbereinigte Pakete für
Stable hochladen. Dies werden jedoch zuerst in proposed-updates abgelegt.
Alle paar Monate prüft der Release-Manager für die Stable-Distribution die Liste
der Pakete in
proposed-updates und bewertet, ob ein Paket für Stable geeignet ist
oder nicht. Daraus wird ein neues Point-Release von Stable zusammengestellt
(z.B. 2.2r3 oder 2.2r4). Nicht geeignete Pakete werden zu gegebener Zeit
aus dem proposed-updates-Verzeichnis zurückgewiesen.</p>
<p>Beachten Sie, dass vom Paketbetreuer (nicht vom Security-Team)
hochgeladene Pakete im proposed-updates/ Verzeichnis nicht vom
Security-Team unterstützt werden.</p>
<toc-add-entry name=composing>Wie setzt sich das Security-Team
zusammen?</toc-add-entry>
<p>A: Das Debian-Sicherheits-Team besteht aus <a href="../intro/organization">\
mehreren Mitgliedern und Helfern</a>. Das Security-Team bestimmt seine Mitgliedr
selbst.</p>
<toc-add-entry name=lifespan>Wie lang ist der Zeitraum, in dem Sicherheits-Updates verfügbar sind?</toc-add-entry>
<p>A: Das Security-Team versucht, eine Stable-Distribution für in etwa ein
Jahr zu unterstützen, nachdem die nächste Stable-Distribution freigegeben
wurde; außer, eine weitere Stable-Distribution wird innerhalb dieser
Zeitspanne freigegeben. Die gleichzeitige Unterstützung für zwei Distributionen
ist schon schwierig genug; die Unterstützung dreier Distributionen ist
nicht möglich.</p>
<toc-add-entry name=check>Wie kann ich die Integrität der Pakete prüfen?</toc-add-entry>
<p>A: Dieser Prozess umfasst das Prüfen der Signatur der Release-Datei gegen den
<a href="http://ftp-master.debian.org/ziyi_key_2005.asc";>öffentlichen
Archiv-Schlüssel</a>. Die Release-Datei
enthält die MD5-Prüfsummen der Packages- und Sources-Dateien, die dann wiederum
MD5-Prüfsummen der Binär- und Source-Packages enthalten. Genauere
Anweisungen, wie man die Paket-Integrität prüfen kann, können Sie im
<a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
Securing-Debian-Handbuch</a> nachlesen.</p>
<toc-add-entry name=break>Was soll ich tun, wenn ein anderes Paket nach
einer Sicherheitsaktualisierung nicht mehr funktioniert?</toc-add-entry>
<p>A: Zuerst sollten Sie herausfinden, warum dieses Paket nicht mehr
funktioniert und ob die Störung mit der Sicherheitsaktualisierung
zusammenhängt. Danach wenden Sie sich im Falle eines schwerwiegenden Problems
an das Sicherheits-Team, oder im Falle eines weniger schwerwiegenden
Problems an den Release-Manager für Stable. Diese Prozedur gilt auch dann, wenn
nach der Aktualisierung eines Pakets ein anderes nicht mehr funktioniert.
Wenn Sie nicht herausfinden können, was schief geht, aber eine Lösung gefunden haben,
wenden Sie sich auch an das Sicherheits-Team. Von dort wird man Sie dann gegebenenfalls
an den Release-Manager von Stable verweist.</p>
--- faq.wml.orig 2005-04-16 19:32:51.094686338 +0200
+++ faq.wml 2005-04-16 20:58:32.435637561 +0200
@@ -1,360 +1,350 @@
-#use wml::debian::template title="Debian Sicherheits-FAQ"
+#use wml::debian::template title="Debian Security-FAQ"
#use wml::debian::translation-check translation="1.46"
# $Id: faq.wml,v 1.61 2005/03/13 16:01:32 jseidel Exp $
-# Translation: Gerfried Fuchs <alfie@debian.org>
+# Translation: Marc Haber <mh+debian-packages@zugschlus.de> nach Vorarbeit von Gerfried Fuchs <alfie@debian.org>
#include "$(ENGLISHDIR)/security/faq.inc"
-<p>Zurzeit erreichen uns die folgenden Fragen etwas zu oft, deshalb wurden
-die Antworten dazu hier zusammengefasst.</p>
+<p>Dieses Dokument enthält Antworten auf die folgenden häufig gestellte Fragen.</p>
<maketoc>
-<toc-add-entry name=signature>Die Signatur eurer Gutachten kann nicht
- korrekt verifiziert werden!</toc-add-entry>
-<p>A: Das ist höchstwahrscheinlich ein Problem auf Ihrer Seite. Die
+<toc-add-entry name=signature>Die Signatur eurer Advisories ist falsch!</toc-add-entry>
+<p>A: Sehr wahrscheinlich handelt es sich um ein Problem auf Ihrer Seite. Es ist
+ technisch sichergestellt, dass nur Nachrichten mit der korrekten Signatur eines
+ Mitglieds des Security-Teams auf der Mailingliste
<a href="http://lists.debian.org/debian-security-announce/";>\
- debian-security-announce</a> Liste besitzt einen Filter, der es nur erlaubt,
- Nachrichten mit einer korrekten Signatur eines Mitglieds des
- Sicherheits-Teams zu versenden.</p>
-
-<p>Die häufigste Ursache dafür ist zumeist ein Mail-Programm auf Ihrer Seite,
- das die Nachricht leicht verändert und dadurch die Signatur ungültig macht.
- Versichern Sie sich, dass Ihre Software keine MIME-Entschlüsselung oder
- -Verschlüsselung durchführt und auch keine
- Tabulator/Leerzeichen-Konvertierungen vornimmt.</p>
+ debian-security-announce</a> erscheinen können.</p>
+
+<p>Die häufigste Ursache dafür sind zumeist durch ein Mail-Programm auf Ihrer
+ Seite durchgefährte leichte Änderungen an der Nachricht, durch die die Signatur
+ ungültig wird. Versichern Sie sich, dass Ihre Software keine MIME-Codierung oder
+ -Decodierung durchführt und auch keine Tabulator/Leerzeichen-Konvertierungen vornimmt.</p>
<p>Bekannte Übeltäter sind fetchmail (mit der Option mimedecode),
formail (von procmail 3.14) und evolution.</p>
-<toc-add-entry name="handling">Wie wird die Sicherheit in Debian
- gehandhabt?</toc-add-entry>
-<p>A: Wenn das Sicherheits-Team auf einen Vorfall aufmerksam wird, überprüfen
- ihn ein oder mehrere Mitglieder und überlegen seinen Einfluss auf das
- Stable-Release von Debian (z.B. ob es verwundbar ist oder nicht). Wenn
- unser System verwundbar ist, arbeiten wir an einer Problembehebung.
- Der Paketbetreuer wird ebenfalls kontaktiert, wenn dieser
- nicht bereits selbst das Sicherheits-Team kontaktiert hat.
- Schlussendlich wird die Behebung des Problems getestet und neue Pakete
- vorbereitet, die dann auf allen Stable-Architekturen übersetzt und
- anschließend hochgeladen werden. Nachdem das alles geschehen ist, wird
- ein Gutachten veröffentlicht.</p>
+<toc-add-entry name="handling">Wie werden sicherheitsrelevante Schwachstellen in Debian gehandhabt?</toc-add-entry>
+<p>A: Wenn das Security-Team auf eine Schwachstelle aufmerksam wird, prüfen
+ dessen Mitglieder den Einfluss der Schwachstelle auf das Stable-Release von
+ Debian. So wird zum Beispiel ermittelt, ob die Schwachstelle überhaupt in
+ Debian Stable vorliegt oder nicht. Wenn unser System verwundbar ist, beheben wir die
+ Schwachstelle. Wir nehmen dann Kontakt mit dem Paketbetreuer auf,
+ wenn dieser sich noch nicht selbst mit dem Security-Team in Verbindung gesetzt hat.
+ Es werden neue Pakete vorbereitet, die nach einem Test dann auf allen
+ Stable-Architekturen übersetzt und anschließend in das Debian-Archiv geladen werden.
+ Nachdem dies alles geschehen ist, wird als letzter Schritt ein Advisory veröffentlicht.</p>
-<toc-add-entry name=oldversion>Wieso trödeln Sie mit einer alten Version des
+<toc-add-entry name=oldversion>Wieso basteln Sie an einer alten Version des
Pakets herum?</toc-add-entry>
-<p>Die wichtigste Regel beim Erstellen eines neuen Pakets, das ein
- Sicherheitsproblem behebt, ist, so wenig Änderungen wie möglich vorzunehmen.
- Unsere Benutzer und Entwickler vertrauen auf das genaue Verhalten eines
- Releases nach dessen Freigabe, daher kann jede Änderung, die wir
- durchführen, möglicherweise das System von jemandem zerstören. Dies gilt
+<p>Unsere wichtigste Regel beim Erstellen eines neuen Pakets zur Behebung einer
+ Schwachstelle ist, so wenig Änderungen wie möglich vorzunehmen.
+ Unsere Benutzer und Entwickler vertrauen darauf, dass sich das Verhalten eines
+ Release nach dessen Freigabe nicht mehr ändert. Jede Änderung, die wir
+ durchführen, kann möglicherweise Systeme zerstören. Dies gilt
insbesondere für Bibliotheken: Es muss darauf geachtet werden, dass sich das
Anwendungs-Programm-Interface (API) oder Anwendungs-Binär-Interface (ABI)
niemals ändert, egal wie klein die Änderung ist.</p>
<p>Dies bedeutet, dass das Umsteigen auf eine neue Upstream-Version keine gute
- Lösung ist und stattdessen die relevanten Änderungen zurückportiert werden
- sollten. Üblicherweise sind die Upstream-Betreuer, wenn notwendig, bereit zu
- helfen, falls das Debian Sicherheits-Team nicht helfen kann.</p>
-
-<p>In einigen Fällen ist es nicht möglich, eine Sicherheitsreparatur
- zurückzuportieren, zum Beispiel, wenn ein großer Teil des Quellcodes
- modifiziert oder neu geschrieben werden muss. Wenn dies passiert, kann es
- notwendig sein, auf eine neue Upstream-Version umzusteigen, aber dies muss
- zuvor mit dem Sicherheits-Team koordiniert werden.</p>
-
-
-<toc-add-entry name=policy>Was sind die Richtlinien für ein repariertes Paket,
- um auf security.debian.org zu erscheinen?</toc-add-entry>
-<p>A: Sicherheits-Lücken in der Stable-Distribution garantieren, dass ein Paket
- zu security.debian.org hinzugefügt wird. Alles andere tut das nicht.
- Die Größe der Lücke
- ist hier nicht das wirkliche Problem. Üblicherweise bereitet das
- Sicherheits-Team die Pakete gemeinsam mit dem Paketbetreuer vor. Sofern
- jemand (ein Vertrauenswürdiger) das Problem analysiert, alle benötigten Pakete
- übersetzt und diese an das Sicherheits-Team übermittelt, dann können auch
- sehr kleine Sicherheits-Reparaturen auf security.debian.org erscheinen.
- Lesen Sie dazu bitte auch unterhalb weiter.</p>
+ Lösung ist und stattdessen die notwendigen Änderungen zurückportiert werden
+ müssen. Wenn das Debian Security-Team Unterstützung benötigt, sind die
+ Upstream-Autors üblicherweise hilsbereit.</p>
+
+<p>In einigen Fällen - zum Beispiel, wenn ein großer Teil des Quellcodes modifiziert
+ oder neu geschrieben wurde - ist es nicht möglich, einen Patch zur Entfernung einer
+ Schwachstelle zurückzuportieren. In diesem Fall kann es notwendig werden, doch auf
+ eine neue Upstream-Version umzusteigen. Dies muss aber in jedem Fall zuvor mit dem
+ Sicherheits-Team koordiniert werden.</p>
+
+
+<toc-add-entry name=policy>Was sind die Anforderungen für ein Paket mit einer security-relevanten Änderung für das Erscheinen auf security.debian.org?</toc-add-entry>
+<p>A: Nur wenn ein neues Paket eine sicherheitsrelevante Schwachstelle behebt, kann es
+ dem Archiv auf security.debian.org hinzugefügt wird. Sonst nicht.
+ Dabei kommt es nicht auf die Schwere der Schwachstelle an. Üblicherweise bereitet das
+ Security-Team die Pakete gemeinsam mit dem Paketbetreuer vor. Auch sehr kleine
+ sicherheitsrelevante Patches können ein Grund für die Aufnahme nach security.debian.org
+ sein, wenn eine vertrauenswürdige Person das Problem analysiert, alle benötigten Pakete
+ übersetzt und diese an das Sicherheits-Team übermittelt. Weitere Informationen sind
+ im Rest dieses Dokuments enthalten.</p>
-<p>Sicherheitsaktualisierungen dienen einem Zweck: Eine Behebung für eine
- Sicherheitsverwundbarkeit zu bieten. Sie sind keine Methode, um zusätzliche
+<p>Sicherheits-Updates dienen dem Zweck der Behebung von sicherheitsrelevanten
+ Schwachstellen. Sie sind keine Methode, um zusätzliche
Änderungen in das Stable-Release einzubringen, ohne diese die normale
Point-Release-Prozedur durchmachen zu lassen.</p>
-<toc-add-entry name=version>Die Versionsnummer für ein Paket zeigt an, dass
- ich immer noch eine verwundbare Version verwende!</toc-add-entry>
-<p>A: Anstatt auf ein neues Release zu aktualisieren, portieren wir die
- Sicherheits-Fixes auf die Version zurück, die mit dem Stable-Release
- ausgeliefert wurde. Wir tun dies, um zu garantieren,
- dass eine Veröffentlichung so wenig wie möglich ändert, damit sich als
- Resultat des Sicherheits-Fixes nichts ändert oder unerwartet Probleme
- verursacht werden. Sie können überprüfen, ob Sie eine sichere Version eines
- Paketes verwenden, indem Sie die changelog-Datei des Paketes ansehen, oder
- seine exakte Versionsnummer mit der angezeigten Version im
- Debian-Sicherheitsgutachten vergleichen.</p>
+<toc-add-entry name=version>Laut der Versionsnummer eines Pakets habe ich immer
+ noch eine verwundbare Version!</toc-add-entry>
+<p>A: Anstatt auf eine neue Upstream-Version zu aktualisieren, portieren wir die
+ Security-Fixes auf die Version zurück, die mit dem Stable-Release
+ ausgeliefert wurde. Wir tun dies, um zu garantieren, dass die durch das das
+ Security-Update eingeführten Änderungen so gering wie möglich sind. Somit wird
+ sichergestellt, dass sich beim Security-Update nichts ändert und keine unerwarteten Probleme
+ verursacht werden. Wenn Sie wissen wollen, ob Sie eine fehlerbereinigte Version eines
+ Paketes verwenden, so lesen Sie in der changelog-Datei des Paketes nach, oder vergleichen
+ die exakte Versionsnummer mit der im Debian-Advisory referenzierten Version.</p>
-<toc-add-entry name=testing>Wie wird die Sicherheit für <tt>Testing</tt> und
+<toc-add-entry name=testing>Wie wird die Security für <tt>Testing</tt> und
<tt>Unstable</tt> gehandhabt?</toc-add-entry>
-<p>A: Die kurze Antwort ist: gar nicht. Testing und Unstable sind starken
- Änderungen unterworfen und das Sicherheits-Team hat nicht die Mittel, die
- benötigt würden, um diese entsprechend zu unterstützen. Wenn Sie einen
- sicheren (und stabilen) Server benötigen, wird es Ihnen dringend empfohlen,
- bei Stable zu bleiben. Jedoch werden die Sicherheitssekretäre versuchen, die
+<p>A: Die kurze Antwort ist: gar nicht. Testing und Unstable ändern sich ständig,
+ und das Security-Team hat nicht die für eine Unterstützung notwendigen Ressourcen.
+ Wenn Sie einen
+ sicheren (und stabilen) Rechner haben wollen, wird es Ihnen dringend empfohlen,
+ bei Stable zu bleiben. Die Mitglieder des Security-Teams und die
+ Package-Maintainer werden jedoch versuchen, die
Probleme in Testing und Unstable zu beheben, nachdem Sie im Stable-Release
behoben sind.</p>
<toc-add-entry name=testing-security>Wie bekommt <tt>Testing</tt>
- Sicherheitsaktualisierungen?</toc-add-entry>
-<p>A: Sicherheitsaktualisierungen gelangen über <tt>Unstable</tt> in die
- <tt>Testing</tt>-Distribution. Normalerweise werden sie mit einer
- hohen Priorität hochgeladen, wodurch sich die Quarantäne auf zwei
- Tage reduziert. Nach dieser Zeit gelangen die Pakete automatisch
+ Security-Updates?</toc-add-entry>
+<p>A: Security-Updates gelangen über <tt>Unstable</tt> in die
+ <tt>Testing</tt>-Distribution. Pakete mit sicherheitsrelevanten Änderungen
+ werden mit Priority: high in das Archiv geladen. Dadurch verringert sich die
+ Wartezeit bis zur Migration nach <tt>Testing</tt> auf zwei Tage.
+ Nach dieser Zeit gelangen die Pakete automatisch
nach <tt>Testing</tt>, wenn sie für alle Architekturen gebaut worden
sind und ihre Abhängigkeiten in <tt>Testing</tt> erfüllt werden
können.</p>
-<toc-add-entry name=contrib>Wie wird die Sicherheit für <tt>contrib</tt> und
+<toc-add-entry name=contrib>Wie wird die Security für <tt>contrib</tt> und
<tt>non-free</tt> gehandhabt?</toc-add-entry>
<p>A: Die kurze Antwort ist: gar nicht. Contrib und non-free sind nicht
- offizieller Bestandteil der Debian-Distribution und werden nicht
- freigegeben und daher nicht vom Sicherheits-Team unterstützt. Einige
- non-free Pakete werden ohne Quellcode oder ohne eine Lizenz vertrieben,
- die die Verteilung von geänderten Versionen erlaubt. In diesen Fällen ist
- es überhaupt nicht möglich, Sicherheitsreparaturen durchzuführen.
+ offizieller Bestandteil der Debian-Distribution, werden nicht released
+ und erhalten keine Unterstützung vom Security-Team. Einige Pakete aus
+ non-free sind nur ohne Quellcode oder unter einer die Verteilung von
+ geänderten Versionen nicht erlaubenden Lizenz erhältlich. In diesen Fällen ist
+ es überhaupt nicht möglich, sicherheitsrelevante Schwachstellen zu beheben.
Falls es möglich ist, das Problem zu beheben und der Paketbetreuer oder
jemand anderes korrekte, aktualisierte Pakete zur Verfügung stellt, wird
- das Security-Team diese normalerweise bearbeiten und ein Gutachten
+ das Security-Team diese normalerweise bearbeiten und ein Advisory
veröffentlichen.</p>
-<toc-add-entry name=mirror>Wieso gibt es keine offiziellen Spiegel-Server für
+<toc-add-entry name=mirror>Wieso gibt es keine offiziellen Mirror-Server für
security.debian.org?</toc-add-entry>
-<p>A: Der Zweck von security.debian.org ist es, Sicherheitsaktualisierungen so
+<p>A: Der Zweck von security.debian.org ist es, Security-Updates so
schnell und einfach wie möglich zur Verfügung zu stellen.</p>
-<p>Die Verwendung von inoffiziellen Spiegeln zu empfehlen, würde zusätzliche
- Komplexität hinzufügen, die üblicherweise nicht benötigt wird und
- frustrierend sein kann, wenn diese Spiegel nicht aktuell gehalten werden.
- Offizielle Spiegel sind jedoch für die Zukunft geplant.</p>
+<p>Inoffizielle Mirrors sind in aller Regel nicht notwendig, erhöhen die Komplexität
+ und können Probleme verursachen, wenn sie
+ nicht aktuell sind. Offizielle Mirrors sind jedoch für die Zukunft geplant.</p>
<toc-add-entry name=missing>Ich habe DSA 100 und DSA 102 gesehen, wo ist aber
DSA 101?</toc-add-entry>
<p>A: Einige Distributoren (hauptsächlich von GNU/Linux, aber auch von
BSD-Derivaten)
- koordinieren Sicherheitsgutachten für einige Vorfälle und stimmen einer
- gemeinsamen Zeitlinie zu, damit alle Distributoren die Möglichkeit haben,
- ein Gutachten zur gleichen Zeit zu veröffentlichen. Dadurch soll verhindert
- werden, dass ein Distributor diskriminiert wird, der mehr Zeit benötigt
- (z.B. falls
- der Hersteller längere Qualitätssicherungs-Tests für die Pakete durchführt,
+ koordinieren die Herausgabe von Security-Advisories für Schwachstellen und
+ stimmen einem gemeinsamen Zeitplan zu. Damit soll ermöglicht werden, dass alle
+ Distributoren ihre Advisories zeitgleich veröffentlichen, um die Benachteiligung
+ einzelner, langsamerer Distributoren zu verringern (z.B. falls
+ der Distributor längere Qualitätssicherungs-Tests für die Pakete durchführt,
oder mehrere Architekturen bzw. Binär-Distributionen unterstützt). Unser
- eigenes Sicherheits-Team bereitet ebenfalls Gutachten im Vorhinein vor.
- Es passiert immer wieder mal, dass andere Sicherheitsgutachten früher
- abgearbeitet werden müssen, als vorbereitete Gutachten veröffentlicht werden
- können, und daher wird temporär eines oder mehrere Gutachten der Nummer
- nach ausgelassen.</p>
+ eigenes Security-Team bereitet oft Advisories vor, ohne sie sofort zu veröffentlichen.
+ Muss ein anderes Advisory vorgezogen werden, bleibt die für das verzögerte Advisory
+ bereits reservierte Nummer temporär unvergeben.</p>
<toc-add-entry name=contact>Wie erreiche ich das
- Sicherheits-Team?</toc-add-entry>
-<p>A: Sicherheitsinformationen können an security@debian.org oder
- team@security.debian.org geschickt werden, unter beiden Adressen
- erreichen Sie die Mitglieder des Sicherheits-Teams.</p>
+ Security-Team?</toc-add-entry>
+<p>A: Sicherheitsrelevante Informationen können Sie per E-Mail an security@debian.org oder
+ team@security.debian.org senden. Unter beiden Adressen
+ erreichen Sie die Mitglieder des Security-Teams.</p>
<p>Falls gewünscht, können
- die Mails mit dem Debian-Sicherheitskontakt-Schlüssel (Schlüssel-ID
+ die Mails an den GPG-Schlüssel des Debian-Security-Teams (Schlüssel-ID
<a href="http://blackhole.pca.dfn.de:11371/pks/lookup?op=get&exact=on&search=0x363CCD95";>\
- 0x363CCD95</a>) verschlüsselt werden. Lesen Sie auch die
- <a href="keys.txt">PGP/GPG-Schlüssel des Sicherheits-Teams</a>.
+ 0x363CCD95</a>) verschlüsselt werden. Bitte lesen Sie auch die Informationen zu den
+ <a href="keys.txt">PGP/GPG-Schlüsseln des Sicherheits-Teams</a>.
</p>
<toc-add-entry name=discover>Ich glaube, ich habe ein Sicherheitsproblem
- entdeckt, was soll ich tun?</toc-add-entry>
-<p>A: Wenn Sie von einem Sicherheitsproblem erfahren, entweder in Ihren eigenen
- Paketen oder in denen eines anderen Entwicklers, dann kontaktieren Sie bitte
- immer das Sicherheits-Team. Wenn das Debian-Sicherheits-Team die
- Verwundbarkeit bestätigt und andere Distributoren höchstwahrscheinlich
- ebenfalls davon betroffen sind, kontaktiert es diese üblicherweise auch.
- Wenn die Verwundbarkeit noch nicht öffentlich bekannt ist, wird es
- versuchen, die
- Sicherheitsgutachten mit den anderen Distributoren zu koordinieren, damit
- alle Haupt-Distributionen synchron sind.</p>
+ entdeckt. Was soll ich tun?</toc-add-entry>
+<p>A: Wenn Sie von einem Sicherheitsproblem erfahren, setzen Sie sich bitte immer
+ mit dem Security-Team in Verbindung - unabhängig davon, ob die Schwachstelle
+ in Ihren eigenen Paketen oder in denen eines anderen Entwicklers vorliegt.
+ Wenn das Debian-Sicherheits-Team die
+ Schwachstelle bestätigt und andere Distributoren höchstwahrscheinlich
+ ebenfalls davon betroffen sind, wird es sich um die Weiterleitung kümmern.
+ Wenn die Schwachstelle noch nicht öffentlich bekannt ist, wird es
+ versuchen, die Security-Advisories mit den anderen Distributoren zu koordinieren, damit
+ alle wichtigen Distributionen synchron sind.</p>
-<p>Falls Sie ein Debian-Entwickler sind, <a href="#care">lesen Sie unten
- weiter</a>.</p>
+<p><a href="#care">Weitere Informationen für Debian-Entwickler finden Sie weiter unten.</a></p>
<toc-add-entry name=care>Was soll ich bei einem Sicherheitsproblem in einem
meiner Pakete tun?</toc-add-entry>
-<p>A: Wenn Sie von einem Sicherheitsproblem erfahren, sei es
- in einem Ihrer Pakete oder in dem eines anderen,
- kontaktieren Sie bitte immer das Sicherheits-Team. Sie
+<p>A: Wenn Sie von einem Sicherheitsproblem erfahren, setzen Sie sich bitte immer
+ mit dem Security-Team in Verbindung - unabhängig davon, ob die Schwachstelle
+ in Ihren eigenen Paketen oder in denen eines anderen Entwicklers vorliegt.
+ Sie
können es mit einer E-Mail an team@security.debian.org erreichen. Die
Mitglieder des Teams
- behalten die Übersicht über offene Sicherheitsprobleme, können den
- Betreuern mit Sicherheitsproblemen helfen oder die Probleme selbst beheben
- und sind verantwortlich für das Versenden der Sicherheitsgutachten und die
+ haben die Übersicht über offene Sicherheitsprobleme, können den
+ Maintainern mit Sicherheitsproblemen helfen oder die Probleme selbst beheben
+ und sind verantwortlich für das Versenden der Advisories und die
Betreuung von security.debian.org.</p>
-<p>Die <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
- Entwickler-Referenz</a> enthält vollständige Informationen darüber, was zu
+<p>In der <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
+ Entwickler-Referenz</a> erhalten Sie vollständige Informationen darüber, was zu
tun ist.</p>
-<p>Es ist im Speziellen wichtig, dass Sie Pakete in keine andere Distribution
- außer Unstable ohne vorherige Zustimmung vom Sicherheitsteam hochladen, da
- das Umgehen davon Verwirrung stiftet und weiteren Aufwand verursacht.</p>
+<p>Es ist im Speziellen wichtig, dass Sie ohne Zustimmung des Security-Teams
+ keine Pakete in eine andere Distribution außer Unstable hochladen, da
+ Sie mit dem Übergehen des Security-Teams Verwirrung stiften und weiteren Aufwand
+ verursachen.</p>
<toc-add-entry name=enofile>Ich habe versucht, ein Paket herunterzuladen, das
- in einem der Sicherheitsgutachten aufgeführt war, aber ich bekomme dabei
+ in einem der Advisories aufgeführt war, aber ich bekomme dabei
einen `file not found' Fehler.</toc-add-entry>
-<p>A: Immer, wenn eine neuere Fehlerbehebung ein älteres Paket auf
- security.debian.org ersetzt, stehen die Chancen gut, dass das ältere
- Paket gelöscht wird, wenn das neue installiert wird. Daher erhalten Sie
+<p>A: Immer, wenn eine neuere fehlerbereinigte Version ein älteres Paket auf
+ security.debian.org ersetzt, wird das ältere Paket bei der Installation
+ des neuen gelöscht. Daher erhalten Sie
diesen `file not found' Fehler. Wir wollen Pakete mit bekannten
- Sicherheitslücken nicht länger als absolut notwendig verbreiten.</p>
+ Sicherheitslücken so schnell wie möglich aus der Distribution nehmen.</p>
-<p>Bitte benutzen Sie die Pakete von den neuesten Sicherheitsgutachten, die
- über die <a href="http://lists.debian.org/debian-security-announce/";>\
- debian-security-announce</a> Mailingliste verteilt werden. Am besten rufen
- Sie einfach <code>apt-get update</code> auf, bevor Sie das Paket
- aktualisieren.</p>
+<p>Bitte benutzen Sie immer die im neuesten Advisory genannten Pakete. Die Advisories
+ erhalten Sie über die Mailingliste
+ <a href="http://lists.debian.org/debian-security-announce/";>\
+ debian-security-announce</a>. Wenn Sie <code>apt-get update</code> aufrufen, bevor
+ Sie updates installieren, ist bei sonst sachgerechter Konfiguration Ihres Systems
+ sichergestellt, dass Sie die aktuelle Paketversion erhalten.</p>
-<toc-add-entry name=upload>Ich habe eine Fehlerbehebung, kann ich direkt auf
+<toc-add-entry name=upload>Ich habe einen Security-Patch. Kann ich direkt auf
security.debian.org hochladen?</toc-add-entry>
-<p>A: Nein, können Sie nicht. Das Archiv auf security.debian.org wird vom
- Sicherheitsteam betreut, das alle Pakete genehmigen muss. Sie sollten
- stattdessen Patches oder passende Quellcode-Pakete an das Sicherheits-Team
- unter team@security.debian.org schicken. Diese werden dann vom
- Sicherheits-Team überprüft und gegebenenfalls hochgeladen, entweder mit
- oder ohne Änderungen.</p>
-
-<p>Wenn Sie nicht mit Sicherheits-Uploads vertraut sind und sich nicht 100%
- sicher sind, dass Ihr Paket sauber ist, verwenden Sie bitte diesen Weg und
- laden Sie Ihr Paket nicht in das incoming-Verzeichnis hoch. Das
- Sicherheits-Team hat nur beschränkte Möglichkeiten, mit kaputten Paketen
- umzugehen, speziell wenn diese keine saubere Versionsnummer haben. Pakete
- können zurzeit nicht zurückgewiesen werden, und der
- <acronym lang="en" title="Build Daemon">buildd</acronym> wäre irritiert,
- wenn es möglich wäre. Daher sollten Sie bitte eine Mail schicken und helfen,
- indem Sie dem Sicherheits-Team keine zusätzlichen Schmerzen
- verursachen.</p>
-
-<p>Die <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
- Entwickler-Referenz</a> enthält vollständige Informationen darüber, was zu
- tun ist.</p>
+<p>A: Nein, das geht nicht. Das Archiv auf security.debian.org wird vom
+ Security-Team betreut, das alle Pakete genehmigen muss. Sie sollten
+ stattdessen Patches oder passende Source-Packages an das Security-Team
+ unter team@security.debian.org schicken. Diese werden dann nach Prüfung und
+ eventuell noch notwendigen Änderungen vom Security-Team hochgeladen.</p>
+
+<p>Wenn Sie nicht mit der Vorbereitung von Security-Uploads vertraut sind und sich nicht 100%
+ sicher sind, dass Ihr Paket in Ordnung ist, verwenden Sie bitte diesen Weg und
+ laden Sie Ihr Paket nicht direkt in das incoming-Verzeichnis hoch. Das
+ Sicherheits-Team hat nur beschränkte Möglichkeiten, in einem solchen Fall mit
+ defekten Paketen umzugehen. Besonders ärgerlich ist es, wenn das eigenmächtig hochgeladene
+ Paket eine falsche Versionsnummer hat. Es besteht derzeit keine Möglichkeit, derartige
+ Pakete zurückzuweisen, und der
+ <acronym lang="en" title="Build Daemon">buildd</acronym> kann durcheinander kommen.
+ Bitte schicken Sie deswegen im Zweifel lieber eine Mail an das Security-Team, um
+ den Aufwand niedrig zu halten.</p>
+
+<p>Vollständige Informationen über die Prozesse erhalten Sie in der
+ <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
+ Developer's Reference</a>.</p>
-<toc-add-entry name=ppu>Ich habe eine Fehlerbehebung, kann ich diese
+<toc-add-entry name=ppu>Ich habe einen Security-Patch. Kann ich dieses
stattdessen nach proposed-updates hochladen?</toc-add-entry>
-<p>A: Technisch gesehen können Sie es. Jedoch sollten Sie es nicht tun, da
- dies böse mit der Arbeit des Sicherheits-Teams kollidieren kann. Pakete von
+<p>A: Technisch gesehen geht das. Bitte unterlassen Sie dies jedoch, da hier
+ Konfliktpotenzial mit der Arbeit des Sicherheits-Teams besteht. Pakete von
security.debian.org werden automatisch in das proposed-updates-Verzeichnis
kopiert. Falls ein Paket mit der gleichen oder einer höheren Versionsnummer
- bereits in das Archiv eingespielt wurde, wird die Sicherheitsaktualisierung
+ bereits im Archiv ist, wird die Sicherheitsaktualisierung
vom Archiv-System zurückgewiesen. Auf diese Art wird die Stable-Distribution
- die Sicherheitsaktualisierung für dieses Paket nicht
- enthalten, außer, falls das »falsche« Paket im proposed-updates
- Verzeichnis zurückgewiesen wurde. Bitte kontaktieren Sie stattdessen das
- Sicherheits-Team: Fügen Sie alle
+ die Sicherheitsaktualisierung für dieses Paket nur dann
+ enthalten, wenn das »falsche« Paket im proposed-updates
+ Verzeichnis zurückgewiesen wurde. Bitte setzen Sie sich anstelle eines eigenen
+ Uploads mit dem Sicherheits-Team in Verbindung, fügen Sie alle
Details über die Verwundbarkeit bei und hängen die Quelldateien (d.h.
diff.gz- und dsc-Dateien) an die E-Mail an.</p>
-<p>Die <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
- Entwickler-Referenz</a> enthält vollständige Informationen darüber, was zu
- tun ist.</p>
+<p>Vollständige Informationen über die Prozesse erhalten Sie in der
+ <a href="$(DOC)/developers-reference/ch-pkgs#s-bug-security">\
+ Developer's Reference</a>.</p>
<toc-add-entry name=SecurityUploadQueue>Ich bin ziemlich sicher, dass meine
- Pakete in Ordnung sind, wie kann ich sie hochladen?</toc-add-entry>
+ Pakete in Ordnung sind. Wie kann ich sie hochladen?</toc-add-entry>
<p>A: Wenn Sie sich sehr sicher sind, dass ihre Pakete nichts zerstören, dass
- die Version sauber ist (z.B. größer als die Version in Stable und kleiner
- als die Version in Testing/Unstable), dass Sie kein Verhalten des Pakets
- geändert haben, trotz des entsprechenden Sicherheitsproblems, dass Sie es
+ die Versionsnummer sauber ist (z.B. größer als die Version in Stable und kleiner
+ als die Version in Testing/Unstable), dass Sie bei der Behebung der Schwachstelle
+ kein Verhalten des Pakets geändert haben, dass Sie es
für die richtige Distribution übersetzt haben (das ist
<code>oldstable-security</code> oder <code>stable-security</code>), dass
das Paket den ursprünglichen Quellcode enthält, falls das Paket neu auf
security.debian.org ist, dass Sie bestätigen können, dass der Patch gegen
- die aktuellste Version sauber ist und nur das entsprechende
- Sicherheitsproblem betrifft (prüfen Sie mit <code>interdiff -z</code> und
- beiden <code>.diff.gz</code>-Dateien), dass Sie den Patch zumindest
+ die aktuellste Version sauber ist und nur die Schwachstelle
+ (prüfen Sie mit <code>interdiff -z</code> die
+ beiden <code>.diff.gz</code>-Dateien) behebt, dass Sie den Patch zumindest
dreimal Korrektur gelesen haben, und dass <code>debdiff</code> keine
Änderungen anzeigt, dürfen Sie die Dateien in das incoming-Verzeichnis
<code>/org/ftp.root/pub/SecurityUploadQueue</code> auf security.debian.org
direkt hochladen. Bitte senden Sie auch eine Benachrichtigung mit allen
Details und Links an team@security.debian.org.</p>
-<toc-add-entry name=help>Wie kann ich bei der Sicherheit helfen?</toc-add-entry>
-<p>A: Bitte prüfen Sie jedes Problem nach, bevor Sie es an security@debian.org
- berichten. Wenn es Ihnen möglich ist, Patches zur Verfügung zu stellen,
- würde das den Prozess beschleunigen. Leiten Sie nicht einfach bugtraq
- Mails weiter, da wir diese bereits empfangen – teilen Sie uns
- stattdessen zusätzliche Informationen zu Dingen mit, die auf bugtraq
- gemeldet wurden.</p>
+<toc-add-entry name=help>Wie kann ich mit der Security helfen?</toc-add-entry>
+<p>A: Bitte überprüfen Sie jedes Problem doppelt, bevor Sie sich an security@debian.org
+ wenden. Wenn Sie Patches zur Verfügung stellen können,
+ beschleunigt dies den Prozess erheblich. Bitte senden Sie uns keine Mails
+ von der bugtraq- und anderen Mailinglisten, da wir diese bereits empfangen.
+ Teilen Sie uns
+ stattdessen zusätzliche Informationen zu den Dingen mit, die auf den Mailinglisten
+ diskutiert wurden.</p>
<toc-add-entry name=proposed-updates>Was umfasst
proposed-updates?</toc-add-entry>
<p>A: Dieses Verzeichnis beinhaltet Pakete, die für die nächste Revision von
Debian Stable vorgeschlagen sind. Wann immer ein Paket von einem
- Paketbetreuer für die Stable-Distribution hochgeladen wird, werden diese
+ Maintainer für die Stable-Distribution hochgeladen wird, wird dieses
im proposed-updates Verzeichnis abgelegt. Da Stable dafür gedacht ist,
stabil zu sein, werden keine automatischen Updates durchgeführt. Das
- Sicherheits-Team wird reparierte Pakete aus ihren Sicherheitsgutachten für
- Stable hochladen, jedoch werden diese zuerst in proposed-updates abgelegt.
- Alle paar Monate prüft der Stable-Release-Manager die Liste der Pakete in
- proposed-updates und diskutiert, ob ein Paket für Stable geeignet ist
+ Security-Team wird die in den Advisories referenzierten fehlerbereinigte Pakete für
+ Stable hochladen. Dies werden jedoch zuerst in proposed-updates abgelegt.
+ Alle paar Monate prüft der Release-Manager für die Stable-Distribution die Liste
+ der Pakete in
+ proposed-updates und bewertet, ob ein Paket für Stable geeignet ist
oder nicht. Daraus wird ein neues Point-Release von Stable zusammengestellt
- (z.B. 2.2r3 oder 2.2r4). Pakete, die nicht passen, werden wahrscheinlich
- von proposed-updates ebenfalls zurückgewiesen.</p>
+ (z.B. 2.2r3 oder 2.2r4). Nicht geeignete Pakete werden zu gegebener Zeit
+ aus dem proposed-updates-Verzeichnis zurückgewiesen.</p>
-<p>Beachten Sie, dass vom Paketbetreuer (nicht vom Sicherheits-Team)
+<p>Beachten Sie, dass vom Paketbetreuer (nicht vom Security-Team)
hochgeladene Pakete im proposed-updates/ Verzeichnis nicht vom
- Sicherheits-Team unterstützt werden.</p>
+ Security-Team unterstützt werden.</p>
-<toc-add-entry name=composing>Wie setzt sich das Sicherheits-Team
+<toc-add-entry name=composing>Wie setzt sich das Security-Team
zusammen?</toc-add-entry>
<p>A: Das Debian-Sicherheits-Team besteht aus <a href="../intro/organization">\
- mehreren Beauftragten und Unterstützern</a>. Das Sicherheits-Team selbst
- bestimmt die Leute, die dem Team beitreten.</p>
+ mehreren Mitgliedern und Helfern</a>. Das Security-Team bestimmt seine Mitgliedr
+ selbst.</p>
-<toc-add-entry name=lifespan>Wie lange sind Sicherheitsaktualisierungen
- vorgesehen?</toc-add-entry>
-<p>A: Das Sicherheits-Team versucht eine stabile Distribution für in etwa ein
- Jahr zu unterstützen, nachdem die nächste stabile Distribution freigegeben
- wurde; außer, eine weitere stabile Distribution wird innerhalb dieser
- Zeitspanne freigegeben. Es ist nicht möglich, drei Distributionen zu
- unterstützen; die gleichzeitige Unterstützung für zwei ist bereits
- schwierig genug.</p>
+<toc-add-entry name=lifespan>Wie lang ist der Zeitraum, in dem Sicherheits-Updates verfügbar sind?</toc-add-entry>
+<p>A: Das Security-Team versucht, eine Stable-Distribution für in etwa ein
+ Jahr zu unterstützen, nachdem die nächste Stable-Distribution freigegeben
+ wurde; außer, eine weitere Stable-Distribution wird innerhalb dieser
+ Zeitspanne freigegeben. Die gleichzeitige Unterstützung für zwei Distributionen
+ ist schon schwierig genug; die Unterstützung dreier Distributionen ist
+ nicht möglich.</p>
<toc-add-entry name=check>Wie kann ich die Integrität der Pakete prüfen?</toc-add-entry>
-<p>A: Dieser Prozess umfasst das Prüfen der Release-Datei-Signatur gegen den
+<p>A: Dieser Prozess umfasst das Prüfen der Signatur der Release-Datei gegen den
<a href="http://ftp-master.debian.org/ziyi_key_2005.asc";>öffentlichen
- Schlüssel</a>, der für die Archive verwendet wird. Die Release-Datei
- enthält die MD5-Prüfsummen der Packages- und Sources-Dateien, die
- MD5-Prüfsummen der Binär- und Quellcodepakete enthalten. Ausführlichere
- Anweisungen, wie man die Paket-Integrität prüfen kann, können im
+ Archiv-Schlüssel</a>. Die Release-Datei
+ enthält die MD5-Prüfsummen der Packages- und Sources-Dateien, die dann wiederum
+ MD5-Prüfsummen der Binär- und Source-Packages enthalten. Genauere
+ Anweisungen, wie man die Paket-Integrität prüfen kann, können Sie im
<a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
- Securing-Debian-Handbuch</a> nachgelesen werden.</p>
+ Securing-Debian-Handbuch</a> nachlesen.</p>
-<toc-add-entry name=break>Was soll ich tun, wenn ein zufälliges Paket nach
+<toc-add-entry name=break>Was soll ich tun, wenn ein anderes Paket nach
einer Sicherheitsaktualisierung nicht mehr funktioniert?</toc-add-entry>
<p>A: Zuerst sollten Sie herausfinden, warum dieses Paket nicht mehr
- funktioniert und wie es mit der Sicherheitsaktualisierung
- zusammenhängt. Danach sollten Sie sich an das
- Sicherheits-Team wenden, wenn es ein schwerwiegendes
- Problem ist, oder an den Stable-Release-Betreuer, wenn es
- weniger schwerwiegend ist. Es geht hier um zufällige
- Pakete, die nach der Aktualisierung eines anderen Paketes
- nicht mehr funktionieren. Wenn Sie nicht herausfinden
- können, was schief geht, aber eine Lösung gefunden haben,
- wenden Sie sich auch an das Sicherheits-Team. Es könnte jedoch sein,
- dass man Sie an den Stable-Release-Betreuer weiterleitet.</p>
+ funktioniert und ob die Störung mit der Sicherheitsaktualisierung
+ zusammenhängt. Danach wenden Sie sich im Falle eines schwerwiegenden Problems
+ an das Sicherheits-Team, oder im Falle eines weniger schwerwiegenden
+ Problems an den Release-Manager für Stable. Diese Prozedur gilt auch dann, wenn
+ nach der Aktualisierung eines Pakets ein anderes nicht mehr funktioniert.
+ Wenn Sie nicht herausfinden können, was schief geht, aber eine Lösung gefunden haben,
+ wenden Sie sich auch an das Sicherheits-Team. Von dort wird man Sie dann gegebenenfalls
+ an den Release-Manager von Stable verweist.</p>
Reply to: