@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プロジェクトの他のすべての部分と同様に、完全ではないことを認識しています。 変更が必要な場合は、ここで説明するガイドラインに従って変更する必要があります。

パッチの確認とマージ

完璧な世界では、各パッチは各メンテナによって個別にレビューされ、ACKされますが、それは各パッチにとって実用的ではない可能性が高いことを認識しています。 通常の状況では、各パッチは、リポジトリにマージされる前に、単純な過半数のメンテナ（偶数のメンテナの場合、N / 2 + 1）によってACKされる必要があります。 メンテナは、Linuxカーネルと同様の形式を使用してパッチをACKする必要があります。次に例を示します。

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

パッチをリポジトリにマージしたメンテナは、それが正しいことを確認した後、サインオフを追加する必要があります（パッチの送信に関するドキュメントを参照してください）。 メンテナがサインオフを追加することが正しくない場合は、パッチをマージしないでください。 メンテナは、パッチのメタデータの最後に標準形式を使用してサインオフを追加する必要があります。次に例を示します。

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

メンテナは多くの理由で互いにコミュニケーションをとることが奨励されていますが、その1つは、長期間連絡が取れなくなったときに他の人に連絡をとらせることです。 ACKがないためにパッチが保持されていて、他のメンテナが妥当な期間（たとえば、2週間以上の遅延）後に応答しない場合、未処理のNACKがない限り、パッチをマージできます。単純な過半数なし。

機密性の高い脆弱性レポートの管理

libseccompの脆弱性報告プロセスは、SECURITY.mdドキュメントに記載されています。

メンテナはレポーターと協力して、報告された脆弱性の有効性と深刻さを評価する必要があります。 可能な限り、_linux-distros_および_oss-security_メーリングリストへの通知を含め、責任ある報告とパッチ適用の慣行に従う必要があります。

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

GitHub IssueTrackerの管理

GitHub課題追跡システムを使用して、バグ、機能リクエスト、場合によっては未回答の質問を追跡します。 ここでの規則は、さまざまな用途を区別し、それらのカテゴリ内で優先順位を付けるのに役立つことを目的としています。

機能リクエストには、課題名に「RFE：」プレフィックスを追加し、「拡張」ラベルを使用する必要があります。 バグレポートでは、問題名に「BUG：」プレフィックスを追加し、「バグ」ラベルを使用する必要があります。

「優先度/高」、「優先度/中」、「優先度/低」のラベルを使用して、問題に優先順位を付ける必要があります。 意味は明らかになるはずです。

課題には、「保留中/情報」、「保留中/レビュー」、「保留中/改訂」のラベルを追加して、追加情報が必要であること、課題/パッチのレビューが保留中であること、パッチの変更が必要であることを示すことができます。

GitHubリリースマイルストーンの管理

どの時点でも、少なくとも2つのGitHubマイルストーンが必要です。1つは次のメジャー/マイナーリリース（たとえば、v2.5）用で、もう1つは次のパッチリリース（たとえば、v2.4.2）用です。 問題がシステムに入力されると、メンテナの裁量でマイルストーンに追加できます。

パブリックメーリングリストの管理

メーリングリストは現在Googleグループでホストされており、Googleアカウントがなくてもディスカッションに参加できますが、グループを管理/管理するにはGoogleアカウントが必要です。 Googleアカウントを持っていて、モデレーターリストへの追加を希望するメンテナーを追加する必要がありますが、追加する必要はありません。

「モデレーター」という用語にもかかわらず、リストは現在モデレートされておらず、そのままにしておく必要があります。

新しいプロジェクトのリリース

libseccompのリリースプロセスは、RELEASE_PROCESS.mdドキュメントに記載されています。

理想的には、各パッチ/ PRで各メンテナからACKを取得するのが良いと思いますが、それが障害になりすぎるかどうかはわかりませんか？ 私の直感では、libseccompパッチ/ PRは十分に小さいので、これは大きな問題にはならないはずですが、あなたの考えに興味があります

同意しました。 パッチごとにACKを取得するのは良いことだと思いますが、非常に単純なパッチやその他の酌量すべき状況（長期休暇など）の場合は、柔軟性を開いたままにして、それを回避することをお勧めします。 ただし、明らかに他の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がスパムであると考えるものだけです。

コミット通知以外のメーリングリストのトラフィックがゼロに近づいていることも何の価値もありません。ほとんどのやり取りはGitHubで行われています。 メーリングリストはそのままにしておくべきだと思いますが、「負担を分担」するためにリストの管理者・モデレーターになる必要はないと感じてください。この場合、「負担」はありません。

PRの量が劇的に増えた場合は、これを再考できると思いますが、現時点では量が十分に少ないため、追加の手動手順は実際には重要ではないと思います。 意見@drakenclimber？

同意しました。 プロジェクトのこの段階では、手動の手順で問題ありません。 実際、それはまさに私が今しばらくやってきたことです。

この時点で、@ drakenclimberはあなた次第だと思います。 マネージャー/モデレーターのアクセスが必要な場合は、Googleアカウントでサブスクライブする必要があります。

メーリングリストはそのままにしておくべきだと思いますが、「負担を分担」するためにリストの管理者・モデレーターになる必要はないと感じてください。この場合、「負担」はありません。

理にかなっています。 あなたがそれでかっこいいなら、あなたは私のGmailアドレスを追加することを歓迎します。 マイナス面はあまり見られませんが、後で役立つ可能性があります。 Gmailのトムドット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日間の対応をお願いしておりますが、できる限り迅速に対応し、開示期間を短縮するよう努めます。

• ポール・ムーア、 paul @ paul-moore.com
• トム・フロマトカ、トム。 [email protected]

機密性の高いセキュリティ問題の解決

バグが開示されたら、メンテナは協力して問題を調査し、解決策を決定する必要があります。 問題の早期開示を防ぐために、ソリューションに取り組んでいる人は、非公開で、従来のlibseccomp開発慣行の外でそうする必要があります。 これに対する1つの可能な解決策は、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履歴にも含まれています）： //github.com/seccomp/libseccomp/pull/158

@drakenclimberですべての設定が