@drakenclimber 논의/편집할 수 있는 MAINTAINER_PROCESS.md 문서에 대한 간략한 개요를 제시하겠습니다. 하지만 지금은 여전히 ​​v2.4.0 릴리스를 마무리하려고 노력하고 있으며 관련이 없고 소홀히 한 몇 가지 다른 문제에 관심을 기울이는 경향이 있습니다. :)

@pcmoore - 걱정 마세요. 그건 그렇고 v2.4 릴리스에 대한 멋진 작업입니다! 내가 어떻게 도울 수 있는지 알려주세요.

우리가 절차를 바로잡을 때 저를 기니피그로 사용해 주십시오. :)

그건 그렇고 v2.4 릴리스에 대한 멋진 작업입니다! 내가 어떻게 도울 수 있는지 알려주세요.

이 시점에서 할 수 있는 테스트는 무엇이든 도움이 됩니다. 나는 이 릴리스의 품질에 대해 꽤 기분이 좋지만 까다로운 부분이 많이 변경되었으므로 일부 응용 프로그램에서 모서리 케이스가 파손된 것을 상상하는 것이 비합리적이지 않습니다. 나는 우리가 "갈색 가방" v2.4.1 릴리스를 할 필요가 없기를 바랍니다. 그러나 당신은 결코 모릅니다.

우리가 절차를 바로잡을 때 저를 기니피그로 사용해 주십시오. :)

당신 이 기니피그이기 때문에 그런 말을 들으니 기쁩니다 ;)

@drakenclimber 나는 MAINTAINER_PROCESS.md 문서의 초안을 위해 이 댓글을 예약하고 있습니다(피드백을 기반으로 여기에서 계속 편집할 수 있다고 생각합니다). 이 문제에 대한 아이디어를 자유롭게 제출해 주시면 관련 내용이 정리되면 이에 대한 PR을 작성하겠습니다.

libseccomp 유지 관리자 프로세스

https://github.com/seccomp/libseccomp

이 문서는 다양한 libseccomp 유지 관리자가 따라야 하는 프로세스를 설명하려고 시도합니다. 이는 어려운 요구 사항이 아니라 여러 공동 유지 관리자가 libseccomp 프로젝트를 보다 쉽게 ​​관리할 수 있도록 하기 위한 안내 문서입니다.

우리는 libseccomp 프로젝트의 다른 모든 부분과 마찬가지로 이 문서가 완벽하지 않다는 것을 알고 있습니다. 변경해야 하는 경우 여기에 설명된 지침에 따라 변경해야 합니다.

패치 검토 및 병합

완벽한 세계에서 각 패치는 각 유지 관리자에 의해 독립적으로 검토되고 승인되지만 각 패치에 대해 실용적이지 않을 수 있음을 알고 있습니다. 정상적인 상황에서 각 패치는 저장소에 병합되기 전에 단순 과반수 유지 관리자(유지 관리자의 경우 N/2+1)가 ACK를 받아야 합니다. 유지 관리자는 Linux 커널과 유사한 형식을 사용하여 패치를 승인해야 합니다. 예를 들면 다음과 같습니다.

Acked-by: John Smith <[email protected]>

패치를 저장소에 병합한 관리자는 그렇게 하는 것이 올바른지 확인한 후 사인오프를 추가해야 합니다(패치 제출에 대한 문서 참조). 유지 관리자가 승인을 추가하는 것이 올바르지 않은 경우 패치가 병합되어서는 안 됩니다. 유지 관리자는 패치의 메타데이터 끝에 표준 형식을 사용하여 승인을 추가해야 합니다. 예를 들면 다음과 같습니다.

Signed-off-by: Jane Smith <[email protected])

유지 관리자는 여러 가지 이유로 서로 의사 소통하도록 권장되며, 그 중 하나는 오랜 시간 동안 연결할 수 없을 때 다른 사람을 허용하는 것입니다. ACK 부족으로 패치가 보류 중이고 합리적인 시간(예: 2주 이상 지연)이 지나도 다른 메인테이너가 응답하지 않는 경우 미해결 NACK이 없는 한 패치를 병합할 수 있습니다. 단순 과반수 없이.

민감한 취약점 보고서 관리

libseccomp 취약점 보고 프로세스는 SECURITY.md 문서에 설명되어 있습니다.

