linux-audit/audit-kernelLinux Kernel의 audit 저장소의 GitHub 미러
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 브랜치, 즉 stable-X.Y, dev, dev-staging 및 next가 있습니다. 이 네 가지 기본 브랜치 외에도 "working-" 접두사로 시작하는 특정 주제별 작업 진행 중인 브랜치가 있습니다. 이러한 브랜치는 해당 특정 주제의 개발에 참여하지 않는 한 일반적으로 무시해도 됩니다. 주제 브랜치의 관리 방식은 여러 요인에 따라 달라질 수 있지만, 각 브랜치에 대한 자세한 내용은 업스트림 메일링 리스트의 관련 토론 스레드에서 공지됩니다.
stable-X.Y 브랜치는 안정 커널 패치를 위한 브랜치이며, Linus의 X.Y-rc1 태그 또는 필요에 따라 이후의 X.Y.Z 안정 커널 릴리스 태그를 기준으로 합니다. 커널 릴리스 후보 주기 동안 심각한 문제가 발견되어 패치가 개발되면 해당 패치는 안정 커널(stable) 표시 및 stable-X.Y 브랜치 포함 후보가 될 수 있습니다. 기본 Linux 커널의 안정 커널 패치에 관한 문서에는 어떤 패치가 안정 커널 후보가 될 수 있는지, 그리고 그러한 패치를 적절히 표시하는 방법에 대한 자세한 정보가 나와 있습니다. 또한 패치를 stable로 표시하는 것의 장점에 대한 업스트림 메일링 리스트 논의가 이루어질 수도 있습니다. 패치가 stable-X.Y 브랜치에 병합되고 next 브랜치에서 하루 이틀을 보낸 후(다음 브랜치 설명 참조), 다음 릴리스 후보 또는 최종 커널 릴리스에 병합되도록 Linus에게 전송됩니다(이 문서의 풀 리퀘스트 설명 참조). 패치가 stable로 올바르게 표시된 경우, 다른 안정 커널 트리들은 Linus의 트리에 패치가 나타나는 즉시 백포트를 시도합니다. 자세한 내용은 기본 Linux 커널 문서를 참조하십시오.
특별히 요청하지 않는 한, 개발자는 stable-X.Y 브랜치를 패치의 기준으로 삼아서는 안 됩니다. 업스트림에 제출된 패치를 병합할 때 발생하는 병합 충돌은 유지 관리자가 처리하지만, 극단적인 경우 도움이 요청될 수 있습니다.
dev 브랜치는 다가오는 병합 창을 대상으로 하는 개발 패치를 위한 브랜치이며, Linus의 최신 X.Y-rc1 태그 또는 심각한 버그, 병합 충돌 및 기타 중대한 문제를 피하기 위해 필요에 따라 이후의 rc 태그를 기준으로 합니다. 이 브랜치는 일반적인 커널 개발 주기 동안 대부분의 패치가 병합되는 기본 개발 브랜치입니다. dev 브랜치에 병합된 패치는 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 커널을 릴리스하고 병합 창이 열리면 두 가지 일이 발생합니다. 첫째, dev 브랜치가 다가오는 새 커널 릴리스를 나타내는 새 stable-X'.Y' 브랜치로 복제되며, 둘째, 현재 병합 창에 포함시키기 위해 이 브랜치에서 풀 리퀘스트가 전송됩니다. 병합 창 프로세스 동안 dev 및 next 브랜치는 동결되어야 하지만, 테스트 또는 프로세스 관련 이유로 일부 패치가 dev-staging에 병합될 가능성도 있습니다.
중요한 버그 수정 또는 병합 창의 일부로서 Linus에게 풀 리퀘스트를 보내려면, 풀 리퀘스트 지점을 가리키는 서명된 git 태그를 생성해야 합니다. 태그 이름은 "{subsystem}-pr-{date}" 형식을 사용해야 하며, 다음 git 명령으로 생성할 수 있습니다:
% git tag -s -m "{subsystem}/stable-X'.Y' PR {date}" {subsystem}-pr-{date}
서명된 태그가 생성되면 이를 풀 리퀘스트의 기준으로 사용해야 합니다.
감사 사용자 공간 도구 및 테스트 스위트는 GitHub에서 호스팅됩니다: