drakenclimber ، سأضع مخططًا سريعًا لمستند MAINTAINER_PROCESS.md يمكننا مناقشته / تحريره ، لكن ما زلت أحاول إنهاء إصدار v2.4.0 الآن ، ومن المحتمل أن أحتاج إلى بضعة أيام تميل إلى بعض القضايا الأخرى غير ذات الصلة والمهملة :)

pcmoore - لا تقلق. عمل جيد على إصدار v2.4 بالمناسبة! اسمحوا لي أن أعرف كيف يمكنني المساعدة.

لا تتردد في استخدامي كخنزير غينيا لأننا نقوم بتصحيح العملية :)

عمل جيد على إصدار v2.4 بالمناسبة! اسمحوا لي أن أعرف كيف يمكنني المساعدة.

مهما كان الاختبار الذي يمكنك القيام به فهو مفيد في هذه المرحلة. أشعر بالرضا حيال جودة هذا الإصدار ، لكن الكثير من الأجزاء الصعبة تغيرت لذا فليس من غير المعقول أن نتخيل كسر بعض الحالات في بعض التطبيقات. أنا متفائل بأننا لن نضطر لعمل إصدار "حقيبة بنية اللون" v2.4.1 ، لكنك لا تعرف أبدًا.

لا تتردد في استخدامي كخنزير غينيا لأننا نقوم بتصحيح العملية :)

سعيد لسماع أقول لكم أن becasue كنت خنزير غينيا.)

drakenclimber أقوم بحجز هذا التعليق لمسودة مستند MAINTAINER_PROCESS.md (أعتقد أنه يمكنني الاستمرار في تحريره هنا بناءً على التعليقات). لا تتردد في إرسال أي أفكار لديك حول هذه المشكلة وسأضع بيانًا عامًا لهذا الأمر بمجرد اقترابنا من شيء ما.

عملية صيانة libseccomp

https://github.com/seccomp/libseccomp

يحاول هذا المستند وصف العمليات التي يجب أن يتبعها مشرفو libseccomp المتنوعون. لا يُقصد منه أن يكون متطلبًا صعبًا ، ولكن كوثيقة إرشادية تهدف إلى تسهيل إدارة مشروع libseccomp على العديد من المشرفين المشتركين.

نحن ندرك أن هذه الوثيقة ، مثل جميع الأجزاء الأخرى من مشروع libseccomp ، ليست مثالية. إذا كانت هناك حاجة لإجراء تغييرات ، فيجب إجراؤها باتباع الإرشادات الموضحة هنا.

مراجعة ودمج التصحيحات

في عالم مثالي ، ستتم مراجعة كل رقعة بشكل مستقل وسيحصل كل مشرف على ACK ، لكننا ندرك أن هذا ليس من المحتمل أن يكون عمليًا لكل رقعة. في ظل الظروف العادية ، يجب أن تحصل كل رقعة على ACK بأغلبية بسيطة من المشرفين (في حالة وجود عدد زوجي من المشرفين ، N / 2 + 1) قبل دمجها في المستودع. يجب على القائمين بالحفاظ على تصحيحات ACK باستخدام تنسيق مشابه لـ Linux Kernel ، على سبيل المثال:

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

يجب على المشرف الذي قام بدمج التصحيح في المستودع إضافة توقيعه بعد التأكد من صحة القيام بذلك (راجع الوثائق الخاصة بتقديم التصحيحات) ؛ إذا لم يكن صحيحًا أن يضيف المشرف تسجيل الخروج ، فمن المحتمل أنه لا ينبغي دمج التصحيح. يجب أن يضيف المشرف تسجيل الخروج الخاص به باستخدام التنسيق القياسي في نهاية البيانات الوصفية للتصحيح ، على سبيل المثال:

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

يتم تشجيع القائمين على الصيانة على التواصل مع بعضهم البعض لأسباب عديدة ، أحدها هو السماح للآخرين عندما يتعذر الوصول إلى أحدهم لفترة طويلة من الزمن. إذا تم تعليق التصحيح بسبب نقص ACK ولم يستجيب المشرفون الآخرون بعد فترة زمنية معقولة (على سبيل المثال ، تأخير لأكثر من أسبوعين) ، طالما أنه لا توجد NACKs معلقة ، فيمكن دمج التصحيح بدون أغلبية بسيطة.

إدارة تقارير الثغرات الأمنية الحساسة

تم توثيق عملية الإبلاغ عن الثغرات الأمنية libseccomp في مستند SECURITY.md.

يجب أن يعمل القائمون على الصيانة مع المراسل لتقييم صحة وخطورة الثغرة الأمنية المبلغ عنها. كلما كان ذلك ممكنًا ، يجب اتباع ممارسات الإبلاغ والتصحيح المسؤولة ، بما في ذلك الإخطار إلى القوائم البريدية _linux-distros_ و _oss-security_.

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

إدارة GitHub Issue Tracker

نستخدم أداة تعقب المشكلات من GitHub لتتبع الأخطاء وطلبات الميزات والأسئلة التي لم تتم الإجابة عليها في بعض الأحيان. تهدف الاتفاقيات هنا إلى المساعدة في التمييز بين الاستخدامات المختلفة ، وتحديد الأولويات ضمن تلك الفئات.

