audit-kernel

Sous-système 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](https://github.com/linux-audit/audit-kernel/blob/main/Documentation/admin-guide/README.rst)

## Ressources en ligne

Le dépôt canonique du noyau d'audit est hébergé par kernel.org :

* https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
* git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git

Il existe également un miroir GitHub officiellement maintenu :

* https://github.com/linux-audit/audit-kernel

## Branches source du noyau et processus de développement

### Branches source du noyau

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.

#### Branche stable-X.Y

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.

#### Branche dev

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.

#### Branche dev-staging

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.

#### Branche next

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.

### Processus de développement du noyau

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.

#### Demandes de tirage pour Linus

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.

## Outils espace utilisateur et suites de tests

Les outils d'audit de l'espace utilisateur et les suites de tests sont hébergés par GitHub :

* https://github.com/linux-audit