path: root/german/security/faq.wml

#use wml::debian::template title="Debian Sicherheits-FAQ"
#use wml::debian::translation-check translation="1fe91e1ee0d4350b235e726f3f93da47d0639b19"
# $Id$
# Translation: Gerfried Fuchs <alfie@debian.org>
# Updated: Holger Wansing <linux@wansing-online.de>, 2011, 2014, 2017.
# Updated: Holger Wansing <hwansing@mailbox.org>, 2020.
#include "$(ENGLISHDIR)/security/faq.inc"

<maketoc>

<toc-add-entry name=buthow>Ich habe eine Sicherheitsankündigung über
debian-security-announce erhalten, wie kann ich die verwundbaren Pakete
aktualisieren?</toc-add-entry>

<p>A: Wie es schon in der E-Mail mit der Sicherheitsankündigung steht,
   sollten Sie die von der Verwundbarkeit betroffenen Pakete aktualisieren.
   Sie können dies tun, indem Sie (nach dem Aktualisieren der Liste
   verfügbarer Pakete mittels <tt>apt-get update</tt>) einfach jedes
   Paket in Ihrem System mit <tt>apt-get upgrade</tt> aktualisieren.
   Sie können aber auch nur ein bestimmtes Paket aktualisieren,
   indem Sie <tt>apt-get install <i>Paket</i></tt> aufrufen.</p>

<p>Die Ankündigungs-E-Mail erwähnt das Quellpaket, in dem die
   Verwundbarkeit aufgetreten ist. Daher sollten Sie alle Binärpakete
   aktualisieren, die aus diesem Quellpaket erstellt werden.
   Um herauszubekommen, welche Binärpakete aktualisiert werden
   müssen, rufen Sie
   <tt>https://packages.debian.org/src:<i>Quellpaket-Name</i></tt> auf
   und klicken auf <i>[Zeige ... Binärpakete]</i> für die
   Distribution, die Sie aktualisieren wollen.</p>

<p>Es kann auch notwendig sein, einen Service oder laufenden Prozess
   neu zu starten. Der Befehl
   <a href="https://manpages.debian.org/checkrestart"><tt>checkrestart</tt></a>,
   der im Paket
   <a href="https://packages.debian.org/debian-goodies">debian-goodies</a>
   enthalten ist, kann dabei helfen, herauszufinden, welche Services
   oder Prozesse dies sind.</p>


<toc-add-entry name=signature>Die Signatur eurer Ankündigungen kann nicht
   korrekt verifiziert werden!</toc-add-entry>
<p>A: Das ist höchstwahrscheinlich ein Problem auf Ihrer Seite. Die
   <a href="https://lists.debian.org/debian-security-announce/">\
   debian-security-announce</a>-Liste besitzt einen Filter, der
   sicherstellt, dass nur Nachrichten mit einer korrekten Signatur
   eines Mitglieds des Sicherheitsteams versendet werden.</p>

<p>Die häufigste Ursache dafür ist zumeist ein E-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>

<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 Sicherheitsteam auf einen Vorfall aufmerksam wird, überprüfen
   ihn ein oder mehrere Mitglieder und bewerten 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 Sicherheitsteam 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
   eine Ankündigung veröffentlicht.</p>


<toc-add-entry name=oldversion>Wieso trödeln Sie mit 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 fehlerfreie Verhalten eines
   Releases nach dessen Freigabe, daher kann jede Änderung, die wir
   durchführen, möglicherweise das System von jemandem 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 Sicherheitsteam nicht helfen kann.</p>

<p>In einigen Fällen ist es nicht möglich, eine Sicherheitskorrektur
   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 Sicherheitsteam koordiniert werden.</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 sich so wenig wie möglich ändert, damit als
   Resultat des Sicherheits-Fixes keine unerwünschten Änderungen oder
   unerwarteten Probleme auftreten.
   Sie können überprüfen, ob Sie eine sichere Version eines
   Paketes verwenden, indem Sie in die changelog-Datei des Paketes schauen, oder
   seine exakte Versionsnummer mit der angezeigten Version in der
   Debian-Sicherheitsankündigung vergleichen.</p>


<toc-add-entry name=archismissing>Ich habe eine Ankündigung erhalten, aber
   der Build des Pakets für eine Prozessorarchitektur scheint zu
   fehlen.</toc-add-entry>
<p>A: Im Allgemeinen veröffentlicht das Sicherheitsteam
   Sicherheitsankündigungen mit Builds der aktualisierten Pakete für alle
   Architekturen, die Debian unterstützt. Allerdings sind einige
   Architekturen schneller als andere und es könnte vorkommen, dass die
   Builds für die meisten Architekturen fertig sind, während einige noch
   fehlen. Diese seltener verwendeten Architekturen repräsentieren einen
   kleinen Teil unserer Benutzerbasis. Abhängig von der Dringlichkeit des
   Problems könnten wir uns dafür entscheiden, die Ankündigung ohne weitere
   Verzögerung zu veröffentlichen. Die fehlenden Builds werden installiert,
   sobald sie verfügbar sind, jedoch ohne einen weiteren Hinweis hierzu.
   Natürlich werden wir niemals eine Ankündigung veröffentlichen, wenn
   dazu die Builds für i386 oder amd64 noch nicht vorhanden sind.</p>


<toc-add-entry name=unstable>Wie wird die Sicherheit für <tt>Unstable</tt>
   gehandhabt?</toc-add-entry>
<p>A: Die Sicherheit für Unstable wird primär durch die Paketbetreuer
   bewerkstelligt, nicht durch das Debian-Sicherheitsteam. Obwohl das
   Sicherheitsteam auch Korrekturen mit hoher Dringlichkeit zum Zwecke
   der Behebung von Sicherheitsproblemen hochladen kann, wenn
   festgestellt wird, dass der Betreuer nicht aktiv wird, hat die
   Sicherheitsunterstützung für Stable immer Priorität.
   Falls Sie einen sicheren (und stabilen) Server benötigen, wird Ihnen
   nachdrücklich empfohlen, bei Stable zu bleiben.</p>

<toc-add-entry name=testing>Wie wird die Sicherheit für <tt>Testing</tt>
   gehandhabt?</toc-add-entry>
<p>A: Die Sicherheit für Testing profitiert von den Bemühungen des
   ganzen Projekts, die Sicherheit für Unstable zu gewährleisten.
   Allerdings gibt es eine minimale zweitägige Verzögerung für die
   Migration der Korrekturen und manchmal können Sicherheitskorrekturen
   auch durch Versionsübergänge verzögert/aufgehalten werden. Das
   Sicherheitsteam hilft bei solchen Übergängen, indem wichtige
   Sicherheits-Uploads zurückgehalten werden, aber dies ist nicht immer
   möglich und dabei könnten auch Verzögerungen auftreten.
   Speziell in den Monaten nach einer neuen Stable-Veröffentlichung, wenn
   viele neue Versionen nach Unstable hochgeladen werden, könnten
   Sicherheitskorrekturen für Testing hinterher hinken.
   Falls Sie einen sicheren (und stabilen) Server benötigen, wird Ihnen
   nachdrücklich empfohlen, bei Stable zu bleiben.</p>


<toc-add-entry name=contrib>Wie wird die Sicherheit 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 Sicherheitsteam unterstützt. Einige
   non-free-Pakete werden ohne Quellcode vertrieben oder ohne eine Lizenz,
   die die Verteilung von geänderten Versionen erlauben würde.
   In diesen Fällen ist
   es überhaupt nicht möglich, Sicherheitskorrekturen durchzuführen.
   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 eine Ankündigung
   veröffentlichen.</p>


<toc-add-entry name=sidversionisold>Die Ankündigung sagt, dass Unstable in
     Version 1.2.3-1 korrigiert sei, aber 1.2.5-1 ist in Unstable. Was ist
     da los?</toc-add-entry>

<p>A: Wir versuchen, die erste Version in Unstable anzugeben, bei der das
   Problem behoben wurde. Manchmal hat der Betreuer in der Zwischenzeit noch
   neuere Versionen hochgeladen. Vergleichen Sie die Version in Unstable mit
   der angegebenen Version. Falls erstere identisch oder höher ist als die zweite,
   sollten Sie vor der Verwundbarkeit geschützt sein.
   Wenn Sie ganz sicher gehen wollen, können Sie das Changelog des Pakets
   mit <tt>apt-get changelog Paketname</tt> überprüfen und nach dem
   Eintrag suchen, der die Fehlerkorrektur erwähnt.</p>


<toc-add-entry name=mirror>Wieso gibt es keine offiziellen Spiegel-Server für
   security.debian.org?</toc-add-entry>
<p>A: Tatsächlich gibt es diese. Es existieren mehrere offizielle Spiegel, die
   als <acronym lang="en" title="Domain Name System">DNS</acronym>-Alias
   implementiert sind. Der Zweck von security.debian.org besteht darin,
   Sicherheitsaktualisierungen so
   schnell und einfach wie möglich zur Verfügung zu stellen.</p>

<p>Die Empfehlung, inoffizielle Spiegel zu verwenden, würde zusätzliche
   Komplexität hinzufügen, was normalerweise unnötig ist und
   frustrierend sein kann, falls diese Spiegel nicht aktuell gehalten werden.</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 Sicherheitsankündigungen für einige Vorfälle und stimmen
   miteinander eine gemeinsame Zeitlinie ab, damit alle Distributoren die
   Möglichkeit haben,
   eine Ankündigung 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,
   oder mehrere Architekturen bzw. Binär-Distributionen unterstützt). Unser
   eigenes Sicherheitsteam bereitet ebenfalls Ankündigungen im Vornherein vor.
   Es passiert immer wieder mal, dass andere Sicherheitsankündigungen früher
   abgearbeitet werden müssen, als vorbereitete Ankündigungen veröffentlicht werden
   können, und daher wird temporär eine oder mehrere Ankündigungen der Nummer
   nach ausgelassen.</p>


<toc-add-entry name=contact>Wie erreiche ich das
   Sicherheitsteam?</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 Sicherheitsteams.</p>

   <p>Falls gewünscht, können
   die E-Mails mit dem Debian-Sicherheitskontakt-Schlüssel (Schlüssel-ID
   <a href="https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x0d59d2b15144766a14d241c66baf400b05c3e651">\
   0x0D59D2B15144766A14D241C66BAF400B05C3E651</a>) verschlüsselt werden. Für die PGP-/GPG-Schlüssel der
   Mitglieder des Sicherheitsteams schauen Sie bitte auf den Schlüsselserver
   <a href="https://keyring.debian.org/">keyring.debian.org</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 einem
   Ihrer eigenen Pakete oder in dem eines anderen Entwicklers, dann
   kontaktieren Sie bitte auf jeden Fall
   das Sicherheitsteam. Wenn das Debian-Sicherheitsteam die
   Verwundbarkeit bestätigt und andere Distributoren höchstwahrscheinlich
   ebenfalls davon betroffen sind, wird es diese üblicherweise auch
   kontaktieren.
   Wenn die Verwundbarkeit noch nicht öffentlich bekannt ist, wird es
   versuchen, die
   Sicherheitsankündigungen mit den anderen Distributoren zu koordinieren, damit
   alle Haupt-Distributionen synchron sind.</p>

<p>Falls die Verwundbarkeit bereits öffentlich bekannt ist, schreiben Sie
   bitte unbedingt einen Fehlerbericht für die
   Debian-Fehlerdatenbank und markieren Sie ihn mit dem Tag
   <q>security</q>.</p>

<p>Falls Sie ein Debian-Entwickler sind, <a href="#care">lesen Sie unten
   weiter</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 Entwicklers,
   kontaktieren Sie bitte auf jeden Fall das Sicherheitsteam per E-Mail unter
   team@security.debian.org. 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 Sicherheitsankündigungen und die
   Betreuung von security.debian.org.</p>

<p>Die <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Entwicklerreferenz</a> enthält 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>


<toc-add-entry name=enofile>Ich habe versucht, ein Paket herunterzuladen, das
   in einer der Sicherheitsankündigungen aufgeführt war, aber ich bekomme dabei
   einen <q>file not found</q>-Fehler.</toc-add-entry>
<p>A: Immer, wenn eine neuere Fehlerkorrektur 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
   diesen <q>file not found</q>-Fehler. Wir wollen Pakete mit bekannten
   Sicherheitslücken nicht länger als absolut notwendig verbreiten.</p>

<p>Bitte benutzen Sie die Pakete aus den neuesten Sicherheitsankündigungen, die
   über die <a href="https://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>


<toc-add-entry name=upload>Ich habe eine Fehlerkorrektur, 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 via
   team@security.debian.org an das Sicherheitsteam schicken. Diese werden dann
   vom Sicherheitsteam überprüft und gegebenenfalls hochgeladen, entweder mit
   oder ohne weitere Änderungen.</p>

