@drakenclimber मैं एक प्रस्तुत करूंगा जिस पर हम चर्चा/संपादित कर सकते हैं, लेकिन मैं अभी भी v2.4.0 रिलीज को लपेटने की कोशिश कर रहा हूं, और मुझे कुछ दिनों की आवश्यकता होगी कुछ अन्य असंबंधित और उपेक्षित मुद्दों पर ध्यान दें :)

@pcmoore - कोई चिंता नहीं। वैसे v2.4 रिलीज पर अच्छा काम! मुझे बताएं कि मैं कैसे मदद कर सकता हूं।

बेझिझक मुझे एक गिनी पिग के रूप में उपयोग करें क्योंकि हम प्रक्रिया को सीधा करते हैं :)

वैसे v2.4 रिलीज पर अच्छा काम! मुझे बताएं कि मैं कैसे मदद कर सकता हूं।

इस समय आप जो भी परीक्षण कर सकते हैं वह सहायक है। मैं इस रिलीज की गुणवत्ता के बारे में बहुत अच्छा महसूस करता हूं, लेकिन बहुत सी मुश्किल बिट्स बदल गई हैं, इसलिए यह कल्पना करना अनुचित नहीं है कि कुछ एप्लिकेशन में कुछ कोने का मामला टूट गया। मुझे उम्मीद है कि हमें "ब्राउन बैग" v2.4.1 रिलीज नहीं करना पड़ेगा, लेकिन आप कभी नहीं जानते।

बेझिझक मुझे एक गिनी पिग के रूप में उपयोग करें क्योंकि हम प्रक्रिया को सीधा करते हैं :)

आप का कहना है कि क्योंकि आप गिनी पिग हैं सुनने के लिए खुशी है कि;)

@drakenclimber मैं इस टिप्पणी को

libseccomp अनुरक्षक प्रक्रिया

https://github.com/seccomp/libseccomp

यह दस्तावेज़ उन प्रक्रियाओं का वर्णन करने का प्रयास करता है जिनका पालन विभिन्न libseccomp अनुरक्षकों द्वारा किया जाना चाहिए। यह एक कठिन आवश्यकता के रूप में अभिप्रेत नहीं है, बल्कि एक मार्गदर्शक दस्तावेज के रूप में है, जिसका उद्देश्य कई सह-रखरखावों के लिए libseccomp परियोजना का प्रबंधन करना आसान बनाना है।

हम मानते हैं कि यह दस्तावेज़, libseccomp प्रोजेक्ट के अन्य सभी भागों की तरह, सही नहीं है। यदि परिवर्तन करने की आवश्यकता है, तो उन्हें यहां वर्णित दिशानिर्देशों का पालन करते हुए किया जाना चाहिए।

पैच की समीक्षा करना और विलय करना

एक आदर्श दुनिया में प्रत्येक पैच की स्वतंत्र रूप से समीक्षा की जाएगी और प्रत्येक रखरखाव द्वारा ACK'd किया जाएगा, लेकिन हम मानते हैं कि प्रत्येक पैच के लिए व्यावहारिक होने की संभावना नहीं है। सामान्य परिस्थितियों में, प्रत्येक पैच को रिपोजिटरी में विलय करने से पहले रखरखाव के एक साधारण बहुमत (रखरखावों की एक समान संख्या के मामले में, N/2+1) द्वारा ACK'd किया जाना चाहिए। अनुरक्षकों को उदाहरण के लिए, Linux कर्नेल के समान प्रारूप का उपयोग करके ACK पैच करना चाहिए:

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

रिपोजिटरी में पैच को मर्ज करने वाले अनुरक्षक को यह सुनिश्चित करने के बाद अपना साइन-ऑफ जोड़ना चाहिए कि ऐसा करना सही है (पैच जमा करने पर दस्तावेज़ देखें); यदि अनुरक्षक के लिए अपना साइन-ऑफ जोड़ना सही नहीं है, तो संभव है कि उन्हें पैच मर्ज नहीं किया जाना चाहिए। अनुरक्षक को पैच के मेटाडेटा के अंत में मानक प्रारूप का उपयोग करके अपना साइन-ऑफ जोड़ना चाहिए, उदाहरण के लिए:

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

