Aktualisierungsanforderungen-de

Andere Sprachen Deutsch ; English ; Français ;

Diese Seite wurde im März 2019 von wiki.mageia.org/de/ übernommen und erweitert. Für die ursprüngliche/n Seite/Autoren siehe hier. Hierbei handelt es sich um eine Übersetzung aus dem englischen.

Übersicht

Dies ist der erste Schritt um eine Aktualisierungsanforderung für eine veröffentlichte Distributon zu formulieren. Nichts ist in Stein gemeißelt, aber wir benötigen eine solche Anforderung damit wir uns darauf vorbereiten können Aktualisierungen für die aktuelle Mageia Veröffentlichung (Mga-current) freizugeben, und wir können den Prozess verfeinern, wie wir Fehler/Mängel finden. Meines Erachtens gibt es mindestens zwei Charakterisierungen der Distribution, die wir um jeden Preis vermeiden möchten:

• Mageia ist sehr langsam bei der Fehlerbehebung und der Veröffentlichung bei Aktualisierungen und
• Mageia gibt routinemäßig ungeprüfte Aktualisierungen frei

Während wir alle wissen, dass "alles mögliche geschehen kann", und aus diesem Grund gelegentlich schlechte Aktualisierungen das QA-Team verlassen, müssen wir alle Anstrengungen aufbieten damit wir rechtzeitig und vollständig NACH QA-Kriteren die Aktualisierungen freigegeben.

Ziel

Eine Aktualisierung sollte entweder einen Fehler in einer Anwendung oder einem Paket beheben oder eine Sicherheitslücke schließen. Ref: Fehlerstrategie

Versionierungsstrategie

In den meisten Fällen sollte eine Aktualisierung aus einem zusammengesetzten Grundgerüst derselben Version des Paketes bestehen, die mit der Distribution veröffentlicht wurde, wobei einige Ausnahmen bestehen:

• Nur eine Fehlerbehebung. Hier gibt es keinen Grund alle Fehlerbehebungen als Patches zur Verfügung zu stellen, wenn die neue Version die Aktualisierungen als Patches enthalten, wenn die neue Version keine neuen Fähigkeiten enthält.
• Softwareversionen die mit Aktualisierungen im Upstream nicht mehr unterstützt werden (Firefox und Thunderbird scheinen zur Zeit in diese Kategorie zu fallen).
• Software die an einen Online-Dienst servicegebunden ist (Spiele, Virenscanner?) und nur mit den entsprechenden Versionen funktionieren.
• Wir machen auch Ausnahmen für Pakete die den Weg in die aktuelle Mageia Veröffentlichung (Mga-current) nicht gefunden haben und Erweiterungen der Distribution sind, sofern sie keine anderen Pakete beeinträchtigen und die vollständige QA-Kontrolle passieren können.

Aktualisierungsanfragen, nur damit der Anwender "das neuste" Paket besitzt, sind in diesem Fall nicht der richtige Platz. Diese Art von Aktualisierungen gehören in die Rubrik backports.

Rollen

In diese Anforderungen sind verschiedene Gruppen eingebunden um diese Aktualisierungen zu erzeugen, testen und zu veröffentlichen:

Gemeinschaft (jeder)

(Hinweis: Je vollständiger die folgende Arbeit gemacht wird, umso zeitnaher können Aktualisierungen veröffentlicht werden):

• Identifikation der Version,
• Fehler berichten,
• Patches ausfindig machen und mit dem Fehler verbinden,
• identifizieren Sie relevante Einträge in anderen Fehlerdatenbanken, Sicherheitsdatenbanken,
• finde entsprechendes POC (Proof of Concept) mit dem die Schwachstellen illustriert werden und hänge diese der Fehlermeldung an,
• Teste und stelle Rückmeldungen zur Verfügung sobald das Aktualisierungspaket in den testing-Quellen erscheint,

Fehlerauswahlteam

• Überprüfen der Fehlerangaben auf Vollständigkeit,
• Anfordern von zusätzlichen Informationen, falls nötig,
• den Fehler einem Betreuer zuweisen,

Betreuer (oder jeder interessierte Packer)

• Bilden eines Aktualisierungspaketes mit Fehlerbehebungen (wenn dir der Fehler nicht bereits zugewiesen wurde, weise ihn dir selbst zu, so dass andere wissen, dass du daran arbeitest),
  • Wenn sich die Version nicht ändert, so lasse mkrel wie es ist '%define subrel 1'.
  • Ist es eine Aktualisierung auf eine neue Version: verwende '%mkrel 1' ohne subrel,
