audit-kernel

Linux Kernel Audit Subsystem
=============================================================================
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git  
https://github.com/linux-audit/audit-kernel

El subsistema de Auditoría (Audit) del kernel de Linux proporciona un marco de registro seguro que se utiliza para capturar y registrar eventos relevantes para la seguridad. Consta de un componente del kernel que genera registros de auditoría basados en la actividad del sistema, un demonio de espacio de usuario que registra estos registros en un archivo local o en un servidor de agregación remoto, y un conjunto de herramientas de espacio de usuario para la inspección y el posprocesamiento de los registros de auditoría.

El README principal del kernel de Linux se encuentra en
[Documentation/admin-guide/README.rst](https://github.com/linux-audit/audit-kernel/blob/main/Documentation/admin-guide/README.rst)

## Recursos en línea

El repositorio canónico del kernel de auditoría está alojado en 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

También existe un espejo oficial de GitHub mantenido:

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

## Ramas de origen del kernel y proceso de desarrollo

### Ramas de origen del kernel

Hay cuatro ramas git principales asociadas con el proceso de desarrollo:
stable-X.Y, dev, dev-staging y next. Además de estas cuatro ramas
principales, también hay ramas de trabajo en curso específicas de cada tema que comienzan con
un prefijo "working-"; por lo general, estas ramas pueden ignorarse a menos que
usted participe en el desarrollo de ese tema en particular. La
gestión de estas ramas temáticas puede variar según una serie de factores,
pero los detalles de cada rama se comunicarán en los hilos de discusión
relevantes en la lista de correo ascendente (upstream).

#### Rama stable-X.Y

La rama stable-X.Y está pensada para parches estables del kernel y se basa en
la etiqueta X.Y-rc1 de Linus, o en una etiqueta de lanzamiento estable X.Y.Z posterior según sea necesario.
Si se identifican problemas graves y se desarrolla un parche durante el ciclo de candidato
a lanzamiento del kernel, puede ser candidato para el marcado de kernel estable y su
inclusión en la rama stable-X.Y. La documentación del kernel principal de Linux
sobre parches estables del kernel contiene más información tanto sobre qué parches pueden ser
candidatos para el kernel estable, como sobre cómo marcarlos adecuadamente; también se pueden
esperar discusiones en la lista de correo ascendente sobre los méritos de marcar el parche para estable. Una vez que un parche se ha fusionado en la rama stable-X.Y y ha pasado
un día o dos en la rama next (consulte las notas sobre la rama next), se enviará a
Linus para fusionarlo en el próximo candidato a lanzamiento o en el lanzamiento final del kernel (consulte
las notas sobre solicitudes de extracción (pull requests) en este documento). Si el parche ha sido
marcado adecuadamente para estable, los otros árboles estables del kernel intentarán realizar un backport del
parche tan pronto como esté presente en el árbol de Linus; consulte la documentación principal
del kernel de Linux para más detalles.

A menos que se solicite específicamente, los desarrolladores no deben basar sus parches en la
rama stable-X.Y. Cualquier conflicto de fusión que surja al fusionar parches
enviados a upstream será gestionado por el mantenedor, aunque se puede solicitar ayuda y/o en casos extremos.

#### Rama dev

La rama dev está pensada para parches de desarrollo dirigidos a la próxima ventana de
fusión y se basa en la última etiqueta X.Y-rc1 de Linus, o en una etiqueta rc posterior según sea necesario
para evitar errores graves, conflictos de fusión u otros problemas significativos. Esta
rama es la rama de desarrollo principal donde se fusiona la mayoría de los parches
durante el ciclo normal de desarrollo del kernel. Los parches fusionados en la
rama dev estarán presentes en la rama next (consulte las notas sobre la rama next) y
se enviarán a Linus durante la próxima ventana de fusión.

Los desarrolladores deben usar la rama dev como una base estable para su propio
trabajo de desarrollo; solo en circunstancias extremas se realizará un rebase de la rama
dev durante el ciclo X.Y-rc, y el mantenedor será responsable de
resolver cualquier conflicto de fusión, aunque se puede solicitar ayuda y/o en casos extremos.

#### Rama dev-staging

La rama dev-staging está pensada para parches de desarrollo que no están
dirigidos a una ventana de fusión específica. La rama dev-staging existe como un área de
almacenamiento temporal para la rama dev principal y, como tal, su uso será impredecible y
se le hará rebase según sea necesario. Los parches fusionados en la rama dev-staging
deberían llegar a la rama dev principal en algún momento del futuro,
aunque eso no está garantizado.

A menos que se solicite específicamente, los desarrolladores no deben usar la rama dev-staging
como base para ningún trabajo de desarrollo.

#### Rama next

La rama next es una rama compuesta creada al fusionar las últimas ramas stable-X.Y
y dev, en ese orden. El objetivo principal de la rama next es
proporcionar una única rama para las pruebas de integración de linux-next que contenga todos los
commits de las ramas componentes. La rama next se actualizará
cada vez que haya un cambio en cualquiera de las ramas componentes, pero permanecerá
congelada durante la ventana de fusión para cooperar con los deseos del
equipo de linux-next.

Si bien los desarrolladores pueden usar la rama next como base para el desarrollo, la rama
dev probablemente sería una base más adecuada y estable.

### Proceso de desarrollo del kernel

Después de que Linus cierra la ventana de fusión del kernel en upstream, la rama stable-X.Y
asociada con el candidato de lanzamiento actual del kernel, la rama dev y
potencialmente la rama dev-staging (consulte las notas sobre la rama dev-staging) se
restablecerán para coincidir con la última etiqueta vX.Y-rc1 en el árbol de Linus. La rama next, como
rama compuesta formada a partir de estas ramas, se actualizará como resultado.

Durante el ciclo de desarrollo que comienza con el cierre de la ventana de fusión del kernel
y termina con el lanzamiento etiquetado del kernel, se aceptarán parches en
las ramas stable-X.Y y dev como se describe en sus respectivas secciones en
este documento. Si bien los parches se aceptarán en la rama stable-X.Y en
cualquier momento, es probable que no se acepten cambios significativos en la rama
dev cuando queden dos semanas o menos en el ciclo de desarrollo; esto
normalmente significa que solo se aceptan correcciones críticas de errores una vez que se lanza el kernel
vX.Y-rc6. Durante este tiempo, la rama next se regenerará según
sea necesario en función de los cambios en las ramas componentes, y se enviarán
solicitudes de extracción (pull requests) según sea necesario a Linus para los parches en la rama stable-X.Y.

Una vez que Linus lanza el kernel final vX.Y y se abre la ventana de fusión, ocurrirán
dos cosas. La primera es que la rama dev se duplicará en
una nueva rama stable-X'.Y', que representa el próximo lanzamiento del kernel, y
la segunda es que se enviará una solicitud de extracción desde esta rama para su inclusión
en la ventana de fusión actual. Durante el proceso de la ventana de fusión, las ramas dev y
next deben permanecer congeladas, aunque existe la posibilidad de que algunos
parches se fusionen en dev-staging por razones de prueba o relacionadas con el proceso.

#### Solicitudes de extracción para Linus

Para enviar una solicitud de extracción (pull request) a Linus, ya sea para una corrección crítica de errores o como
parte de la ventana de fusión, se debe crear una etiqueta git firmada que apunte al
punto de la solicitud de extracción. La etiqueta debe nombrarse usando el formato
"{subsystem}-pr-{date}" y se puede generar con el siguiente comando git:

```
% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}
```

Una vez que se ha creado la etiqueta firmada, debe usarse como base para la
solicitud de extracción.

## Herramientas de espacio de usuario y suites de pruebas

Las herramientas de espacio de usuario de auditoría y las suites de pruebas están alojadas en GitHub:

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