अनुरक्षकों को कई कारणों से एक-दूसरे के साथ संवाद करने के लिए प्रोत्साहित किया जाता है, जिनमें से एक यह है कि जब एक विस्तारित अवधि के लिए पहुंच से बाहर हो तो दूसरों को जाने दें। यदि एसीके की कमी के कारण एक पैच आयोजित किया जा रहा है और अन्य रखरखाव उचित समय के बाद प्रतिक्रिया नहीं दे रहे हैं (उदाहरण के लिए, दो सप्ताह से अधिक की देरी), जब तक कोई बकाया एनएके नहीं हैं, पैच को विलय किया जा सकता है साधारण बहुमत के बिना।

संवेदनशील सुभेद्यता रिपोर्ट प्रबंधित करना

libseccomp भेद्यता रिपोर्टिंग प्रक्रिया को SECURITY.md दस्तावेज़ में प्रलेखित किया गया है।

रिपोर्ट की गई भेद्यता की वैधता और गंभीरता का आकलन करने के लिए अनुरक्षकों को रिपोर्टर के साथ मिलकर काम करना चाहिए। जब भी संभव हो, जिम्मेदार रिपोर्टिंग और पैचिंग प्रथाओं का पालन किया जाना चाहिए, जिसमें _linux-distros_ और _oss-security_ मेलिंग सूचियों की अधिसूचना शामिल है।

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

गिटहब इश्यू ट्रैकर का प्रबंधन

हम बग, फीचर अनुरोधों और कभी-कभी अनुत्तरित प्रश्नों को ट्रैक करने के लिए गिटहब इश्यू ट्रैकर का उपयोग करते हैं। यहां सम्मेलनों का उद्देश्य विभिन्न उपयोगों के बीच अंतर करने और उन श्रेणियों के भीतर प्राथमिकता देने में मदद करना है।

फ़ीचर अनुरोधों में समस्या के नाम में "RFE:" उपसर्ग जोड़ा जाना चाहिए और "एन्हांसमेंट" लेबल का उपयोग करना चाहिए। बग रिपोर्ट में समस्या के नाम में "बग:" उपसर्ग जोड़ा जाना चाहिए और "बग" लेबल का उपयोग करना चाहिए।

मुद्दों को "प्राथमिकता/उच्च", "प्राथमिकता/माध्यम", और "प्राथमिकता/निम्न" लेबल का उपयोग करके प्राथमिकता दी जानी चाहिए। अर्थ उम्मीद से स्पष्ट होना चाहिए।

मुद्दों को अतिरिक्त रूप से "लंबित/जानकारी", "लंबित/समीक्षा", और "लंबित/संशोधन" लेबल के साथ लेबल किया जा सकता है ताकि यह इंगित किया जा सके कि अतिरिक्त जानकारी की आवश्यकता है, समस्या/पैच की समीक्षा लंबित है, और/या पैच में बदलाव की आवश्यकता है।

गिटहब रिलीज मील के पत्थर का प्रबंधन

किसी भी समय कम से कम दो गिटहब मील के पत्थर होने चाहिए: एक अगले प्रमुख/मामूली रिलीज के लिए (उदाहरण के लिए, v2.5), और अगले पैच रिलीज के लिए एक (उदाहरण के लिए, v2.4.2)। जैसे ही मुद्दों को सिस्टम में दर्ज किया जाता है, उन्हें अनुरक्षकों के विवेक पर मील के पत्थर में जोड़ा जा सकता है।

सार्वजनिक मेलिंग सूची का प्रबंधन

