=============================================================================
https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/audit.git
https://github.com/linux-audit/audit-kernel
Linux Audit サブシステムは、セキュリティ関連イベントを捕捉・記録するための安全なロギングフレームワークを提供します。これは、システムアクティビティに基づいて監査レコードを生成するカーネルコンポーネント、これらのレコードをローカルファイルまたはリモート集約サーバーに記録するユーザースペースデーモン、そして監査ログの検査および後処理のためのユーザースペースツール群で構成されています。
Linux カーネル本体の README は Documentation/admin-guide/README.rst にあります。
公式の監査カーネルリポジトリは kernel.org でホストされています:
公式にメンテナンスされている GitHub ミラーもあります:
開発プロセスに関連する主要な git ブランチは4つあります: stable-X.Y、dev、dev-staging、next です。これらの4つの主要ブランチに加えて、トピック固有の進行中のブランチがあり、"working-" 接頭辞で始まります。これらのブランチは、その特定のトピックの開発に参加している場合を除き、通常は無視して構いません。これらのトピックブランチの管理は多くの要因によって異なりますが、各ブランチの詳細は上流のメーリングリストの関連する議論スレッドで通知されます。
stable-X.Y ブランチは、安定版カーネルパッチを対象としており、Linus の X.Y-rc1 タグ、または必要に応じてそれ以降の X.Y.Z 安定版カーネルリリースタグに基づいています。深刻な問題が特定され、カーネルのリリース候補サイクル中にパッチが開発された場合、それは安定版カーネルマークの候補となり、stable-X.Y ブランチに含まれる可能性があります。メインの Linux カーネルドキュメントの安定版カーネルパッチに関する記述には、どのパッチが安定版カーネル候補になり得るか、またそれらのパッチを適切にマークする方法についての詳細情報があります。パッチを安定版としてマークすることの是非に関する上流のメーリングリストでの議論も期待されます。パッチが stable-X.Y ブランチにマージされ、next ブランチで1、2日過ごした後(次の next ブランチの注記を参照)、次のリリース候補または最終カーネルリリースにマージするために Linus に送られます(このドキュメントのプルリクエストに関する注記を参照)。パッチが安定版として適切にマークされている場合、他の安定版カーネルツリーは、そのパッチが Linus のツリーに存在するとすぐにバックポートを試みます。詳細はメインの Linux カーネルドキュメントを参照してください。
特に要求されない限り、開発者は stable-X.Y ブランチをパッチのベースにしてはなりません。上流に送信されたパッチのマージから生じるマージ競合はメンテナーが処理しますが、極端な場合には支援が求められることがあります。
dev ブランチは、次のマージウィンドウを対象とした開発パッチを目的としており、Linus の最新の X.Y-rc1 タグ、または深刻なバグ、マージ競合、その他の重大な問題を避けるために必要に応じてそれ以降の rc タグに基づいています。このブランチは主要な開発ブランチであり、通常のカーネル開発サイクル中に大多数のパッチがマージされます。dev ブランチにマージされたパッチは next ブランチに存在し(次の next ブランチの注記を参照)、次のマージウィンドウ中に Linus に送られます。
開発者は dev ブランチを自身の開発作業の安定したベースとして使用すべきです。X.Y-rc サイクル中に dev ブランチがリベースされるのは極端な状況下のみであり、メンテナーがマージ競合の解決を担当しますが、極端な場合には支援が求められることがあります。
dev-staging ブランチは、特定のマージウィンドウを対象としない開発パッチを目的としています。dev-staging ブランチは、主要な dev ブランチのステージング領域として存在するため、その使用法は予測不可能であり、必要に応じてリベースされます。dev-staging ブランチにマージされたパッチは、将来のある時点で主要な dev ブランチに到達するはずですが、それは保証されていません。
特に要求されない限り、開発者は dev-staging ブランチを開発作業のベースとして使用すべきではありません。
next ブランチは、最新の stable-X.Y ブランチと dev ブランチをその順序でマージして構築される複合ブランチです。next ブランチの主な目的は、コンポーネントブランチのすべてのコミットを含む、linux-next 統合テスト用の単一ブランチを提供することです。next ブランチは、いずれかのコンポーネントブランチに変更があるたびに更新されますが、linux-next チームの意向に協力するため、マージウィンドウ中は凍結されます。
開発者は next ブランチを開発のベースとして使用できますが、dev ブランチの方がより適切で安定したベースとなるでしょう。
Linus が上流のカーネルマージウィンドウを閉じた後、現在のカーネルリリース候補に関連する stable-X.Y ブランチ、dev ブランチ、および場合によっては dev-staging ブランチ(dev-staging ブランチの注記を参照)は、Linus のツリー内の最新の vX.Y-rc1 タグに一致するようにリセットされます。これらのブランチから構成される複合ブランチである next ブランチも、その結果として更新されます。
カーネルのマージウィンドウの終了で始まり、タグ付けされたカーネルリリースで終わる開発サイクルの間、パッチはこのドキュメントのそれぞれのセクションで説明されているように stable-X.Y ブランチと dev ブランチに受け入れられます。stable-X.Y ブランチへのパッチはいつでも受け入れられますが、開発サイクルの残りが2週間以下の場合、dev ブランチへの重要な変更はおそらく受け入れられません。これは通常、vX.Y-rc6 カーネルがリリースされると、重要なバグ修正のみが受け入れられることを意味します。この間、next ブランチはコンポーネントブランチの変更に基づいて必要に応じて再生成され、stable-X.Y ブランチのパッチに対して必要に応じて Linus へのプルリクエストが送信されます。
Linus が最終的な vX.Y カーネルをリリースし、マージウィンドウが開くと、2つのことが起こります。1つ目は、dev ブランチが新しい stable-X'.Y' ブランチに複製され、新しいカーネルリリースを表すことです。2つ目は、このブランチから現在のマージウィンドウに含めるためのプルリクエストが送信されることです。マージウィンドウのプロセス中、dev ブランチと next ブランチは凍結されるべきですが、テストまたはプロセス関連の理由から一部のパッチが dev-staging にマージされる可能性があります。
Linus にプルリクエストを送信するには、重要なバグ修正またはマージウィンドウの一部として、プルリクエストポイントを指す署名付き git タグを作成する必要があります。タグは "{subsystem}-pr-{date}" 形式で名前を付ける必要があり、次の git コマンドで生成できます:
% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}
署名付きタグが作成されたら、それをプルリクエストのベースとして使用する必要があります。
監査ユーザースペースツールとテストスイートは GitHub でホストされています: