Achtung! Diese Übersetzung ist zu alt, benutzen Sie bitte das Original.

Debian Sicherheits-FAQ

Zurzeit erreichen uns die folgenden Fragen etwas zu oft, deshalb wurden die Antworten dazu hier zusammengefasst.

  1. Die Signatur eurer Ankündigungen kann nicht korrekt verifiziert werden!
  2. Wie wird die Sicherheit in Debian gehandhabt?
  3. Wieso trödeln Sie mit einer alten Version des Pakets herum?
  4. Was sind die Richtlinien für ein repariertes Paket, um auf security.debian.org zu erscheinen?
  5. Was bedeutet lokal (aus der Ferne)?
  6. Die Versionsnummer für ein Paket zeigt an, dass ich immer noch eine verwundbare Version verwende!
  7. Ich habe eine Ankündigung erhalten, aber der Build des Pakets für eine Prozessorarchitektur scheint zu fehlen.
  8. Wie wird die Sicherheit für Unstable gehandhabt?
  9. Wie wird die Sicherheit für Testing gehandhabt?
  10. Wie wird die Sicherheit für contrib und non-free gehandhabt?
  11. Die Ankündigung sagt, dass Unstable in Version 1.2.3-1 korrigiert sei, aber 1.2.5-1 ist in Unstable. Was ist hier los?
  12. Wieso gibt es keine offiziellen Spiegel-Server für security.debian.org?
  13. Ich habe DSA 100 und DSA 102 gesehen, wo ist aber DSA 101?
  14. Wie erreiche ich das Sicherheitsteam?
  15. Ich glaube, ich habe ein Sicherheitsproblem entdeckt, was soll ich tun?
  16. Was soll ich bei einem Sicherheitsproblem in einem meiner Pakete tun?
  17. Ich habe versucht, ein Paket herunterzuladen, das in einem der Sicherheitsankündigungen aufgeführt war, aber ich bekomme dabei einen file not found-Fehler.
  18. Ich habe eine Fehlerbehebung, kann ich direkt auf security.debian.org hochladen?
  19. Ich habe eine Fehlerbehebung, kann ich diese stattdessen nach proposed-updates hochladen?
  20. Ich bin ziemlich sicher, dass meine Pakete in Ordnung sind, wie kann ich sie hochladen?
  21. Wie kann ich bei der Sicherheit helfen?
  22. Was umfasst proposed-updates?
  23. Wie setzt sich das Sicherheitsteam zusammen?
  24. Wie lange sind Sicherheitsaktualisierungen vorgesehen?
  25. Wie kann ich die Integrität der Pakete prüfen?
  26. Was soll ich tun, wenn ein zufälliges Paket nach einer Sicherheitsaktualisierung nicht mehr funktioniert?

F: Die Signatur eurer Ankündigungen kann nicht korrekt verifiziert werden!

A: Das ist höchstwahrscheinlich ein Problem auf Ihrer Seite. Die debian-security-announce Liste besitzt einen Filter, der es nur erlaubt, Nachrichten mit einer korrekten Signatur eines Mitglieds des Sicherheitsteams zu versenden.

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.

Bekannte Übeltäter sind fetchmail (mit der Option mimedecode), formail (von procmail 3.14) und evolution.

F: Wie wird die Sicherheit in Debian gehandhabt?

A: Wenn das Sicherheitsteam 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 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.

F: Wieso trödeln Sie mit einer alten Version des Pakets herum?

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 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.

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.

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 Sicherheitsteam koordiniert werden.

F: Was sind die Richtlinien für ein repariertes Paket, um auf security.debian.org zu erscheinen?

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 Sicherheitsteam die Pakete gemeinsam mit dem Paketbetreuer vor. Sofern jemand (ein Vertrauenswürdiger) das Problem analysiert, alle benötigten Pakete übersetzt und diese an das Sicherheitsteam übermittelt, dann können auch sehr kleine Sicherheitsreparaturen auf security.debian.org erscheinen. Lesen Sie dazu bitte auch unterhalb weiter.

Sicherheitsaktualisierungen dienen einem Zweck: Eine Behebung für eine Sicherheitsverwundbarkeit zu bieten. Sie sind keine Methode, um zusätzliche Änderungen in das Stable-Release einzubringen, ohne diese die normale Prozedur einer Zwischenveröffentlichung (Point-Release) durchmachen zu lassen.

F: Was bedeutet lokal (aus der Ferne)?

A: Einige Ankündigungen decken Verwundbarkeiten ab, die nicht mit dem klassischen Schema von lokalen und Verwundbarkeiten aus der Ferne identifiziert werden können. Einige Verwundbarkeiten können nicht aus der Ferne ausgenutzt werden, d.h. sie entsprechen nicht einem Daemon, der auf einer Netzschnittstelle horcht. Falls sie durch spezielle Dateien ausgenutzt werden können, die über das Netz bereit gestellt werden, während der verwundbare Dienst nicht permanent mit dem Netz verbunden ist, schreiben wir in diesen Fällen lokal (aus der Ferne).

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 von einer Download-Seite.