मेलिंग सूची वर्तमान में Google समूह पर होस्ट की गई है, और जबकि Google खाते के बिना चर्चा में भाग लेना संभव है, समूह को मॉडरेट/व्यवस्थापन करने के लिए एक Google खाते की आवश्यकता होती है। वे अनुरक्षक जिनके पास एक Google खाता है और जो मॉडरेटर सूची में शामिल होना चाहते हैं, उन्हें जोड़ा जाना चाहिए, लेकिन ऐसा करने की कोई आवश्यकता नहीं है।

"मॉडरेटर" शब्द के बावजूद सूची वर्तमान में अनियंत्रित है और इसे वैसे ही रहना चाहिए।

नई परियोजना विज्ञप्ति

libseccomp रिलीज़ प्रक्रिया RELEASE_PROCESS.md दस्तावेज़ में प्रलेखित है।

आदर्श रूप से मुझे लगता है कि प्रत्येक पैच/पीआर पर प्रत्येक रखरखाव से एसीके प्राप्त करना अच्छा होगा, लेकिन मुझे यकीन नहीं है कि यह एक रोडब्लॉक का बहुत अधिक होगा? मेरी आंत की भावना यह है कि libseccomp पैच/पीआर पर्याप्त मात्रा में कम हैं कि यह एक बड़ी समस्या नहीं होनी चाहिए, लेकिन मैं उत्सुक हूं कि आप क्या सोचते हैं

माना। मुझे लगता है कि प्रत्येक पैच के लिए एसीके के लिए प्रयास करना अच्छा होगा, लेकिन हम वास्तव में साधारण पैच, या अन्य विलुप्त होने वाली परिस्थितियों (लंबी छुट्टियां, आदि) के लिए इसे बाईपास करने के लिए लचीलापन छोड़ना चाहेंगे। स्पष्ट रूप से अन्य एसीके को छोड़कर अपवाद होना चाहिए, हालांकि आदर्श नहीं होना चाहिए।

उपर्युक्त के बावजूद, मुझे लगता है कि किसी दिए गए रखरखाव से पैच को एक अलग रखरखाव द्वारा एसीके और प्रतिबद्ध किया जाना चाहिए।

इसमें शामिल होने की निश्चित रूप से एक अच्छी आदत होगी। इसे मूर्खतापूर्ण गलतियों से बचने में मदद करनी चाहिए।

हमें मर्जिंग पीआर और पैच को कैसे हैंडल करना है, जैसे कि मेंटेनर साइन-ऑफ, इसे हाथ से करना और गिटहब टूल्स का उपयोग न करना आदि का दस्तावेजीकरण करने की आवश्यकता है।

मुझे आपके द्वारा सुझाई गई प्रक्रिया को देखने में दिलचस्पी होगी। क्या कोई कारण है कि हमें बिल्ट-इन जीथब टूल्स से बचना चाहिए?

मुझे लगता है कि यहां कुंजी सभी अनुरक्षकों को README.md में उपयुक्त अनुभाग में सूचीबद्ध करना है और उल्लेख करना है कि अनुरक्षकों को समस्या को हल करने के लिए मिलकर काम करना चाहिए और उचित जिम्मेदार प्रकटीकरण प्रक्रियाओं का पालन करना चाहिए। हमें linux-distros और oss-security सूचियों के लिंक शामिल करने चाहिए।

हां, दूसरों को समस्याओं की रिपोर्ट करने के लिए एक आसान और सुरक्षित तरीका प्रदान करना महत्वपूर्ण है। मैं सहमत हूं।

माना। मुझे लगता है कि प्रत्येक पैच के लिए एसीके के लिए प्रयास करना अच्छा होगा, लेकिन हम वास्तव में साधारण पैच, या अन्य विलुप्त होने वाली परिस्थितियों (लंबी छुट्टियां, आदि) के लिए इसे बाईपास करने के लिए लचीलापन छोड़ना चाहेंगे। स्पष्ट रूप से अन्य एसीके को छोड़कर अपवाद होना चाहिए, हालांकि आदर्श नहीं होना चाहिए।

अच्छे अंक, मैं सहमत हूँ।