유지 관리자는 보고된 취약점의 유효성과 심각성을 평가하기 위해 보고자와 협력해야 합니다. 가능할 때마다 _linux-distros_ 및 _oss-security_ 메일링 리스트에 대한 알림을 포함하여 책임 있는 보고 및 패치 작업을 따라야 합니다.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

GitHub 문제 추적기 관리

GitHub 문제 추적기를 사용하여 버그, 기능 요청 및 때로는 답변되지 않은 질문을 추적합니다. 여기의 규칙은 다양한 용도를 구별하고 해당 범주 내에서 우선 순위를 지정하는 데 도움이 됩니다.

기능 요청에는 문제 이름에 "RFE:" 접두사를 추가하고 "향상" 레이블을 사용해야 합니다(MUST). 버그 보고서는 문제 이름에 "BUG:" 접두사를 추가하고 "버그" 레이블을 사용해야 합니다(MUST).

"우선순위/높음", "우선순위/중간" 및 "우선순위/낮음" 레이블을 사용하여 문제의 우선순위를 지정해야 합니다(SHOULD). 의미가 분명해야 합니다.

추가 정보가 필요하고, 문제/패치가 검토 대기 중이거나, 패치가 변경되어야 함을 나타내기 위해 문제에 "보류/정보", "보류/검토" 및 "보류/개정" 레이블을 추가로 지정할 수 있습니다.

GitHub 릴리스 마일스톤 관리

특정 시점에 최소한 두 개의 GitHub 마일스톤이 있어야 합니다. 하나는 다음 주/부 릴리스(예: v2.5)용이고 다른 하나는 다음 패치 릴리스(예: v2.4.2)입니다. 문제가 시스템에 입력되면 유지 관리자의 재량에 따라 이정표에 추가될 수 있습니다.

공개 메일링 리스트 관리

메일링 리스트는 현재 Google 그룹스에서 호스팅되며 Google 계정 없이도 토론에 참여할 수 있지만 그룹을 조정/관리하려면 Google 계정이 필요합니다. Google 계정이 있고 중재자 목록에 추가되기를 원하는 관리자를 추가해야 하지만 그렇게 할 필요는 없습니다.

"조정자"라는 용어에도 불구하고 목록은 현재 조정되지 않았으며 그대로 유지되어야 합니다.

새 프로젝트 릴리스

libseccomp 릴리스 프로세스는 RELEASE_PROCESS.md 문서에 설명되어 있습니다.

이상적으로는 각 패치/PR에서 각 유지 관리자로부터 ACK를 받는 것이 좋을 것이라고 생각하지만, 이것이 너무 많은 장애물이 될지 잘 모르겠습니다. 내 직감은 libseccomp 패치/PR의 볼륨이 충분히 낮아 이것이 큰 문제가 되지 않아야 하지만 어떻게 생각하는지 궁금합니다.

동의. 각 패치에 대해 ACK를 얻으려고 노력하는 것이 좋을 것이라고 생각하지만, 정말 간단한 패치나 기타 참작이 가능한 상황(장기 휴가 등)의 경우 이를 우회할 수 있는 유연성을 남겨두고 싶을 수도 있습니다. 분명히 다른 ACK를 우회하는 것은 예외가 아니라 정상이어야 합니다.

위의 내용에 관계없이 주어진 유지 관리자의 패치는 다른 유지 관리자가 승인하고 커밋해야 한다고 생각합니다.

이것은 분명히 좋은 습관이 될 것입니다. 어리석은 실수를 피하는 데 도움이 되어야 합니다.

또한 PR 및 패치 병합을 처리하는 방법(예: 유지 관리자 승인, 손으로 수행, GitHub 도구 사용 안함 등)을 문서화해야 합니다.

당신이 추천하는 과정을 보고 싶습니다. 내장된 github 도구를 피해야 하는 이유가 있습니까?

여기서 핵심은 README.md의 해당 섹션에 모든 유지 관리자를 나열하고 유지 관리자가 문제를 해결하고 적절한 책임 있는 공개 프로세스를 따르기 위해 협력해야 한다고 언급하는 것이라고 생각합니다. linux-distros 및 oss-security 목록에 대한 링크를 포함해야 합니다.

예, 다른 사람들이 문제를 보고할 수 있는 쉽고 안전한 방법을 제공하는 것이 중요합니다. 나는 동의한다.

동의. 각 패치에 대해 ACK를 얻으려고 노력하는 것이 좋을 것이라고 생각하지만, 정말 간단한 패치나 기타 참작이 가능한 상황(장기 휴가 등)의 경우 이를 우회할 수 있는 유연성을 남겨두고 싶을 수도 있습니다. 분명히 다른 ACK를 우회하는 것은 예외가 아니라 정상이어야 합니다.

좋은 점, 동의합니다.

또한 PR 및 패치 병합을 처리하는 방법(예: 유지 관리자 승인, 손으로 수행, GitHub 도구 사용 안함 등)을 문서화해야 합니다.

당신이 추천하는 과정을 보고 싶습니다. 내장된 github 도구를 피해야 하는 이유가 있습니까?

저는 패치를 작성하거나 주 리포지토리에 커밋하여 패치를 만지는 모든 사람이 명시적으로 파일에 서명을 추가한다는 아이디어를 정말 좋아합니다. 또한 메인 리포지토리에 무언가를 푸시하기 전에 메인테이너가 로컬 시스템에서 make check 를 수행해야 한다고 생각합니다. GitHub 인터페이스 내에서 직접 PR을 병합하는 것은 실제로 이러한 작업을 수행하는 것을 허용하지 않습니다.

PR 볼륨이 극적으로 증가했다면 이를 재고할 수 있지만 지금은 볼륨이 충분히 낮아서 추가 수동 단계가 실제로 중요하지 않다고 생각합니다.

의견 @drakenclimber?

방금 Google 그룹스 메일링 리스트를 살펴보았는데 귀하의 oracle.com 계정/주소를 관리자/조정자 계정으로 사용할 수 없는 것 같습니다. Google 계정이어야 합니다. 이 시점에서 @drakenclimber는 당신에게 달려 있다고 생각합니다. 관리자/조정자 액세스를 원하면 Google 계정으로 구독해야 합니다.

내가 현재 목록을 검토하지 않고 있으며 검토해야 한다고 생각하지 않는다는 점은 주목할 가치가 있습니다. 현재 목록으로 즉시 전송되지 않는 유일한 게시물은 Google에서 스팸이라고 생각하는 것입니다.

또한 커밋 알림 외부의 메일링 리스트 트래픽이 0에 가까워지는 것도 가치가 없습니다. 대부분의 상호 작용은 현재 GitHub에서 발생합니다. 나는 우리가 메일링 리스트를 유지해야 한다고 생각하지만 "부담"을 공유하기 위해 리스트의 관리자/조정자가 될 필요가 없다고 생각하지 마십시오. 이 경우에는 "부담"이 없습니다.

PR 볼륨이 극적으로 증가했다면 이를 재고할 수 있지만 지금은 볼륨이 충분히 낮아서 추가 수동 단계가 실제로 중요하지 않다고 생각합니다. 의견 @drakenclimber?

동의. 저는 프로젝트의 이 단계에서 수동 단계를 수행하는 것이 좋습니다. 사실, 그것이 바로 지금 내가 잠시 동안 하고 있는 일입니다.

이 시점에서 @drakenclimber는 당신에게 달려 있다고 생각합니다. 관리자/조정자 액세스를 원하면 Google 계정으로 구독해야 합니다.

나는 우리가 메일링 리스트를 유지해야 한다고 생각하지만 "부담"을 공유하기 위해 리스트의 관리자/조정자가 될 필요가 없다고 생각하지 마십시오. 이 경우에는 "부담"이 없습니다.

맞는 말이다. 괜찮으시다면 제 Gmail 주소를 추가하셔도 됩니다. 딱히 단점이 보이지는 않지만 나중에 도움이 될 수 있습니다. gmail의 tom dot hromatka.

방금 프로젝트 GitHub의 "보안" 탭에서 SECURITY.md 파일을 특별한 방식으로 처리하는 것으로 나타났습니다(CONTRIBUTING.md를 예로 참조). 이 프로세스의 일부로 이 파일을 사용하는 것을 고려해야 합니다.

"보안" 탭을 사용하면 비공개로 패치 작업을 할 수 있도록 프로젝트의 비공개 포크를 생성할 수도 있습니다. 수정 사항이 준비되기 전에 문제를 공개하지 않고도 보안 수정 사항에 대해 더 잘 협력할 수 있다는 점에서 큰 승리가 될 수 있습니다.

정말 멋진 기능입니다. 좋은 발견!