F: Die Versionsnummer für ein Paket zeigt an, dass ich immer noch eine verwundbare Version verwende!

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-Sicherheitsankündigungen vergleichen.

F: Ich habe eine Ankündigung erhalten, aber der Build des Pakets für eine Prozessorarchitektur scheint zu fehlen.

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.

F: Wie wird die Sicherheit für Unstable gehandhabt?

A: Die kurze Antwort ist: gar nicht. Unstable ist starken Änderungen unterworfen und das Sicherheitsteam hat nicht die Mittel, die benötigt würden, um diese entsprechend zu unterstützen. Falls Sie einen sicheren (und stabilen) Server benötigen, wird Ihnen nachdrücklich empfohlen, bei Stable zu bleiben.

F: Wie wird die Sicherheit für Testing gehandhabt?

A: Falls Sie einen sicheren (und stabilen) Server benötigen, wird Ihnen nachdrücklich empfohlen, bei Stable zu bleiben. Allerdings gibt es Sicherheitsunterstützung für Testing: Das Debian Testing-Security-Team behandelt Probleme von Testing. Es stellt sicher, dass die korrigierten Pakete Testing auf dem normalen Weg durch Migration aus Unstable (mit reduzierter Quarantäne-Zeit) erreichen oder, falls das zu lange dauert, sie über die normale http://security.debian.org-Infrastruktur erledigt werden. Um diese zu benutzen, muss die folgende Zeile in /etc/apt/sources.list enthalten sein:

deb http://security.debian.org <codename>/updates main

Führen Sie dann apt-get update && apt-get upgrade wie gewohnt aus.

Beachten Sie, dass dies nicht garantiert, dass alle bekannten Sicherheitsprobleme in Testing behoben sind! Einige aktualisierte Pakete könnten auf den Übergang nach Testing warten. Weitere Informationen über die Sicherheits-Infrastruktur für Testing kann unter http://secure-testing-master.debian.net/ gefunden werden.

F: Wie wird die Sicherheit für contrib und non-free gehandhabt?

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 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. 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.

F: Die Ankündigung sagt, dass Unstable in Version 1.2.3-1 korrigiert sei, aber 1.2.5-1 ist in Unstable. Was ist hier los?

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 als Zweitere ist, sollten Sie vor der Verwundbarkeit geschützt sein.

F: Wieso gibt es keine offiziellen Spiegel-Server für security.debian.org?

A: Tatsächlich gibt es diese. Es existieren mehrere offizielle Spiegel, die über DNS-Aliase implementiert sind. Der Zweck von security.debian.org besteht darin, Sicherheitsaktualisierungen so schnell und einfach wie möglich zur Verfügung zu stellen.

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, falls diese Spiegel nicht aktuell gehalten werden.

F: Ich habe DSA 100 und DSA 102 gesehen, wo ist aber DSA 101?

A: Einige Distributoren (hauptsächlich von GNU/Linux, aber auch von BSD-Derivaten) koordinieren Sicherheitsankündigungen für einige Vorfälle und stimmen einer gemeinsamen Zeitlinie zu, 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 Vorhinein 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 eines oder mehrere Ankündigungen der Nummer nach ausgelassen.

F: Wie erreiche ich das Sicherheitsteam?

A: Sicherheitsinformationen können an security@debian.org oder team@security.debian.org geschickt werden, unter beiden Adressen erreichen Sie die Mitglieder des Sicherheitsteams.

Wenn Sie Paketbetreuer sind und uns bezüglich eines Problems in einem Ihrer Pakete kontaktieren möchten, erzeugen Sie bitte ein Ticket in unserem Request Tracker. Falls Sie PGP-Verschlüsselung verwenden möchten, ist es jedoch besser, eine reguläre E-Mail zu nutzen.

Falls gewünscht, können die E-Mails mit dem Debian-Sicherheitskontakt-Schlüssel (Schlüssel-ID 0x90F8EEC5) verschlüsselt werden. Für die PGP-/GPG-Schlüssel der Mitglieder des Sicherheitsteams schauen Sie bitte auf den Schlüsselserver keyring.debian.org.

F: Ich glaube, ich habe ein Sicherheitsproblem entdeckt, was soll ich tun?

A: Wenn Sie von einem Sicherheitsproblem erfahren, entweder in Ihren eigenen Paketen oder in denen eines anderen Entwicklers, dann kontaktieren Sie bitte immer das Sicherheitsteam. Wenn das Debian-Sicherheitsteam 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 Sicherheitsankündigungen mit den anderen Distributoren zu koordinieren, damit alle Haupt-Distributionen synchron sind.