हमें मर्जिंग पीआर और पैच को कैसे हैंडल करना है, जैसे कि मेंटेनर साइन-ऑफ, इसे हाथ से करना और गिटहब टूल्स का उपयोग न करना आदि का दस्तावेजीकरण करने की आवश्यकता है।

मुझे आपके द्वारा सुझाई गई प्रक्रिया को देखने में दिलचस्पी होगी। क्या कोई कारण है कि हमें बिल्ट-इन जीथब टूल्स से बचना चाहिए?

मुझे वास्तव में यह विचार पसंद है कि हर कोई जो पैच को छूता है, या तो इसे संलेखित करके या इसे मुख्य रेपो में भेजकर, स्पष्ट रूप से फ़ाइल में अपना साइन-ऑफ जोड़ता है। मैं वास्तव में यह भी सोचता हूं कि मुख्य रेपो में कुछ भी धकेलने से पहले अनुरक्षकों को अपने स्थानीय सिस्टम पर make check करना चाहिए। पीआर को सीधे गिटहब इंटरफ़ेस के भीतर से मर्ज करना वास्तव में किसी को भी उन चीजों को करने की अनुमति नहीं देता है।

मुझे लगता है कि अगर पीआर वॉल्यूम कभी नाटकीय रूप से बढ़ता है तो हम इस पर पुनर्विचार कर सकते हैं, लेकिन अभी वॉल्यूम इतना कम है कि अतिरिक्त मैनुअल कदम वास्तव में मेरी राय में महत्वपूर्ण नहीं हैं।

राय @drakenclimber?

मैंने अभी-अभी Google समूह की मेलिंग सूची को देखा और ऐसा लगता है कि मैं आपके oracle.com खाते/पते का उपयोग प्रबंधक/मॉडरेटर खाते के रूप में नहीं कर सकता, यह एक Google खाता होना चाहिए। इस बिंदु पर मुझे लगता है कि यह आप पर निर्भर है @drakenclimber; यदि आप प्रबंधक/मॉडरेटर पहुंच चाहते हैं तो आपको Google खाते से सदस्यता लेनी होगी।

यह ध्यान देने योग्य है कि मैं वर्तमान में सूची को मॉडरेट नहीं करता, और मुझे नहीं लगता कि इसे मॉडरेट किया जाना चाहिए। वर्तमान में केवल वही पोस्ट जो सूची में तुरंत नहीं भेजी जाती हैं, वे चीजें हैं जिन्हें Google स्पैम मानता है।

यह भी व्यर्थ है कि कमिट नोटिफिकेशन के बाहर मेलिंग सूची पर ट्रैफ़िक शून्य के करीब पहुंच रहा है, अधिकांश इंटरैक्शन अब GitHub पर होता है। जबकि मुझे लगता है कि हमें मेलिंग सूची को इधर-उधर रखना चाहिए, कृपया यह महसूस न करें कि "बोझ साझा करने" के लिए आपको सूची का प्रबंधक/मॉडरेटर होने की आवश्यकता है, इस मामले में कोई "बोझ" नहीं है।

मुझे लगता है कि अगर पीआर वॉल्यूम कभी नाटकीय रूप से बढ़ता है तो हम इस पर पुनर्विचार कर सकते हैं, लेकिन अभी वॉल्यूम इतना कम है कि अतिरिक्त मैनुअल कदम वास्तव में मेरी राय में महत्वपूर्ण नहीं हैं। राय @drakenclimber?

माना। मैं परियोजना के इस चरण में एक मैनुअल कदम के साथ ठीक हूँ। वास्तव में, मैं अभी कुछ समय से यही कर रहा हूं।

इस बिंदु पर मुझे लगता है कि यह आप पर निर्भर है @drakenclimber; यदि आप प्रबंधक/मॉडरेटर पहुंच चाहते हैं तो आपको Google खाते से सदस्यता लेनी होगी।