<p>Die <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Entwicklerreferenz</a> enthält vollständige Informationen darüber, was zu
   tun ist.</p>


<toc-add-entry name=ppu>Ich habe eine Fehlerkorrektur, kann ich diese
   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 Sicherheitsteams kollidieren kann. 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
   vom Archiv-System zurückgewiesen. Auf diese Art wird die Stable-Distribution
   die Sicherheitsaktualisierung für dieses Paket nicht
   enthalten, außer wenn das <q>falsche</q> Paket im
   proposed-updates-Verzeichnis zurückgewiesen wurde. Bitte kontaktieren Sie
   stattdessen das
   Sicherheitsteam: Fügen Sie alle
   Details über die Verwundbarkeit bei und hängen Sie die Quelldateien (d.h.
   diff.gz- und dsc-Dateien) an die E-Mail an.</p>

<p>Die <a href="$(DOC)/developers-reference/pkgs.html#bug-security">\
   Entwicklerreferenz</a> enthält vollständige Informationen darüber, was zu
   tun ist.</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 kein Verhalten des Pakets
   geändert haben, trotz des entsprechenden Sicherheitsproblems, dass Sie es
   für die richtige Distribution übersetzt haben (also
   <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
   dreimal Korrektur gelesen haben, und dass <code>debdiff</code> keine
   Änderungen anzeigt, dürfen Sie die Dateien direkt in das incoming-Verzeichnis
   <code>ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue</code>
   auf security.debian.org 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-E-Mails
   weiter, da wir diese bereits empfangen &ndash; teilen Sie uns
   stattdessen zusätzliche Informationen zu Dingen mit, die auf bugtraq
   gemeldet wurden.</p>

<p>Eine gute Art mit der Sicherheitsarbeit zu beginnen ist es, beim
   Debian Sicherheits-Tracker zu helfen (<a
   href="https://security-tracker.debian.org/tracker/data/report">Anleitung</a>).</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 Aktualisierung von
   Debian Stable vorgeschlagen sind. Wann immer ein Paket von einem
   Paketbetreuer für die Stable-Distribution hochgeladen wird, werden diese
   im proposed-updates Verzeichnis abgelegt. Da Stable dafür gedacht ist,
   stabil zu sein, werden keine automatischen Aktualisierungen durchgeführt. Das
   Sicherheitsteam wird korrigierte Pakete aus ihren Sicherheitsankündigungen 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
   oder nicht. Daraus wird eine neue Zwischenveröffentlichung von Stable zusammengestellt
   (z.B. 7.4 oder 7.6). Pakete, die nicht passen, werden wahrscheinlich
   von proposed-updates ebenfalls zurückgewiesen.</p>

<p>Beachten Sie, dass vom Paketbetreuer (nicht vom Sicherheitsteam)
   hochgeladene Pakete im Verzeichnis proposed-updates/ nicht vom
   Sicherheitsteam unterstützt werden.</p>


<toc-add-entry name=composing>Wie setzt sich das Sicherheitsteam
   zusammen?</toc-add-entry>
<p>A: Das Debian-Sicherheitsteam besteht aus <a href="../intro/organization#security">\
   mehreren Beauftragten und Unterstützern</a>. Das Sicherheitsteam selbst
   bestimmt die Leute, die dem Team beitreten.</p>


<toc-add-entry name=lifespan>Wie lange sind Sicherheitsaktualisierungen
   vorgesehen?</toc-add-entry>
<p>A: Das Sicherheitsteam 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=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
   <a href="https://ftp-master.debian.org/keys.html">öffentlichen
   Schlüssel</a>, der für die Archive verwendet wird. Die Release-Datei
   enthält Prüfsummen der Packages- und Sources-Dateien, die wiederum
   Prüfsummen der Binär- und Quellcodepakete enthalten. Ausführlichere
   Anweisungen, wie man die Paket-Integrität prüfen kann, können im
   <a href="$(HOME)/doc/manuals/securing-debian-howto/ch7#s-deb-pack-sign">\
   Securing-Debian-Handbuch</a> nachgelesen werden.</p>

<toc-add-entry name=break>Was soll ich tun, wenn ein zufälliges 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
    Sicherheitsteam 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 läuft, aber eine Lösung gefunden haben,
    wenden Sie sich auch an das Sicherheitsteam. Es könnte jedoch sein,
    dass man Sie an den Stable-Release-Manager weiterleitet.</p>


<toc-add-entry name=cvewhat>Was ist ein CVE-Identifier?</toc-add-entry>
<p>A: Das <q>Common Vulnerabilities and Exposures</q>-Projekt
   weisst spezifischen Verwundbarkeiten eindeutige Bezeichner, sogenannte
   CVE-Identifier zu, um den Verweis auf spezielle Sicherheitsprobleme
   zu vereinfachen. Weitere Informationen finden Sie in der <a
   href="https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures">\
   Wikipedia</a>.</p>


<toc-add-entry name=cvedsa>Gibt Debian für jede CVE-ID eine
    Sicherheitsankündigung (DSA) heraus?</toc-add-entry>
<p>A: Debians Sicherheitsteam verfolgt jede veröffentlichte CVE-ID,
   verbindet sie mit dem relevanten Debian-Paket und beurteilt ihren
   Einfluß in Bezug auf Debian - die Tatsache, dass für irgendetwas eine
   CVE-ID herausgegeben wurde, impliziert nicht zwingend, dass dies
   eine ernsthafte Bedrohung für ein Debian-System darstellt.
   Diese Informationen werden im <a
   href="https://security-tracker.debian.org">Debian Sicherheits-Tracker</a>
   festgehalten und für die Probleme, die für Debian als bedrohlich
   betrachtet werden, werden Sicherheitsankündigungen veröffentlicht.</p>

<p>Probleme mit geringen Auswirkungen, die keine DSA erforderlich machen,
   können in der nächsten Debian-Veröffentlichung oder in einer
   Zwischenveröffentlichung der aktuellen Stable- bzw. Oldstable-Distribution
   behoben werden oder sie werden in eine DSA integriert, die wegen
   gravierenderen Verwundbarkeiten herausgebracht wird.</p>


<toc-add-entry name=cveget>Kann Debian CVE-Identifier vergeben?</toc-add-entry>
<p>A: Debian hat den Status einer CVE Numbering Authority und kann CVE-IDs
   vergeben, aber gemäß CVE-Richtlinie nur für noch geheim gehaltene
   Sicherheitsprobleme. Falls Sie Kenntnis von einer noch unveröffentlichten
   Sicherheitslücke bei einer Software in Debian haben und eine CVE-ID
   dafür bekommen möchten, kontaktieren Sie das Debian Sicherheitsteam.
   Für Fälle, bei denen das Problem bereits öffentlich ist, empfehlen wir,
   dem unter <a
   href="https://github.com/RedHatProductSecurity/CVE-HOWTO">\
   CVE OpenSource Request HOWTO</a> beschriebenen Prozedere zu folgen.</p>


<toc-add-entry name=disclosure-policy>Hat Debian eine Richtlinie betreffend die
   Enthüllung von Sicherheitslücken (Vulnerability Disclosure Policy)?</toc-add-entry>
<p>A: Debian hat eine solche <a href="disclosure-policy">Richtlinie</a>
   im Rahmen der Teilnahme am CVE-Programm veröffentlicht.


<h1>Veraltete Debian Sicherheits-FAQ</h1>

<toc-add-entry name=localremote>Was bedeutet <q>local (remote)</q> (lokal
   (aus der Ferne))?</toc-add-entry>
<p>
   <b>Das Feld <i>Problem type</i> in DSA-Mails wird seit April 2014 nicht mehr verwendet.</b><br/>
   A: Einige Ankündigungen decken Verwundbarkeiten ab, die nicht mit dem klassischen
   Schema von lokalen Verwundbarkeiten und Verwundbarkeiten aus der Ferne
   identifiziert werden
   können. Einige Verwundbarkeiten können nicht aus der Ferne ausgenutzt werden,
   d.h. sie beziehen sich nicht auf einen Daemon, der auf einer Netzwerkschnittstelle
   horcht. Falls sie durch spezielle Dateien ausgenutzt werden können, die
   über das Netz bereit gestellt werden, der verwundbare Dienst aber nicht
   permanent mit dem Netz verbunden ist, schreiben wir in diesen Fällen
   <q>local (remote)</q>.
</p>

<p>Diese Verwundbarkeiten liegen irgendwo zwischen lokalen und solchen aus der
   Ferne und decken oft Archive ab, die über das Netz bereitgestellt werden
   könnten, z.B. E-Mail-Anhänge oder Dateien von einer Download-Seite.
</p>