يجب أن تحتوي طلبات الميزات على بادئة "RFE:" مضافة إلى اسم المشكلة واستخدام تصنيف "التحسين". يجب أن تكون تقارير الأخطاء عبارة عن بادئة "BUG:" مضافة إلى اسم المشكلة واستخدام تصنيف "الخطأ".

يجب إعطاء الأولوية للمشكلات باستخدام تسميات "الأولوية / عالية" و "الأولوية / المتوسطة" و "الأولوية / المنخفضة". نأمل أن يكون المعنى واضحًا.

يمكن أيضًا تسمية المشكلات بعلامات "معلق / معلومات" و "معلق / مراجعة" و "معلق / مراجعة" للإشارة إلى الحاجة إلى معلومات إضافية ، وأن المشكلة / التصحيح معلق للمراجعة و / أو يتطلب التصحيح تغييرات.

إدارة مراحل إصدار GitHub

يجب أن يكون هناك ما لا يقل عن اثنين من معالم GitHub الرئيسية في أي وقت: واحد للإصدار الرئيسي / الثانوي التالي (على سبيل المثال ، v2.5) ، والآخر لإصدار التصحيح التالي (على سبيل المثال ، v2.4.2). عند إدخال المشكلات في النظام ، يمكن إضافتها إلى الأحداث الرئيسية وفقًا لتقدير القائمين على الصيانة.

إدارة القائمة البريدية العامة

القائمة البريدية مستضافة حاليًا على مجموعات Google ، وبينما من الممكن المشاركة في المناقشات بدون حساب Google ، يلزم وجود حساب Google للإشراف / إدارة المجموعة. يجب إضافة المشرفين الذين لديهم حساب Google ويرغبون في أن يتم إضافتهم إلى قائمة الوسطاء ، ولكن لا يوجد شرط للقيام بذلك.

على الرغم من مصطلح "وسيط" ، فإن القائمة حاليًا غير خاضعة للإشراف ويجب أن تظل كذلك.

إصدارات المشروع الجديد

تم توثيق عملية إصدار libseccomp في مستند RELEASE_PROCESS.md.

من الناحية المثالية ، أعتقد أنه سيكون من الجيد الحصول على ACK من كل مشرف على كل رقعة / علاقات عامة ، لكنني لست متأكدًا مما إذا كان ذلك سيكون بمثابة عقبة كبيرة جدًا؟ شعوري الغريزي هو أن تصحيحات libseccomp / PRs منخفضة الحجم بدرجة كافية بحيث لا ينبغي أن تكون هذه مشكلة كبيرة ولكني أشعر بالفضول فيما تعتقده

متفق. أعتقد أن السعي للحصول على ACK لكل رقعة سيكون أمرًا جيدًا ، لكن قد نرغب في ترك المرونة مفتوحة لتجاوز ذلك بالنسبة إلى التصحيحات البسيطة حقًا ، أو الظروف المخففة الأخرى (الإجازات الطويلة ، وما إلى ذلك). من الواضح أن تجاوز ACKs الأخرى يجب أن يكون الاستثناء وليس القاعدة.

بصرف النظر عما سبق ، أعتقد أن التصحيحات من أي مشرف معين تحتاج إلى ACK ويلتزم بها مشرف مختلف.

ستكون هذه بالتأكيد عادة جيدة للدخول فيها. يجب أن يساعد في تجنب الأخطاء السخيفة.

نحتاج أيضًا إلى توثيق كيفية التعامل مع دمج العلاقات العامة والتصحيحات ، مثل تسجيل خروج المشرف ، والقيام بذلك يدويًا وعدم استخدام أدوات GitHub ، إلخ.

سأكون مهتمًا برؤية العملية التي توصي بها. هل هناك سبب يمنعنا من استخدام أدوات جيثب المدمجة؟

أعتقد أن المفتاح هنا هو سرد جميع القائمين على الصيانة في القسم المناسب في README.md والإشارة إلى أنه يجب على القائمين على الصيانة العمل معًا لحل المشكلة واتباع عمليات الكشف المسؤولة المناسبة. يجب أن نقوم بتضمين روابط إلى لينكس-توزيعات وقوائم أمان نظام التشغيل.

نعم ، يعد توفير طريقة سهلة وآمنة للآخرين للإبلاغ عن المشكلات أمرًا بالغ الأهمية. أنا موافق.

متفق. أعتقد أن السعي للحصول على ACK لكل رقعة سيكون أمرًا جيدًا ، لكن قد نرغب في ترك المرونة مفتوحة لتجاوز ذلك بالنسبة إلى التصحيحات البسيطة حقًا ، أو الظروف المخففة الأخرى (الإجازات الطويلة ، وما إلى ذلك). من الواضح أن تجاوز ACKs الأخرى يجب أن يكون الاستثناء وليس القاعدة.

نقاط جيدة ، أوافق.

نحتاج أيضًا إلى توثيق كيفية التعامل مع دمج العلاقات العامة والتصحيحات ، مثل تسجيل خروج المشرف ، والقيام بذلك يدويًا وعدم استخدام أدوات GitHub ، إلخ.