जबकि मुझे लगता है कि हमें मेलिंग सूची को इधर-उधर रखना चाहिए, कृपया यह महसूस न करें कि "बोझ साझा करने" के लिए आपको सूची का प्रबंधक/मॉडरेटर होने की आवश्यकता है, इस मामले में कोई "बोझ" नहीं है।

समझ में आता है। यदि आप इसके साथ अच्छे हैं तो मेरा जीमेल पता जोड़ने के लिए आपका स्वागत है; मैं वास्तव में एक नकारात्मक पहलू नहीं देखता, लेकिन यह बाद में मददगार साबित हो सकता है। टॉम डॉट hromatka जीमेल पर।

मैंने अभी देखा है कि प्रोजेक्ट के लिए "सुरक्षा" टैब के तहत गिटहब SECURITY.md फ़ाइल को एक विशेष तरीके से संभालता है (उदाहरण के रूप में CONTRIBUTING.md देखें)। हमें इस प्रक्रिया के हिस्से के रूप में इस फाइल का उपयोग करने पर विचार करना चाहिए।

"सुरक्षा" टैब आपको परियोजना का एक निजी कांटा बनाने की भी अनुमति देता है ताकि आप निजी तौर पर पैच पर काम कर सकें; यह एक बड़ी जीत हो सकती है क्योंकि यह हमें फिक्स तैयार होने से पहले समस्या को सार्वजनिक किए बिना सुरक्षा सुधारों पर बेहतर सहयोग करने की अनुमति देता है।

यह वास्तव में बहुत अच्छा फीचर है। अच्छा खोज!

@drakenclimber मैंने अभी ऊपर टिप्पणी में डॉक्टर को अपडेट किया है, इसे देखें और मुझे बताएं कि आप क्या सोचते हैं। हमें अभी भी एक SECURITY.md दस्तावेज़ को एक साथ जोड़ने की आवश्यकता है, लेकिन यह बहुत तेज़ होना चाहिए (बस कुछ वाक्य); जब आप ऊपर दिए गए मुख्य दस्तावेज़ से संतुष्ट होंगे, तब मैं एक साथ एक ड्राफ़्ट प्रस्तुत करूँगा।

@drakenclimber मैंने अभी-अभी आपके gmail पते को Google समूह में सब्सक्राइब किया है और आपको प्रबंधक/मॉडरेटर एक्सेस दिया है, अगर यह काम नहीं कर रहा है तो मुझे बताएं।

मैंने अभी-अभी Google समूह में आपके gmail पते की सदस्यता ली है और आपको प्रबंधक/मॉडरेटर पहुंच प्रदान की है, अगर यह काम नहीं कर रहा है तो मुझे बताएं।

ऐसा लगता है कि यह काम कर रहा है। मैं लॉगिन करने और मेल सूची के लिए सेटिंग्स में जाने में सक्षम था। धन्यवाद!

मैंने अभी ऊपर टिप्पणी में दस्तावेज़ को अपडेट किया है, इसे देखें और मुझे बताएं कि आप क्या सोचते हैं।

मुझे वाकई बहुत अच्छा लग रहा है।

@drakenclimber यहाँ एक SECURITY.md दस्तावेज़ का एक त्वरित मसौदा है, विचार?

libseccomp सुरक्षा भेद्यता प्रबंधन प्रक्रिया

https://github.com/seccomp/libseccomp

यह दस्तावेज़ दस्तावेज़ उन प्रक्रियाओं का वर्णन करने का प्रयास करता है जिनके माध्यम से संवेदनशील सुरक्षा संबंधित बग को libseccomp प्रोजेक्ट के लिए जिम्मेदारी से प्रकट किया जा सकता है और प्रोजेक्ट अनुरक्षकों को इन रिपोर्टों को कैसे संभालना चाहिए। अन्य libseccomp प्रक्रिया दस्तावेज़ों की तरह, इस दस्तावेज़ को एक मार्गदर्शक दस्तावेज़ के रूप में माना जाना चाहिए, न कि नियमों का एक कठिन, अडिग सेट; बग रिपोर्टरों और परियोजना अनुरक्षकों को मुद्दों का यथासंभव समाधान करने के लिए एक साथ काम करने के लिए प्रोत्साहित किया जाता है, इस तरीके से जो शामिल सभी पक्षों के लिए सबसे अच्छा काम करता है।

