linux-audit/audit-kernelEspejo en GitHub del repositorio de auditoría del kernel de Linux
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
El repositorio canónico del kernel de auditoría está alojado en kernel.org:
También existe un espejo oficial de GitHub mantenido:
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).
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.
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.
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.
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.
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.
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.
Las herramientas de espacio de usuario de auditoría y las suites de pruebas están alojadas en GitHub: