linux-audit/audit-kernelMiroir GitHub du dépôt d'audit du noyau Linux.
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
https://github.com/linux-audit/audit-kernel
Le sous-système d'audit Linux fournit un cadre de journalisation sécurisé utilisé pour capturer et enregistrer les événements liés à la sécurité. Il se compose d'un composant noyau qui génère des enregistrements d'audit en fonction de l'activité du système, d'un démon espace utilisateur qui journalise ces enregistrements dans un fichier local ou sur un serveur d'agrégation distant, et d'un ensemble d'outils espace utilisateur pour l'inspection et le post-traitement des journaux d'audit.
Le README principal du noyau Linux se trouve dans Documentation/admin-guide/README.rst
Le dépôt canonique du noyau d'audit est hébergé par kernel.org :
Il existe également un miroir GitHub officiellement maintenu :
Il y a quatre branches git principales associées au processus de développement : stable-X.Y, dev, dev-staging et next. En plus de ces quatre branches principales, il existe également des branches thématiques spécifiques, en cours de développement, qui commencent par un préfixe « working- » ; ces branches peuvent généralement être ignorées sauf si vous êtes impliqué dans le développement de ce sujet particulier. La gestion de ces branches thématiques peut varier selon un certain nombre de facteurs, mais les détails de chaque branche seront communiqués dans les fils de discussion pertinents sur la liste de diffusion en amont.
La branche stable-X.Y est destinée aux correctifs pour noyau stable et est basée sur le tag X.Y-rc1 de Linus, ou sur un tag de version stable ultérieur X.Y.Z du noyau si nécessaire. Si des problèmes graves sont identifiés et qu'un correctif est développé pendant le cycle des candidats à la publication du noyau, ce correctif peut être candidat au marquage pour noyau stable et à l'intégration dans la branche stable-X.Y. La documentation du noyau Linux principal sur les correctifs pour noyau stable contient plus d'informations à la fois sur les correctifs qui peuvent être candidats au noyau stable, et sur la manière de marquer ces correctifs de façon appropriée ; des discussions sur la liste de diffusion en amont sur l'intérêt de marquer le correctif pour stable peuvent également être attendues. Une fois qu'un correctif a été fusionné dans la branche stable-X.Y et a passé un jour ou deux dans la branche next (voir les notes sur la branche next), il sera envoyé à Linus pour être fusionné dans la prochaine version candidate ou la version finale du noyau (voir les notes sur les demandes de tirage dans ce document). Si le correctif a été correctement marqué pour stable, les autres arbres de noyau stable tenteront de rétroporter le correctif dès qu'il sera présent dans l'arbre de Linus, voir la documentation principale du noyau Linux pour plus de détails.
Sauf demande spécifique, les développeurs ne devraient pas baser leurs correctifs sur la branche stable-X.Y. Les éventuels conflits de fusion résultant de la fusion de correctifs soumis en amont seront pris en charge par le mainteneur, bien que de l'aide et/ou une assistance puisse être demandée dans les cas extrêmes.
La branche dev est destinée aux correctifs de développement ciblant la prochaine fenêtre de fusion, et est basée sur le tag X.Y-rc1 le plus récent de Linus, ou sur un tag rc ultérieur si nécessaire pour éviter de graves bogues, des conflits de fusion ou d'autres problèmes importants. Cette branche est la branche de développement principale où la majorité des correctifs sont fusionnés au cours du cycle de développement normal du noyau. Les correctifs fusionnés dans la branche dev seront présents dans la branche next (voir les notes sur la branche next) et seront envoyés à Linus lors de la prochaine fenêtre de fusion.
Les développeurs devraient utiliser la branche dev comme base stable pour leur propre travail de développement ; ce n'est que dans des circonstances extrêmes que la branche dev sera rebasée pendant le cycle X.Y-rc, et le mainteneur sera responsable de la résolution des éventuels conflits de fusion, bien que de l'aide et/ou une assistance puisse être demandée dans les cas extrêmes.
La branche dev-staging est destinée aux correctifs de développement qui ne ciblent pas une fenêtre de fusion spécifique. La branche dev-staging existe comme zone de préparation pour la branche dev principale et, à ce titre, son utilisation sera imprévisible et elle sera rebasée si nécessaire. Les correctifs fusionnés dans la branche dev-staging devraient trouver leur chemin vers la branche dev principale à un moment donné dans le futur, bien que cela ne soit pas garanti.
Sauf demande spécifique, les développeurs ne devraient pas utiliser la branche dev-staging comme base pour tout travail de développement.
La branche next est une branche composite construite en fusionnant les dernières branches stable-X.Y et dev, dans cet ordre. L'objectif principal de la branche next est de fournir une branche unique pour les tests d'intégration linux-next contenant tous les commits des branches composantes. La branche next sera mise à jour dès qu'il y aura un changement dans l'une des branches composantes, mais elle restera figée pendant la fenêtre de fusion afin de coopérer avec les souhaits de l'équipe linux-next.
Bien que les développeurs puissent utiliser la branche next comme base de développement, la branche dev serait probablement une base plus appropriée, et stable.
Après que Linus ferme la fenêtre de fusion du noyau en amont, la branche stable-X.Y associée au candidat à la publication du noyau actuel, la branche dev, et potentiellement la branche dev-staging (voir les notes sur la branche dev-staging) seront réinitialisées pour correspondre au tag vX.Y-rc1 le plus récent de l'arbre de Linus. La branche next, en tant que branche composite composée de ces branches, sera mise à jour en conséquence.
Au cours du cycle de développement qui commence avec la fermeture de la fenêtre de fusion du noyau et se termine avec la publication étiquetée du noyau, des correctifs seront acceptés dans les branches stable-X.Y et dev comme décrit dans leurs sections respectives de ce document. Bien que des correctifs soient acceptés dans la branche stable-X.Y à tout moment, des changements importants ne seront probablement pas acceptés dans la branche dev lorsqu'il restera deux semaines ou moins dans le cycle de développement ; cela signifie généralement que seuls les correctifs de bogues critiques sont acceptés une fois que le noyau vX.Y-rc6 est publié. Pendant ce temps, la branche next sera régénérée au besoin en fonction des changements dans les branches composantes, et des demandes de tirage seront envoyées à Linus si nécessaire pour les correctifs de la branche stable-X.Y.
Lorsque Linus publie le noyau final vX.Y et que la fenêtre de fusion s'ouvre, deux choses se produisent. La première est que la branche dev est dupliquée en une nouvelle branche stable-X'.Y', représentant la prochaine version du noyau à venir, et la seconde est qu'une demande de tirage sera envoyée depuis cette branche pour inclusion dans la fenêtre de fusion actuelle. Pendant le processus de fenêtre de fusion, les branches dev et next devraient être figées, bien qu'il soit possible que certains correctifs puissent être fusionnés dans dev-staging pour des raisons de test ou liées au processus.
Afin d'envoyer une demande de tirage à Linus, que ce soit pour un correctif de bogue critique ou dans le cadre de la fenêtre de fusion, un tag git signé doit être créé pointant vers le point de la demande de tirage. Le tag doit être nommé en utilisant le format « {subsystem}-pr-{date} » et peut être généré avec la commande git suivante :
% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}
Une fois le tag signé créé, il doit être utilisé comme base pour la demande de tirage.
Les outils d'audit de l'espace utilisateur et les suites de tests sont hébergés par GitHub :