@drakenclimber 방금 위의 댓글에서 문서를 업데이트했습니다. 확인하고 어떻게 생각하는지 알려주세요. 우리는 여전히 SECURITY.md 문서를 짜맞춰야 하지만 꽤 빠를 것입니다(단 몇 문장). 위의 기본 문서에 만족하면 함께 초안을 던질 것입니다.

@drakenclimber 방금 귀하의 Gmail 주소를 Google 그룹에 등록하고 관리자/조정자 액세스 권한을 부여했습니다. 작동하지 않는 경우 알려주십시오.

방금 귀하의 Gmail 주소를 Google 그룹에 등록하고 관리자/조정자 액세스 권한을 부여했습니다. 작동하지 않는 경우 알려주십시오.

작동하는 것 같습니다. 나는 로그인하고 메일 목록에 대한 설정으로 갈 수 있었다. 감사 해요!

방금 위의 댓글에서 문서를 업데이트했습니다. 확인하고 어떻게 생각하는지 알려주세요.

정말 좋아보이네요.

@drakenclimber 는 SECURITY.md 문서의 간단한 초안입니다. 생각은?

libseccomp 보안 취약점 처리 프로세스

https://github.com/seccomp/libseccomp

이 문서 문서는 민감한 보안 관련 버그가 libseccomp 프로젝트에 책임감 있게 공개될 수 있는 프로세스와 프로젝트 관리자가 이러한 보고서를 처리하는 방법을 설명하려고 시도합니다. 다른 libseccomp 프로세스 문서와 마찬가지로 이 문서도 엄격하고 완고한 규정 세트가 아니라 안내 문서로 취급되어야 합니다. 버그 보고자와 프로젝트 유지 관리자는 관련된 모든 당사자에게 가장 적합한 방식으로 문제를 최대한 해결하기 위해 함께 일할 것을 권장합니다.

문제 보고

즉각적인 공개에 적합하지 않은 libseccomp 라이브러리의 문제는 현재 libseccomp 유지 관리자에게 이메일로 보내야 합니다. 목록은 다음과 같습니다. 우리는 일반적으로 문제가 공개되기 전에 문제를 해결하기 위해 최대 90일의 기간을 요청하지만 가능한 한 빨리 문제를 해결하고 공개 기간을 단축하기 위해 모든 노력을 기울일 것입니다.

• 폴 무어, [email protected]
• 톰 흐로마트카, 톰. [email protected]

민감한 보안 문제 해결

버그가 공개되면 유지 관리자는 함께 문제를 조사하고 해결책을 결정해야 합니다. 문제의 조기 공개를 방지하기 위해 솔루션 작업을 하는 사람들은 전통적인 libseccomp 개발 관행을 벗어나 개인적으로 공개해야 합니다. 이에 대한 한 가지 가능한 솔루션은 GitHub "보안" 기능을 활용하여 유지 관리자와 선택적으로 리포터 간에 공유할 수 있는 비공개 개발 포크를 만드는 것입니다. 자리 표시자 GitHub 문제가 생성될 수 있지만 세부 정보는 문제가 수정되고 책임감 있게 공개될 때까지 극히 제한적으로 유지되어야 합니다. CVE 또는 기타 태그가 문제에 할당된 경우 문제가 공개되면 GitHub 문제 제목에 취약점 태그가 포함되어야 합니다.

공개

가능하면 linux-distros 및 oss-security 메일링 리스트에 대한 알림을 포함하여 책임 있는 보고 및 패치 작업을 따라야 합니다.

• https://oss-security.openwall.org/wiki/mailing-lists/distros

그들에게 가장 잘 맞는 방식으로.

nitpick - in a manner which works best for all parties involved. 로 변경하고 싶습니다.

보안 취약점 문서는 정말 좋은 것 같아요. 잘 하셨어요!

그들에게 가장 잘 맞는 방식으로.

nitpick - in a manner which works best for all parties involved. 로 변경하고 싶습니다.

지금 초안을 업데이트하고 있습니다.

나는 우리가 문서/프로세스 업데이트와 함께 PR을 통합할 가치가 있다는 데 충분히 동의했다고 생각합니다. 지금 그렇게 하고 다시 여기에 링크를 게시하겠습니다.

PR 링크(위의 GH 기록에도 포함됨): https://github.com/seccomp/libseccomp/pull/158

이제 @drakenclimber 모든 준비가 완료되었다고 생각합니다.