linux-audit/audit-kernelMirror GitHub del repository audit del kernel Linux.
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
https://github.com/linux-audit/audit-kernel
Il sottosistema di audit di Linux fornisce un framework di logging sicuro utilizzato per catturare e registrare eventi rilevanti per la sicurezza. È composto da un componente del kernel che genera record di audit in base all'attività del sistema, un demone nello spazio utente che registra questi record su un file locale o su un server di aggregazione remoto, e un insieme di strumenti nello spazio utente per l'ispezione e la post-elaborazione dei log di audit.
Il README principale del kernel Linux si trova in Documentation/admin-guide/README.rst
Il repository canonico del kernel di audit è ospitato da kernel.org:
È disponibile anche un mirror GitHub mantenuto ufficialmente:
Ci sono quattro branch git principali associati al processo di sviluppo: stable-X.Y, dev, dev-staging e next. Oltre a questi quattro branch principali, ci sono anche branch work in progress specifici per argomento, che iniziano con un prefisso "working-"; questi branch possono generalmente essere ignorati a meno che non si sia coinvolti nello sviluppo di quel particolare argomento. La gestione di questi branch tematici può variare in base a una serie di fattori, ma i dettagli di ogni branch saranno comunicati nei relativi thread di discussione sulla mailing list upstream.
Il branch stable-X.Y è destinato alle patch per kernel stabili e si basa sul tag X.Y-rc1 di Linus, o su un successivo tag di rilascio stabile X.Y.Z del kernel, se necessario. Se vengono identificati problemi seri e viene sviluppata una patch durante il ciclo dei release candidate del kernel, essa può essere candidata per la marcatura come stabile e per l'inclusione nel branch stable-X.Y. La documentazione del kernel Linux principale sulle patch per kernel stabili contiene maggiori informazioni sia su quali patch possono essere candidate stabili, sia su come marcarle in modo appropriato; sono inoltre da aspettarsi discussioni sulla mailing list upstream riguardo all'opportunità di marcare la patch come stabile. Una volta che una patch è stata integrata nel branch stable-X.Y e ha trascorso un giorno o due nel branch next (vedi le note sul branch next), verrà inviata a Linus per essere integrata nel prossimo release candidate o nel rilascio finale del kernel (vedi le note sulle pull request in questo documento). Se la patch è stata correttamente marcata come stabile, gli altri alberi dei kernel stabili tenteranno di fare il backport della patch non appena questa sarà presente nell'albero di Linus; per maggiori dettagli, consultare la documentazione principale del kernel Linux.
Salvo richiesta specifica, gli sviluppatori non dovrebbero basare le proprie patch sul branch stable-X.Y. Eventuali conflitti di merge derivanti dall'integrazione di patch inviate upstream saranno gestiti dal maintainer, sebbene aiuto e/o possano essere richiesti in casi estremi.
Il branch dev è destinato alle patch di sviluppo che puntano alla prossima merge window e si basa sull'ultimo tag X.Y-rc1 di Linus, o su un tag rc successivo se necessario per evitare bug gravi, conflitti di merge o altri problemi significativi. Questo branch è il principale branch di sviluppo in cui la maggior parte delle patch viene integrata durante il normale ciclo di sviluppo del kernel. Le patch integrate nel branch dev saranno presenti nel branch next (vedi le note sul branch next) e verranno inviate a Linus durante la prossima merge window.
Gli sviluppatori dovrebbero usare il branch dev come base stabile per il proprio lavoro di sviluppo; solo in circostanze estreme il branch dev verrà riallineato (rebased) durante il ciclo X.Y-rc e il maintainer sarà responsabile della risoluzione di eventuali conflitti di merge, sebbene aiuto e/o possano essere richiesti in casi estremi.
Il branch dev-staging è destinato alle patch di sviluppo che non puntano a una specifica merge window. Il branch dev-staging esiste come area di staging per il principale branch dev e, come tale, il suo utilizzo sarà imprevedibile e verrà riallineato (rebased) secondo necessità. Le patch integrate nel branch dev-staging dovrebbero trovare la loro strada nel branch dev primario a un certo punto in futuro, sebbene ciò non sia garantito.
Salvo richiesta specifica, gli sviluppatori non dovrebbero usare il branch dev-staging come base per alcun lavoro di sviluppo.
Il branch next è un branch composito creato integrando i branch stable-X.Y e dev più recenti, in quest'ordine. L'obiettivo principale del branch next è fornire un unico branch per i test di integrazione linux-next che contenga tutti i commit dei branch componenti. Il branch next verrà aggiornato ogni volta che ci sarà una modifica a uno qualsiasi dei branch componenti, ma rimarrà congelato durante la merge window per assecondare le richieste del team linux-next.
Sebbene gli sviluppatori possano usare il branch next come base per lo sviluppo, il branch dev sarebbe probabilmente una base più adatta e stabile.
Dopo che Linus chiude la merge window del kernel upstream, il branch stable-X.Y associato all'attuale release candidate del kernel, il branch dev e potenzialmente il branch dev-staging (vedi le note sul branch dev-staging) verranno reimpostati per corrispondere all'ultimo tag vX.Y-rc1 nell'albero di Linus. Il branch next, in quanto branch composito formato da questi branch, verrà aggiornato di conseguenza.
Durante il ciclo di sviluppo che inizia con la chiusura della merge window del kernel e termina con il rilascio del kernel taggato, le patch verranno accettate nei branch stable-X.Y e dev come descritto nelle rispettive sezioni di questo documento. Sebbene le patch verranno accettate nel branch stable-X.Y in qualsiasi momento, è probabile che modifiche significative non vengano accettate nel branch dev quando mancano due o meno settimane alla fine del ciclo di sviluppo; questo significa tipicamente che vengono accettati solo bugfix critici una volta rilasciato il kernel vX.Y-rc6. Durante questo periodo, il branch next verrà rigenerato secondo necessità in base alle modifiche nei branch componenti, e verranno inviate pull request a Linus secondo necessità per le patch nel branch stable-X.Y.
Una volta che Linus rilascia il kernel finale vX.Y e la merge window si apre, accadranno due cose. La prima è che il branch dev verrà duplicato in un nuovo branch stable-X'.Y', che rappresenta il nuovo rilascio del kernel in arrivo, e la seconda è che verrà inviata una pull request da questo branch per l'inclusione nella merge window corrente. Durante il processo della merge window, i branch dev e next dovrebbero essere congelati, sebbene esista la possibilità che alcune patch vengano integrate in dev-staging per test o per motivi legati al processo.
Per inviare una pull request a Linus, sia per un bugfix critico che come parte della merge window, deve essere creato un tag git firmato che punti al punto della pull request. Il tag dovrebbe essere nominato usando il formato "{subsystem}-pr-{date}" e può essere generato con il seguente comando git:
% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}
Una volta creato il tag firmato, dovrebbe essere usato come base per la pull request.
Gli strumenti userspace di audit e le suite di test sono ospitati su GitHub: