linux-audit/audit-kernelGitHub-Spiegel des Audit-Repositorys des Linux-Kernels
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
https://github.com/linux-audit/audit-kernel
Das Linux-Audit-Subsystem stellt ein sicheres Logging-Framework bereit, das verwendet wird, um sicherheitsrelevante Ereignisse zu erfassen und aufzuzeichnen. Es besteht aus einer Kernel-Komponente, die Audit-Datensätze auf der Grundlage von Systemaktivitäten erzeugt, einem Userspace-Daemon, der diese Datensätze in eine lokale Datei oder an einen entfernten Aggregationsserver protokolliert, sowie einer Reihe von Userspace-Werkzeugen zur Überprüfung und Nachbearbeitung von Audit-Protokollen.
Die Haupt-README des Linux-Kernels finden Sie unter Documentation/admin-guide/README.rst
Das kanonische Audit-Kernel-Repository wird von kernel.org gehostet:
Es gibt außerdem einen offiziell gepflegten GitHub-Spiegel:
Es gibt vier primäre Git-Branches, die mit dem Entwicklungsprozess verbunden sind: stable-X.Y, dev, dev-staging und next. Zusätzlich zu diesen vier primären Branches gibt es themenspezifische, in Arbeit befindliche Branches, die mit einem Präfix „working-“ beginnen; diese Branches können im Allgemeinen ignoriert werden, es sei denn, Sie sind in die Entwicklung des jeweiligen Themas eingebunden. Die Verwaltung dieser Themen-Branches kann je nach einer Reihe von Faktoren variieren, aber die Details jedes Branches werden in den relevanten Diskussionsthreads auf der Upstream-Mailingliste mitgeteilt.
Der stable-X.Y-Branch ist für stabile Kernel-Patches gedacht und basiert auf Linus' X.Y-rc1-Tag oder, falls erforderlich, einem späteren stabilen Kernel-Release-Tag X.Y.Z. Wenn ernsthafte Probleme festgestellt werden und während des Release-Kandidaten-Zyklus des Kernels ein Patch entwickelt wird, kann dieser ein Kandidat für die Kennzeichnung als stabiler Kernel-Patch und die Aufnahme in den stable-X.Y-Branch sein. Die Dokumentation des Haupt-Linux-Kernels zu stabilen Kernel-Patches enthält weitere Informationen sowohl darüber, welche Patches Kandidaten für stabile Kernel sein können, als auch darüber, wie diese Patches entsprechend gekennzeichnet werden; es ist auch mit Diskussionen auf der Upstream-Mailingliste über die Vorzüge der Kennzeichnung des Patches für stable zu rechnen. Sobald ein Patch in den stable-X.Y-Branch gemergt wurde und ein oder zwei Tage im next-Branch verbracht hat (siehe die Hinweise zum next-Branch), wird er an Linus gesendet, um in den nächsten Release-Kandidaten oder das endgültige Kernel-Release gemergt zu werden (siehe die Hinweise zu Pull-Requests in diesem Dokument). Wenn der Patch ordnungsgemäß für stable gekennzeichnet wurde, versuchen die anderen stabilen Kernel-Bäume, den Patch zu backporten, sobald er in Linus' Baum vorhanden ist; weitere Einzelheiten finden Sie in der Dokumentation des Haupt-Linux-Kernels.
Sofern nicht ausdrücklich darum gebeten, sollten Entwickler ihre Patches nicht auf dem stable-X.Y-Branch basieren. Alle Merge-Konflikte, die beim Mergen der upstream eingereichten Patches entstehen, werden vom Maintainer behoben, obwohl in extremen Fällen Hilfe und/oder Unterstützung angefordert werden kann.
Der dev-Branch ist für Entwicklungs-Patches gedacht, die für das kommende Merge-Fenster bestimmt sind, und basiert auf Linus' neuestem X.Y-rc1-Tag oder, falls erforderlich, einem späteren rc-Tag, um schwerwiegende Fehler, Merge-Konflikte oder andere bedeutende Probleme zu vermeiden. Dieser Branch ist der primäre Entwicklungszweig, in dem die Mehrheit der Patches während des normalen Kernel-Entwicklungszyklus gemergt wird. Patches, die in den dev-Branch gemergt werden, sind im next-Branch vorhanden (siehe die Hinweise zum next-Branch) und werden Linus während des nächsten Merge-Fensters zugesandt.
Entwickler sollten den dev-Branch als stabile Basis für ihre eigene Entwicklungsarbeit verwenden; nur unter extremen Umständen wird der dev-Branch während des X.Y-rc-Zyklus rebased, und der Maintainer ist für die Lösung etwaiger Merge-Konflikte verantwortlich, obwohl in extremen Fällen Hilfe und/oder Unterstützung angefordert werden kann.
Der dev-staging-Branch ist für Entwicklungs-Patches gedacht, die nicht auf ein bestimmtes Merge-Fenster abzielen. Der dev-staging-Branch existiert als Staging-Bereich für den Haupt-dev-Branch und seine Nutzung ist daher unvorhersehbar; er wird bei Bedarf rebased. Patches, die in den dev-staging-Branch gemergt werden, sollten irgendwann in der Zukunft ihren Weg in den primären dev-Branch finden, auch wenn das nicht garantiert ist.
Sofern nicht ausdrücklich darum gebeten, sollten Entwickler den dev-staging-Branch nicht als Basis für Entwicklungsarbeiten verwenden.
Der next-Branch ist ein zusammengesetzter Branch, der durch Mergen der neuesten stable-X.Y- und dev-Branches in dieser Reihenfolge entsteht. Der Hauptzweck des next-Branches besteht darin, einen einzigen Branch für die linux-next-Integrationstests bereitzustellen, der alle Commits der Komponenten-Branches enthält. Der next-Branch wird aktualisiert, sobald es eine Änderung an einem der Komponenten-Branches gibt, bleibt jedoch während des Merge-Fensters eingefroren, um den Wünschen des linux-next-Teams zu entsprechen.
Obwohl Entwickler den next-Branch als Basis für die Entwicklung verwenden können, wäre der dev-Branch wahrscheinlich eine geeignetere und stabilere Basis.
Nachdem Linus das Kernel-Merge-Fenster upstream schließt, werden der stable-X.Y-Branch, der mit dem aktuellen Kernel-Release-Kandidaten verbunden ist, der dev-Branch und möglicherweise der dev-staging-Branch (siehe die Hinweise zum dev-staging-Branch) zurückgesetzt, um dem neuesten vX.Y-rc1-Tag in Linus' Baum zu entsprechen. Der next-Branch wird als zusammengesetzter Branch aus diesen Branches infolgedessen aktualisiert.
Während des Entwicklungszyklus, der mit dem Schließen des Kernel-Merge-Fensters beginnt und mit dem getaggten Kernel-Release endet, werden Patches in den stable-X.Y- und den dev-Branch aufgenommen, wie in den jeweiligen Abschnitten dieses Dokuments beschrieben. Während Patches zu jedem beliebigen Zeitpunkt in den stable-X.Y-Branch aufgenommen werden, werden wesentliche Änderungen wahrscheinlich nicht in den dev-Branch aufgenommen, wenn noch zwei oder weniger Wochen im Entwicklungszyklus verbleiben; das bedeutet in der Regel, dass nur kritische Fehlerbehebungen akzeptiert werden, sobald der vX.Y-rc6-Kernel veröffentlicht wurde. Während dieser Zeit wird der next-Branch nach Bedarf auf der Grundlage von Änderungen in den Komponenten-Branches neu erzeugt, und Pull-Requests werden nach Bedarf an Linus für Patches im stable-X.Y-Branch gesendet.
Sobald Linus den endgültigen vX.Y-Kernel veröffentlicht und das Merge-Fenster öffnet, werden zwei Dinge geschehen. Erstens wird der dev-Branch in einen neuen stable-X'.Y'-Branch dupliziert, der das neue bevorstehende Kernel-Release repräsentiert, und zweitens wird aus diesem Branch ein Pull-Request zur Aufnahme in das aktuelle Merge-Fenster gesendet. Während des Merge-Fenster-Prozesses sollten der dev- und der next-Branch eingefroren sein, obwohl die Möglichkeit besteht, dass einige Patches aus Test- oder Prozessgründen in dev-staging gemergt werden.
Um einen Pull-Request an Linus zu senden, sei es für eine kritische Fehlerbehebung oder als Teil des Merge-Fensters, muss ein signierter Git-Tag erstellt werden, der auf den Pull-Request-Punkt zeigt. Der Tag sollte im Format „{subsystem}-pr-{date}“ benannt werden und kann mit dem folgenden Git-Befehl erzeugt werden:
% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}
Sobald der signierte Tag erstellt wurde, sollte er als Grundlage für den Pull-Request verwendet werden.
Die Audit-Userspace-Werkzeuge und Test-Suiten werden von GitHub gehostet: