@drakenclimber Ich werde eine kurze Gliederung für ein MAINTAINER_PROCESS.md-Dokument erstellen, das wir diskutieren / bearbeiten können, aber ich versuche immer noch, die Version 2.4.0 abzuschließen, und ich werde wahrscheinlich ein paar Tage brauchen, um neigen zu ein paar anderen, nicht zusammenhängenden und vernachlässigten Problemen :)

@pcmoore - Keine Sorge. Übrigens gute Arbeit an der Version 2.4! Lassen Sie mich wissen, wie ich helfen kann.

Fühlen Sie sich frei, mich als Versuchskaninchen zu benutzen, während wir den Prozess in Ordnung bringen :)

Übrigens gute Arbeit an der Version 2.4! Lassen Sie mich wissen, wie ich helfen kann.

Was auch immer Sie testen können, ist an dieser Stelle hilfreich. Ich fühle mich mit der Qualität dieser Veröffentlichung ziemlich gut, aber viele der kniffligen Teile haben sich geändert, so dass es nicht unvernünftig ist, sich vorzustellen, dass bei einer Anwendung ein Eckgehäuse kaputt gegangen ist. Ich hoffe, dass wir kein "brown bag" v2.4.1-Release machen müssen, aber man kann nie wissen.

Fühlen Sie sich frei, mich als Versuchskaninchen zu benutzen, während wir den Prozess in Ordnung bringen :)

Gut , dass Sie zu hören, dass becasue Sie das Meerschweinchen sind;)

@drakenclimber Ich

Der libseccomp-Maintainer-Prozess

https://github.com/seccomp/libseccomp

Dieses Dokument versucht, die Prozesse zu beschreiben, die von den verschiedenen Betreuern von libseccomp befolgt werden sollten. Es ist nicht als harte Anforderung gedacht, sondern eher als Leitfaden, der es mehreren Mitbetreuern erleichtern soll, das libseccomp-Projekt zu verwalten.

Wir erkennen, dass dieses Dokument, wie alle anderen Teile des libseccomp-Projekts, nicht perfekt ist. Wenn Änderungen vorgenommen werden müssen, sollten diese gemäß den hier beschriebenen Richtlinien vorgenommen werden.

Patches überprüfen und zusammenführen

In einer perfekten Welt würde jeder Patch unabhängig überprüft und von jedem Betreuer bestätigt werden, aber wir erkennen an, dass dies wahrscheinlich nicht für jeden Patch praktikabel ist. Unter normalen Umständen sollte jeder Patch von einer einfachen Mehrheit von Betreuern (im Fall einer geraden Anzahl von Betreuern N/2+1) bestätigt werden, bevor er in das Projektarchiv zusammengeführt wird. Betreuer sollten Patches mit einem ähnlichen Format wie dem Linux-Kernel bestätigen, zum Beispiel:

Acked-by: John Smith <[email protected]>

Der Betreuer, der den Patch in das Repository eingebunden hat, sollte seine Zustimmung hinzufügen, nachdem er sich vergewissert hat, dass dies korrekt ist (siehe die Dokumentation zum Einreichen von Patches); Wenn es für den Betreuer nicht richtig ist, sein Sign-Off hinzuzufügen, ist es wahrscheinlich, dass der Patch nicht zusammengeführt werden sollte. Der Betreuer sollte seine Unterschrift im Standardformat am Ende der Metadaten des Patches hinzufügen, zum Beispiel:

Signed-off-by: Jane Smith <[email protected])

Die Betreuer werden aus vielen Gründen ermutigt, miteinander zu kommunizieren. Einer davon ist, die anderen zu lassen, wenn einer für längere Zeit nicht erreichbar ist. Wenn ein Patch mangels ACKs zurückgehalten wird und die anderen Betreuer nach angemessener Zeit (z ohne einfache Mehrheit.

Verwalten sensibler Schwachstellenberichte

Der libseccomp-Schwachstellenmeldeprozess ist im Dokument SECURITY.md dokumentiert.

Die Betreuer sollten mit dem Melder zusammenarbeiten, um die Gültigkeit und Schwere der gemeldeten Schwachstelle zu beurteilen. Wann immer möglich, sollten verantwortungsvolle Vorgehensweisen beim Melden und Patchen befolgt werden, einschließlich Benachrichtigungen an die Mailinglisten _linux-distros_ und _oss-security_.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

Verwalten des GitHub Issue Tracker

Wir verwenden den GitHub Issue Tracker, um Fehler, Funktionsanfragen und manchmal unbeantwortete Fragen zu verfolgen. Die Konventionen hier sollen helfen, zwischen den verschiedenen Verwendungen zu unterscheiden und innerhalb dieser Kategorien Prioritäten zu setzen.

Funktionsanfragen MÜSSEN das Präfix "RFE:" zum Problemnamen hinzugefügt haben und das Label "Erweiterung" verwenden. Fehlerberichte MÜSSEN dem Fehlernamen ein "BUG:"-Präfix hinzugefügt und das Label "Bug" verwenden.

Probleme SOLLTEN mit den Labels "Priorität/Hoch", "Priorität/Mittel" und "Priorität/Niedrig" priorisiert werden. Die Bedeutung sollte hoffentlich klar sein.

Probleme KÖNNEN zusätzlich mit den Labels "pending/info", "pending/review" und "pending/revision" gekennzeichnet werden, um anzuzeigen, dass zusätzliche Informationen benötigt werden, das Issue/Patch zur Überprüfung aussteht und/oder der Patch Änderungen erfordert.

Verwalten der GitHub-Release-Meilensteine

Es sollte zu jedem Zeitpunkt mindestens zwei GitHub-Meilensteine ​​geben: einen für die nächste Haupt-/Nebenversion (z. B. v2.5) und einen für die nächste Patch-Version (z. B. v2.4.2). Wenn Probleme in das System eingegeben werden, können sie nach Ermessen der Betreuer zu den Meilensteinen hinzugefügt werden.

Verwalten der öffentlichen Mailingliste

Die Mailingliste wird derzeit bei Google Groups gehostet, und obwohl es möglich ist, ohne Google-Konto an Diskussionen teilzunehmen, ist ein Google-Konto erforderlich, um die Gruppe zu moderieren/zu verwalten. Betreuer, die über ein Google-Konto verfügen und in die Moderatorenliste aufgenommen werden möchten, sollten hinzugefügt werden, dies ist jedoch nicht erforderlich.

Trotz des Begriffs „Moderator“ ist die Liste derzeit unmoderiert und soll so bleiben.

Neue Projektversionen

Der Freigabeprozess von libseccomp ist im Dokument RELEASE_PROCESS.md dokumentiert.

Im Idealfall denke ich, dass es schön wäre, von jedem Betreuer für jeden Patch/PR eine ACK zu bekommen, aber ich bin mir nicht sicher, ob das zu viel von einem Hindernis wäre? Mein Bauchgefühl ist, dass libseccomp-Patches/PRs so klein sind, dass dies kein großes Problem darstellen sollte, aber ich bin gespannt, was Sie denken

Einverstanden. Ich denke, es wäre gut, ein ACK für jeden Patch anzustreben, aber wir möchten vielleicht die Flexibilität offen lassen, um dies für wirklich einfache Patches oder andere mildernde Umstände (lange Ferien usw.) zu umgehen. Offensichtlich sollte das Umgehen der anderen ACKs jedoch die Ausnahme und nicht die Regel sein.

Unabhängig davon denke ich, dass Patches von einem bestimmten Betreuer von einem anderen Betreuer bestätigt und übergeben werden müssen.

Dies wäre auf jeden Fall eine gute Angewohnheit. Es soll helfen, dumme Fehler zu vermeiden.

Wir müssen auch dokumentieren, wie das Zusammenführen von PRs und Patches gehandhabt wird, z.

Mich würde interessieren, welches Verfahren Sie empfehlen. Gibt es einen Grund, warum wir die integrierten Github-Tools vermeiden sollten?

Ich denke, der Schlüssel hier ist, alle Betreuer im entsprechenden Abschnitt in der README.md aufzulisten und zu erwähnen, dass die Betreuer zusammenarbeiten sollten, um das Problem zu lösen und den entsprechenden verantwortlichen Offenlegungsprozessen zu folgen. Wir sollten Links zu den Linux-Distributionen und oss-Security-Listen einfügen.

Ja, es ist wichtig, anderen eine einfache und sichere Methode zum Melden von Problemen bereitzustellen. Ich stimme zu.

Einverstanden. Ich denke, es wäre gut, ein ACK für jeden Patch anzustreben, aber wir möchten vielleicht die Flexibilität offen lassen, um dies für wirklich einfache Patches oder andere mildernde Umstände (lange Ferien usw.) zu umgehen. Offensichtlich sollte das Umgehen der anderen ACKs jedoch die Ausnahme und nicht die Regel sein.

Gute Punkte, ich stimme zu.

Wir müssen auch dokumentieren, wie das Zusammenführen von PRs und Patches gehandhabt wird, z.

Mich würde interessieren, welches Verfahren Sie empfehlen. Gibt es einen Grund, warum wir die integrierten Github-Tools vermeiden sollten?

Ich mag die Idee wirklich, dass jeder, der einen Patch berührt, entweder indem er ihn erstellt oder ihn an das Haupt-Repository festlegt, seine Unterschrift explizit zur Datei hinzufügt. Ich denke auch wirklich, dass die Betreuer make check auf ihrem lokalen System machen sollten, bevor sie etwas in das Hauptrepo verschieben. Das Zusammenführen von PRs direkt aus der GitHub-Schnittstelle ermöglicht es nicht wirklich, eines dieser Dinge zu tun.

Ich kann mir vorstellen, wenn das PR-Volumen jemals dramatisch ansteigen würde, könnten wir dies überdenken, aber im Moment ist das Volumen niedrig genug, dass die zusätzlichen manuellen Schritte meiner Meinung nach wirklich nicht von Bedeutung sind.

Meinungen @drakenclimber?

Ich habe gerade in die Mailingliste von Google Groups geschaut und es sieht so aus, als ob ich Ihr oracle.com-Konto/Ihre Adresse nicht als Manager/Moderator-Konto verwenden kann, es muss ein Google-Konto sein. An dieser Stelle denke ich, es liegt an dir @drakenclimber; Wenn Sie Manager-/Moderatorzugriff wünschen, müssen Sie sich mit einem Google-Konto anmelden.

Es ist erwähnenswert, dass ich die Liste derzeit nicht moderiere und ich denke, dass sie auch nicht moderiert werden sollte. Derzeit werden nur Posts, die Google für SPAM hält, nicht sofort in die Liste geschickt.

Es ist auch nichts wert, dass der Verkehr auf der Mailingliste außerhalb von Commit-Benachrichtigungen gegen Null geht, die meisten Interaktionen finden jetzt auf GitHub statt. Obwohl ich denke, dass wir die Mailingliste behalten sollten, denken Sie bitte nicht, dass Sie ein Manager/Moderator der Liste sein müssen, um "die Last zu teilen", in diesem Fall gibt es keine "Last".

Ich kann mir vorstellen, wenn das PR-Volumen jemals dramatisch ansteigen würde, könnten wir dies überdenken, aber im Moment ist das Volumen niedrig genug, dass die zusätzlichen manuellen Schritte meiner Meinung nach wirklich nicht von Bedeutung sind. Meinungen @drakenclimber?

Einverstanden. Ich bin mit einem manuellen Schritt in dieser Phase des Projekts in Ordnung. Genau das mache ich schon seit einiger Zeit.

An dieser Stelle denke ich, es liegt an dir @drakenclimber; Wenn Sie Manager-/Moderatorzugriff wünschen, müssen Sie sich mit einem Google-Konto anmelden.

Obwohl ich denke, dass wir die Mailingliste behalten sollten, denken Sie bitte nicht, dass Sie ein Manager/Moderator der Liste sein müssen, um "die Last zu teilen", in diesem Fall gibt es keine "Last".

Macht Sinn. Sie können gerne meine Gmail-Adresse hinzufügen, wenn Sie damit einverstanden sind; Ich sehe nicht wirklich einen Nachteil, aber es könnte sich später als hilfreich erweisen. tom dot hromatka bei gmail.

Mir ist gerade aufgefallen, dass GitHub unter dem Reiter "Sicherheit" für das Projekt die Datei SECURITY.md auf besondere Weise zu behandeln scheint (siehe Beispiel CONTRIBUTING.md). Wir sollten in Betracht ziehen, diese Datei als Teil dieses Prozesses zu verwenden.

Auf der Registerkarte "Sicherheit" können Sie auch einen privaten Fork des Projekts erstellen, damit Sie privat an Patches arbeiten können; Dies könnte insofern ein großer Gewinn sein, als es uns ermöglicht, bei Sicherheitsfixes besser zusammenzuarbeiten, ohne das Problem öffentlich zu machen, bevor der Fix fertig ist.

Das ist eine wirklich coole Funktion. Guter Fund!

@drakenclimber Ich habe gerade das Dokument im obigen Kommentar aktualisiert,

@drakenclimber Ich habe gerade Ihre Google Mail-Adresse bei der Google-Gruppe abonniert und Ihnen Manager-/Moderatorzugriff gewährt. Wenn es nicht funktioniert, lassen Sie es mich wissen.

Ich habe gerade Ihre Google Mail-Adresse bei der Google-Gruppe abonniert und Ihnen Manager-/Moderatorzugriff gewährt. Wenn es nicht funktioniert, lassen Sie es mich wissen.

Sieht aus, als ob es funktioniert. Ich konnte mich einloggen und in die Einstellungen für die Mailliste gehen. Vielen Dank!

Ich habe gerade das Dokument im obigen Kommentar aktualisiert, sieh es dir an und lass mich wissen, was du denkst.

Sieht mir richtig gut aus.

@drakenclimber hier ist ein kurzer Entwurf eines SECURITY.md-Dokuments, Gedanken?

Der libseccomp-Sicherheitsschwachstellen-Behandlungsprozess

https://github.com/seccomp/libseccomp

Dieses Dokument versucht, die Prozesse zu beschreiben, durch die sensible sicherheitsrelevante Fehler verantwortlich an das libseccomp-Projekt weitergegeben werden können und wie die Projektbetreuer mit diesen Berichten umgehen sollten. Genau wie die anderen libseccomp-Prozessdokumente sollte dieses Dokument als Leitdokument und nicht als hartes, unnachgiebiges Regelwerk behandelt werden; Die Fehlermelder und Projektbetreuer werden ermutigt, zusammenzuarbeiten, um die Probleme so gut wie möglich anzugehen, und zwar auf eine Weise, die für alle Beteiligten am besten funktioniert.

Probleme melden

Probleme mit der libseccomp-Bibliothek, die nicht zur sofortigen Veröffentlichung geeignet sind, sollten per E-Mail an die aktuellen libseccomp-Betreuer gesendet werden, die Liste ist unten. Wir fordern in der Regel höchstens eine Frist von 90 Tagen, um das Problem zu beheben, bevor es veröffentlicht wird, aber wir werden uns bemühen, das Problem so schnell wie möglich zu beheben und das Offenlegungsfenster zu verkürzen.

• Paul Moore, [email protected]
• Tom Hromatka, tom. [email protected]

Beheben sensibler Sicherheitsprobleme

Nach der Offenlegung eines Fehlers sollten die Betreuer zusammenarbeiten, um das Problem zu untersuchen und eine Lösung zu finden. Um eine frühzeitige Offenlegung des Problems zu verhindern, sollten diejenigen, die an der Lösung arbeiten, dies privat und außerhalb der traditionellen libseccomp-Entwicklungspraktiken tun. Eine mögliche Lösung hierfür besteht darin, die GitHub-Funktion „Sicherheit“ zu nutzen, um einen privaten Entwicklungszweig zu erstellen, der von den Betreuern und optional dem Berichterstatter geteilt werden kann. Ein Platzhalter-GitHub-Problem kann erstellt werden, aber die Details sollten äußerst begrenzt bleiben, bis das Problem behoben und verantwortungsbewusst offengelegt wurde. Wenn dem Problem ein CVE oder ein anderes Tag zugewiesen wurde, sollte der Titel des GitHub-Problems das Schwachstellen-Tag enthalten, sobald das Problem bekannt wurde.

Offenlegung

Wann immer möglich, sollten verantwortungsvolle Berichts- und Patching-Praktiken befolgt werden, einschließlich Benachrichtigungen an die linux-distros- und oss-security-Mailinglisten.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

auf eine Weise, die für sie am besten funktioniert.

Nitpick - ich wäre versucht, dies in in a manner which works best for all parties involved. zu ändern

Ich denke, das Dokument zur Sicherheitslücke sieht wirklich gut aus. Gute Arbeit!

auf eine Weise, die für sie am besten funktioniert.

Nitpick - ich wäre versucht, dies in in a manner which works best for all parties involved. zu ändern

Das gefällt mir, ich aktualisiere jetzt den Entwurf.

Ich denke, wir sind uns genug einig, dass es sich lohnt, eine PR mit den Dokumentations- / Prozessaktualisierungen zusammenzustellen, das werde ich jetzt tun und einen Link hierher posten.

PR-Link (auch in der GH-Historie oben enthalten): https://github.com/seccomp/libseccomp/pull/158

Ich denke, du bist jetzt fertig @drakenclimber , wenn dir etwas auffällt, lass es mich wissen.