Falls die Verwundbarkeit bereits öffentlich bekannt ist, schreiben Sie bitte unbedingt einen Fehlerbericht für das Debian-Fehlerverfolgungssystem und markieren Sie ihn mit dem Tag security.

Falls Sie ein Debian-Entwickler sind, lesen Sie unten weiter.

F: Was soll ich bei einem Sicherheitsproblem in einem meiner Pakete tun?

A: Wenn Sie von einem Sicherheitsproblem erfahren, sei es in einem Ihrer Pakete oder in dem eines anderen, kontaktieren Sie bitte immer das Sicherheitsteam, vorzugsweise indem Sie ein Ticket im Request Tracker erzeugen. Sie können das Team aber auch per 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 Sicherheitsankündigungen und die Betreuung von security.debian.org.

Die Entwicklerreferenz enthält vollständige Informationen darüber, was zu tun ist.

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.

F: Ich habe versucht, ein Paket herunterzuladen, das in einem der Sicherheitsankündigungen aufgeführt war, aber ich bekomme dabei einen file not found-Fehler.

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 diesen file not found-Fehler. Wir wollen Pakete mit bekannten Sicherheitslücken nicht länger als absolut notwendig verbreiten.

Bitte benutzen Sie die Pakete von den neuesten Sicherheitsankündigungen, die über die debian-security-announce Mailingliste verteilt werden. Am besten rufen Sie einfach apt-get update auf, bevor Sie das Paket aktualisieren.

F: Ich habe eine Fehlerbehebung, kann ich direkt auf security.debian.org hochladen?

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 Sicherheitsteam schicken, entweder über den Request Tracker oder via team@security.debian.org. Diese werden dann vom Sicherheitsteam überprüft und gegebenenfalls hochgeladen, entweder mit oder ohne Änderungen.

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 Sicherheitsteam 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 buildd wäre irritiert, wenn es möglich wäre. Daher sollten Sie bitte eine E-Mail schicken und helfen, indem Sie dem Sicherheitsteam keine zusätzlichen Schmerzen verursachen.

Die Entwicklerreferenz enthält vollständige Informationen darüber, was zu tun ist.

F: Ich habe eine Fehlerbehebung, kann ich diese stattdessen nach proposed-updates hochladen?

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, falls das falsche 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 die Quelldateien (d.h. diff.gz- und dsc-Dateien) an die E-Mail an.

Die Entwicklerreferenz enthält vollständige Informationen darüber, was zu tun ist.

F: Ich bin ziemlich sicher, dass meine Pakete in Ordnung sind, wie kann ich sie hochladen?

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 für die richtige Distribution übersetzt haben (das ist oldstable-security oder stable-security), 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 interdiff -z und beiden .diff.gz-Dateien), dass Sie den Patch zumindest dreimal Korrektur gelesen haben, und dass debdiff keine Änderungen anzeigt, dürfen Sie die Dateien in das incoming-Verzeichnis ftp://security-master.debian.org/pub/SecurityUploadQueue auf security.debian.org direkt hochladen. Bitte senden Sie auch eine Benachrichtigung mit allen Details und Links an team@security.debian.org.

F: Wie kann ich bei der Sicherheit helfen?

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 – teilen Sie uns stattdessen zusätzliche Informationen zu Dingen mit, die auf bugtraq gemeldet wurden.

Eine gute Art mit der Sicherheitsarbeit zu beginnen ist es, beim Debian Sicherheits-Tracker zu helfen (Anleitung).

F: Was umfasst proposed-updates?

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 im proposed-updates Verzeichnis abgelegt. Da Stable dafür gedacht ist, stabil zu sein, werden keine automatischen Aktualisierungen durchgeführt. Das Sicherheitsteam wird reparierte 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. 2.2r3 oder 2.2r4). Pakete, die nicht passen, werden wahrscheinlich von proposed-updates ebenfalls zurückgewiesen.

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

F: Wie setzt sich das Sicherheitsteam zusammen?

A: Das Debian-Sicherheitsteam besteht aus mehreren Beauftragten und Unterstützern. Das Sicherheitsteam selbst bestimmt die Leute, die dem Team beitreten.

F: Wie lange sind Sicherheitsaktualisierungen vorgesehen?

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.

F: Wie kann ich die Integrität der Pakete prüfen?

A: Dieser Prozess umfasst das Prüfen der Release-Datei-Signatur gegen den öffentlichen Schlüssel, der für die Archive verwendet wird. Die Release-Datei enthält die Prüfsummen der Packages- und Sources-Dateien, die Prüfsummen der Binär- und Quellcodepakete enthalten. Ausführlichere Anweisungen, wie man die Paket-Integrität prüfen kann, können im Securing-Debian-Handbuch nachgelesen werden.

F: Was soll ich tun, wenn ein zufälliges Paket nach einer Sicherheitsaktualisierung nicht mehr funktioniert?

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 geht, 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-Betreuer weiterleitet.