سأكون مهتمًا برؤية العملية التي توصي بها. هل هناك سبب يمنعنا من استخدام أدوات جيثب المدمجة؟

تعجبني حقًا فكرة أن كل شخص يلمس أحد التصحيح ، إما عن طريق تأليفه أو إلزامه في الريبو الرئيسي ، يضيف صراحة تسجيله إلى الملف. أعتقد أيضًا حقًا أن المشرفين يجب أن يفعلوا make check على نظامهم المحلي قبل دفع أي شيء إلى الريبو الرئيسي. لا يسمح دمج العلاقات العامة مباشرة من داخل واجهة GitHub فعلاً بأي من هذه الأشياء.

أتخيل أنه إذا زاد حجم العلاقات العامة بشكل كبير ، يمكننا إعادة النظر في ذلك ، ولكن الآن الحجم منخفض بما يكفي لأن الخطوات اليدوية الإضافية ليست مهمة حقًا في رأيي.

آراءdrakenclimber؟

لقد نظرت للتو في القائمة البريدية لمجموعات Google ويبدو أنه لا يمكنني استخدام حساب / عنوان oracle.com الخاص بك كحساب مدير / مشرف ، يجب أن يكون حساب Google. في هذه المرحلة ، أعتقد أن الأمر متروك لكdrakenclimber ؛ إذا كنت تريد وصول المدير / المشرف ، فستحتاج إلى الاشتراك باستخدام حساب Google.

تجدر الإشارة إلى أنني لا أدير القائمة حاليًا ولا أعتقد أنه يجب الإشراف عليها. في الوقت الحالي ، المشاركات الوحيدة التي لم يتم إرسالها على الفور إلى القائمة هي الأشياء التي تعتقد Google أنها رسائل اقتحامية.

لا يستحق الأمر أيضًا أن حركة المرور في القائمة البريدية خارج إشعارات الالتزام تقترب من الصفر ، حيث يحدث معظم التفاعل على GitHub الآن. بينما أعتقد أنه يجب علينا الاحتفاظ بالقائمة البريدية ، من فضلك لا تشعر أنك بحاجة إلى أن تكون مديرًا / مشرفًا على القائمة من أجل "مشاركة العبء" ، فلا يوجد "عبء" في هذه الحالة.

أتخيل أنه إذا زاد حجم العلاقات العامة بشكل كبير ، يمكننا إعادة النظر في ذلك ، ولكن الآن الحجم منخفض بما يكفي لأن الخطوات اليدوية الإضافية ليست مهمة حقًا في رأيي. آراءdrakenclimber؟

متفق. أنا بخير مع خطوة يدوية في هذه المرحلة من المشروع. في الواقع ، هذا بالضبط ما كنت أفعله منذ فترة الآن.

في هذه المرحلة ، أعتقد أن الأمر متروك لكdrakenclimber ؛ إذا كنت تريد وصول المدير / المشرف ، فستحتاج إلى الاشتراك باستخدام حساب Google.

بينما أعتقد أنه يجب علينا الاحتفاظ بالقائمة البريدية ، من فضلك لا تشعر أنك بحاجة إلى أن تكون مديرًا / مشرفًا على القائمة من أجل "مشاركة العبء" ، فلا يوجد "عبء" في هذه الحالة.

من المنطقي. مرحبًا بك في إضافة عنوان gmail الخاص بي إذا كنت رائعًا مع ذلك ؛ لا أرى حقًا جانبًا سلبيًا ، لكن قد يكون مفيدًا لاحقًا. توم دوت هيروماتكا في بريد جوجل.

لقد لاحظت للتو أنه تحت علامة التبويب "الأمان" للمشروع يبدو أن 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 "Security" لإنشاء مفترق تطوير خاص يمكن مشاركته بين المشرفين ، واختيارياً المراسل. قد يتم إنشاء مشكلة عنصر نائب على GitHub ، ولكن يجب أن تظل التفاصيل محدودة للغاية حتى يحين الوقت الذي يتم فيه إصلاح المشكلة والكشف عنها بشكل مسؤول. إذا تم تعيين CVE أو علامة أخرى للمشكلة ، فيجب أن يتضمن عنوان مشكلة GitHub علامة الثغرة الأمنية بمجرد الكشف عن المشكلة.

الكشف العلني

كلما كان ذلك ممكنًا ، يجب اتباع ممارسات الإبلاغ والتصحيح المسؤولة ، بما في ذلك الإخطار إلى القوائم البريدية لنظام التشغيل Linux-distros و OS-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.

يعجبني ذلك ، تحديث المسودة الآن.

أعتقد أننا متفقون بشكل كاف على أن الأمر يستحق تجميع العلاقات العامة مع تحديثات المستند / العملية ، سأفعل ذلك الآن وأرسل رابطًا هنا مرة أخرى.

رابط العلاقات العامة (مضمن أيضًا في سجل GH أعلاه): https://github.com/seccomp/libseccomp/pull/158

أعتقد أنك جاهز الآن غريب ،