रिपोर्टिंग समस्याएं

libseccomp लाइब्रेरी की समस्याएं जो तत्काल सार्वजनिक प्रकटीकरण के लिए उपयुक्त नहीं हैं, उन्हें वर्तमान libseccomp अनुरक्षकों को ईमेल किया जाना चाहिए, सूची नीचे दी गई है। हम आम तौर पर इस मुद्दे को सार्वजनिक करने से पहले इसे संबोधित करने के लिए अधिकतम 90 दिनों की समयावधि का अनुरोध करते हैं, लेकिन हम इस मुद्दे को जल्द से जल्द हल करने और प्रकटीकरण विंडो को छोटा करने का हर संभव प्रयास करेंगे।

• पॉल मूर, [email protected]
• टॉम होरोमैटका, टॉम। [email protected]

संवेदनशील सुरक्षा मुद्दों का समाधान

बग के प्रकट होने पर, अनुरक्षकों को समस्या की जांच करने और समाधान पर निर्णय लेने के लिए मिलकर काम करना चाहिए। समस्या के शीघ्र प्रकटीकरण को रोकने के लिए, समाधान पर काम करने वालों को निजी तौर पर और पारंपरिक libseccomp विकास प्रथाओं के बाहर ऐसा करना चाहिए। इसका एक संभावित समाधान एक निजी विकास कांटा बनाने के लिए गिटहब "सुरक्षा" कार्यक्षमता का लाभ उठाना है जिसे अनुरक्षकों और वैकल्पिक रूप से रिपोर्टर के बीच साझा किया जा सकता है। एक प्लेसहोल्डर गिटहब मुद्दा बनाया जा सकता है, लेकिन जब तक समस्या को ठीक नहीं किया जाता है और जिम्मेदारी से खुलासा नहीं किया जाता है तब तक विवरण बेहद सीमित रहना चाहिए। यदि समस्या के लिए कोई CVE, या अन्य टैग असाइन किया गया है, तो समस्या के प्रकट होने के बाद GitHub समस्या शीर्षक में भेद्यता टैग शामिल होना चाहिए।

सार्वजनिक प्रकटीकरण

जब भी संभव हो, जिम्मेदार रिपोर्टिंग और पैचिंग प्रथाओं का पालन किया जाना चाहिए, जिसमें linux-distros और oss-security मेलिंग सूचियों की अधिसूचना शामिल है।

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

इस तरह से जो उनके लिए सबसे अच्छा काम करता है।

नाइटपिक - मैं इसे in a manner which works best for all parties involved. बदलने का लुत्फ उठाऊंगा

मुझे लगता है कि सुरक्षा भेद्यता दस्तावेज़ वास्तव में अच्छा दिखता है। अच्छा काम!

इस तरह से जो उनके लिए सबसे अच्छा काम करता है।

नाइटपिक - मैं इसे in a manner which works best for all parties involved. बदलने का लुत्फ उठाऊंगा

मुझे वह पसंद है, अब ड्राफ़्ट को अपडेट कर रहा हूँ।

मुझे लगता है कि हम पर्याप्त सहमति में हैं कि दस्तावेज़/प्रक्रिया अपडेट के साथ पीआर को एक साथ रखना उचित है, मैं इसे अभी करूँगा और यहां एक लिंक पोस्ट करूंगा।

पीआर लिंक (उपरोक्त जीएच इतिहास में भी शामिल है): https://github.com/seccomp/libseccomp/pull/158

मुझे लगता है कि अब आप पूरी तरह से तैयार हैं @drakenclimber , अगर आपको कुछ भी गड़बड़ दिखाई देता है तो मुझे बताएं।