• Führe letztendlich einige anfängliche QA-Tests aus nur um zu sehen, dass die Anwendung/Fehlerbehebung funktioniert. Für eine Sicherheitsaktualisierung ist auch ein Link zur entsprechenden Ankündigung der Sicherheitslücke oder CVE notwendig, ebenso sollte, falls verfügbar, ein proof-of-concept (POC, auch als Exploit bekannt) mitgeliefert werden, um überprüfen zu können ob die Sicherheitsmängel behoben werden konnten,
• weiterreichen des Pakets zu den Aktualisierungstests. Überprüfe die Seite mgarepo x15px um zu erfahren wie man ein Pakte weiterreicht,
  • Schreibe die Aktualisierungsankündigung/Begutachtung (Update Advisory Announcement) in den Fehlerbericht der für die Aktualisierungsanforderung geschrieben wird (Beispiel einer Update Advisory Announcement x15px),
• Teile die Fehlermeldung wieder an qa-bugs@ml.mageia.org zu (hinzufügen der Paket-/Versionsnummer als Wiederzuweisung, sollte schon in der Begutachtung/Ankündigung enthalten sein)
• Auflisten ALLER SRPMs die für eine Aktualisierung benötigt werden und auch aller RPMs. Weshalb dies nötig ist siehst du im Bugreport 3949.

QA Team (Wie man eine Aktualisierung überprüft und freigibt)

• Teste das Paket (die Pakete) um sicherzugehen dass die Installation auf der unterstützten Architektur auch funktioniert,
• stelle sicher dass das Paket (die Pakete) von den vorhergehenden Version(en) aktualisiert werden kann,
• stelle sicher das dass entsprechende Problem behoben wurde, indem versucht wird dieses erneut zu erzwingen und die die vollständige Anwendung so ausgeführt wird, wie erwartet,
• für eine Sicherheitsschwachstelle, wenn ein POC verfügbar ist und innerhalb der QA-Fähigkeiten getestet werden kann, teste dass die neue Version immun gegen diese Schwachstelle ist (QA kann dies zum Betreuer oder dem Sicherheitsteam verschieben damit es dort überprüft wird oder geholfen werden kann)
• Wenn ein Paket die QA-Überprüfung nicht besteht, beginnt die Schleife zurück zur Fehlersuche und der Wiederholung des Fehlerbeheben-/Packen/Testzyklus bis wir ein zufriedenstellendes Resultat erreicht haben.

Sicherheitsteam

• Verfolgen der Mailinglisten und anderen Quellen von Sicherheitsinformationen für Veröffentlichungen die sich auf die unterstützten Versionen beziehen, genauso wie für Cauldron,
  • http://oss-security.openwall.org/wiki/mailing-lists,
  • http://osvdb.org/ (wenn Sie einmal einen Zugang haben, können Sie einen Dienst verwenden, der von Ihnen ausgewählte Aktualisierungsankündigungen an Sie weiterleitet),
• Eröffne einen Fehlerbericht oder gebe dem Betreuer des Paketes aufgrund des Problems Bescheid (so wie immer, ein Eintrag in Bugzilla ist etwas konkretes mit dem die Leute etwas anfangen können und sicherstellt das die Dinge nicht "durch das Raster fallen")
• Erstelle ein POC (Proof Of Concept) wenn nötig/möglich um zu testen ob das aktualisierte Paket gegen das Problem immun ist,
• Arbeite mit den Paket-Betreuern und der QA für jedes sicherheitsbezogene Problem zusammen, um das Verhalten der Patches und der Anwendung zu überprüfen.
• Nehme an den geschlossene vendor-cooperation Sicherheits(mailing)listen teil, und stelle sicher, dass wir den Embargovereinbarungen entsprechen. Durch Betreuen einer solchen Anwesenheit werden wir ein Mitglied der Sicherheitsgemeinschaft.

Sysadmin Team

• Verschieben des Paket von updates_testing nach updates, unter Verwendung eines Skripts,
• sende eine Mail an die Liste (mithilfe eines Skripts)
• FIXME veröffentlicht die Ankündigung des Updates auf den Webseiten
• FIXME delegiert diese Aufgabe an jemand anderen (richtige Einrichtung von sudo, usw.)

Referenzen

• Wie man ein Paket für eine Aktualisierung einreicht x15px
• QA Prozess zum Testen von Aufrüstungen