@drakenclimber Saya akan memberikan garis besar singkat untuk dokumen MAINTAINER_PROCESS.md yang dapat kita diskusikan/edit, tetapi saya masih mencoba untuk menyelesaikan rilis v2.4.0 sekarang, dan saya mungkin perlu beberapa hari untuk cenderung ke beberapa masalah lain yang tidak terkait dan diabaikan :)

@pcmoore - Jangan khawatir. Omong-omong, kerja bagus di rilis v2.4! Beri tahu saya bagaimana saya bisa membantu.

Jangan ragu untuk menggunakan saya sebagai kelinci percobaan saat prosesnya diluruskan :)

Omong-omong, kerja bagus di rilis v2.4! Beri tahu saya bagaimana saya bisa membantu.

Pengujian apa pun yang dapat Anda lakukan sangat membantu pada saat ini. Saya merasa cukup baik tentang kualitas rilis ini, tetapi banyak bagian rumit yang berubah sehingga tidak masuk akal untuk membayangkan beberapa kasus sudut pecah di beberapa aplikasi. Saya berharap kita tidak perlu melakukan rilis "tas coklat" v2.4.1, tetapi Anda tidak pernah tahu.

Jangan ragu untuk menggunakan saya sebagai kelinci percobaan saat prosesnya diluruskan :)

Senang mendengar Anda mengatakan itu karena Anda adalah kelinci percobaan;)

@drakenclimber Saya memesan komentar ini untuk draf dokumen MAINTAINER_PROCESS.md (saya pikir saya dapat terus mengeditnya di sini berdasarkan umpan balik). Jangan ragu untuk mengirimkan ide apa pun yang Anda miliki dalam masalah ini dan saya akan menyusun PR untuk ini setelah kami mendapatkan sesuatu yang dekat.

Proses Pengelola libseccomp

https://github.com/seccomp/libseccomp

Dokumen ini mencoba menjelaskan proses yang harus diikuti oleh berbagai pengelola libseccomp. Ini tidak dimaksudkan sebagai persyaratan yang sulit, melainkan sebagai dokumen panduan yang dimaksudkan untuk memudahkan beberapa pengelola bersama untuk mengelola proyek libseccomp.

Kami menyadari bahwa dokumen ini, seperti semua bagian lain dari proyek libseccomp, tidak sempurna. Jika perubahan perlu dilakukan, perubahan tersebut harus dilakukan dengan mengikuti pedoman yang dijelaskan di sini.

Meninjau dan Menggabungkan Patch

Dalam dunia yang sempurna setiap patch akan ditinjau secara independen dan ACK'd oleh setiap pengelola, tetapi kami menyadari bahwa tidak mungkin praktis untuk setiap patch. Dalam keadaan normal, setiap patch harus ACK'd oleh sebagian besar pengelola (dalam kasus jumlah pengelola genap, N/2+1) sebelum digabungkan ke dalam repositori. Pengelola harus menambal ACK menggunakan format yang mirip dengan Kernel Linux, misalnya:

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

Pengelola yang menggabungkan tambalan ke dalam repositori harus menambahkan tanda tangan mereka setelah memastikan bahwa hal itu benar (lihat dokumentasi tentang pengiriman tambalan); jika tidak benar bagi pengelola untuk menambahkan sign-off mereka, kemungkinan patch mereka tidak boleh digabung. Pengelola harus menambahkan sign-off mereka menggunakan format standar di akhir metadata patch, misalnya:

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

Pengelola didorong untuk berkomunikasi satu sama lain karena berbagai alasan, salah satunya adalah membiarkan yang lain ketika salah satu tidak dapat dijangkau untuk waktu yang lama. Jika tambalan ditahan karena kurangnya ACK dan pengelola lainnya tidak merespons setelah jangka waktu yang wajar (misalnya, penundaan lebih dari dua minggu), selama tidak ada NACK yang beredar, tambalan dapat digabungkan tanpa mayoritas sederhana.

Mengelola Laporan Kerentanan Sensitif

Proses pelaporan kerentanan libseccomp didokumentasikan dalam dokumen SECURITY.md.

Pengelola harus bekerja sama dengan pelapor untuk menilai validitas dan keseriusan kerentanan yang dilaporkan. Kapan pun memungkinkan, praktik pelaporan dan penambalan yang bertanggung jawab harus diikuti, termasuk pemberitahuan ke milis _linux-distros_ dan _oss-security_.

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

Mengelola Pelacak Masalah GitHub

Kami menggunakan pelacak masalah GitHub untuk melacak bug, permintaan fitur, dan terkadang pertanyaan yang tidak terjawab. Konvensi di sini dimaksudkan untuk membantu membedakan antara penggunaan yang berbeda, dan memprioritaskan dalam kategori tersebut.

Permintaan fitur HARUS memiliki awalan "RFE:" yang ditambahkan ke nama masalah dan menggunakan label "penyempurnaan". Laporan bug HARUS awalan "BUG:" ditambahkan ke nama masalah dan menggunakan label "bug".

Masalah HARUS diprioritaskan menggunakan label "prioritas/tinggi", "prioritas/sedang", dan "prioritas/rendah". Maknanya mudah-mudahan harus jelas.

Masalah DAPAT diberi label tambahan dengan label "pending/info", "pending/review", dan "pending/revision" untuk menunjukkan bahwa informasi tambahan diperlukan, masalah/tambalan menunggu tinjauan, dan/atau tambalan memerlukan perubahan.

Mengelola Tonggak Rilis GitHub

Setidaknya harus ada dua pencapaian GitHub kapan saja: satu untuk rilis mayor/minor berikutnya (misalnya, v2.5), dan satu untuk rilis patch berikutnya (misalnya, v2.4.2). Saat masalah dimasukkan ke dalam sistem, masalah tersebut dapat ditambahkan ke pencapaian sesuai kebijaksanaan pengelola.

Mengelola Milis Publik

Milis saat ini dihosting di Grup Google, dan meskipun dimungkinkan untuk berpartisipasi dalam diskusi tanpa akun Google, akun Google diperlukan untuk memoderasi/mengelola grup. Pengelola yang memiliki akun Google dan ingin ditambahkan ke daftar moderator harus ditambahkan, tetapi tidak ada persyaratan untuk melakukannya.

Terlepas dari istilah "moderator", daftar tersebut saat ini tidak dimoderasi dan harus tetap seperti itu.

Rilis Proyek Baru

Proses rilis libseccomp didokumentasikan dalam dokumen RELEASE_PROCESS.md.

Idealnya saya pikir akan menyenangkan untuk mendapatkan ACK dari setiap pengelola di setiap tambalan/PR, tetapi saya tidak yakin apakah itu akan menjadi penghalang jalan? Perasaan saya adalah bahwa patch/PR libseccomp adalah volume yang cukup rendah sehingga ini seharusnya tidak menjadi masalah besar, tetapi saya ingin tahu apa yang Anda pikirkan

Sepakat. Saya pikir berjuang untuk ACK untuk setiap tambalan akan baik, tetapi kami mungkin ingin membiarkan fleksibilitas terbuka untuk memotongnya untuk tambalan yang sangat sederhana, atau keadaan khusus lainnya (liburan panjang, dll.). Jelas melewati ACK lain harus menjadi pengecualian bukan norma.

Terlepas dari hal di atas, saya pikir tambalan dari pengelola mana pun perlu ACK'd dan dilakukan oleh pengelola yang berbeda.

Ini pasti akan menjadi kebiasaan yang baik untuk dilakukan. Ini akan membantu menghindari kesalahan konyol.

Kita juga perlu mendokumentasikan cara menangani penggabungan PR dan patch, misalnya, keluar dari pengelola, melakukannya dengan tangan dan tidak menggunakan alat GitHub, dll.

Saya akan tertarik untuk melihat proses yang Anda rekomendasikan. Apakah ada alasan mengapa kita harus menghindari alat github bawaan?

Saya pikir kuncinya di sini adalah untuk membuat daftar semua pengelola di bagian yang sesuai di README.md dan menyebutkan bahwa pengelola harus bekerja sama untuk menyelesaikan masalah dan mengikuti proses pengungkapan yang bertanggung jawab yang sesuai. Kita harus menyertakan link ke daftar linux-distros dan oss-security.

Ya, menyediakan metode yang mudah dan aman bagi orang lain untuk melaporkan masalah sangatlah penting. Saya setuju.

Sepakat. Saya pikir berjuang untuk ACK untuk setiap tambalan akan baik, tetapi kami mungkin ingin membiarkan fleksibilitas terbuka untuk memotongnya untuk tambalan yang sangat sederhana, atau keadaan khusus lainnya (liburan panjang, dll.). Jelas melewati ACK lain harus menjadi pengecualian bukan norma.

Poin bagus, saya setuju.

Kita juga perlu mendokumentasikan cara menangani penggabungan PR dan patch, misalnya, keluar dari pengelola, melakukannya dengan tangan dan tidak menggunakan alat GitHub, dll.

Saya akan tertarik untuk melihat proses yang Anda rekomendasikan. Apakah ada alasan mengapa kita harus menghindari alat github bawaan?

Saya sangat menyukai gagasan bahwa setiap orang yang menyentuh tambalan, baik dengan mengotorisasinya atau memasukkannya ke repo utama, secara eksplisit menambahkan tanda tangan mereka ke file. Saya juga benar-benar berpikir bahwa pengelola harus melakukan make check pada sistem lokal mereka sebelum mendorong apa pun ke repo utama. Menggabungkan PR langsung dari dalam antarmuka GitHub tidak benar-benar memungkinkan seseorang untuk melakukan salah satu dari hal itu.

Saya membayangkan jika volume PR meningkat secara dramatis, kami dapat mempertimbangkannya kembali, tetapi saat ini volumenya cukup rendah sehingga langkah manual tambahan menurut saya tidak terlalu signifikan.

Pendapat @drakenclimber?

Saya baru saja melihat ke milis Grup Google dan sepertinya saya tidak dapat menggunakan akun/alamat oracle.com Anda sebagai akun manajer/moderator, itu pasti akun Google. Pada titik ini saya pikir terserah Anda @drakenclimber; jika Anda ingin akses manajer/moderator, Anda harus berlangganan dengan akun Google.

Perlu dicatat bahwa saat ini saya tidak memoderasi daftar tersebut, dan menurut saya itu tidak harus dimoderasi. Saat ini satu-satunya posting yang tidak segera dikirim ke daftar adalah hal-hal yang menurut Google adalah SPAM.

Ini juga tidak berarti bahwa lalu lintas di milis di luar pemberitahuan komit mendekati nol, sebagian besar interaksi terjadi di GitHub sekarang. Sementara saya pikir kita harus menyimpan milis, tolong jangan merasa Anda perlu menjadi manajer/moderator milis untuk "berbagi beban", tidak ada "beban" dalam kasus ini.

Saya membayangkan jika volume PR meningkat secara dramatis, kami dapat mempertimbangkannya kembali, tetapi saat ini volumenya cukup rendah sehingga langkah manual tambahan menurut saya tidak terlalu signifikan. Pendapat @drakenclimber?

Sepakat. Saya baik-baik saja dengan langkah manual pada tahap proyek ini. Sebenarnya, itulah yang telah saya lakukan untuk sementara waktu sekarang.

Pada titik ini saya pikir terserah Anda @drakenclimber; jika Anda ingin akses manajer/moderator, Anda harus berlangganan dengan akun Google.

Sementara saya pikir kita harus menyimpan milis, tolong jangan merasa Anda perlu menjadi manajer/moderator milis untuk "berbagi beban", tidak ada "beban" dalam kasus ini.

Masuk akal. Anda dipersilakan untuk menambahkan alamat gmail saya jika Anda tidak keberatan dengan itu; Saya tidak benar-benar melihat kerugiannya, tetapi itu bisa membantu nanti. tom dot hromatka di gmail.

Saya baru menyadari bahwa di bawah tab "Keamanan" untuk proyek, GitHub tampaknya menangani file SECURITY.md dengan cara khusus (lihat CONTRIBUTING.md sebagai contoh). Kita harus mempertimbangkan untuk menggunakan file ini sebagai bagian dari proses ini.

Tab "Keamanan" juga memungkinkan Anda membuat fork pribadi proyek sehingga Anda dapat mengerjakan tambalan secara pribadi; ini bisa menjadi kemenangan besar karena memungkinkan kami untuk berkolaborasi lebih baik dalam perbaikan keamanan tanpa membuat masalah menjadi publik sebelum perbaikan siap.

Itu fitur yang sangat keren. Temukan yang bagus!

@drakenclimber Saya baru saja memperbarui dokumen di komentar di atas, periksa dan beri tahu saya pendapat Anda. Kita masih perlu menyusun dokumen SECURITY.md, tetapi itu seharusnya cukup cepat (hanya beberapa kalimat); Saya akan menyusun draf setelah Anda puas dengan dokumen utama di atas.

@drakenclimber Saya baru saja berlangganan alamat gmail Anda ke grup Google dan memberi Anda akses manajer/moderator, jika tidak berfungsi beri tahu saya.

Saya baru saja berlangganan alamat gmail Anda ke grup Google dan memberi Anda akses manajer/moderator, jika tidak berfungsi beri tahu saya.

Sepertinya itu bekerja. Saya bisa masuk dan masuk ke pengaturan untuk daftar surat. Terima kasih!

Saya baru saja memperbarui dokumen di komentar di atas, periksa dan beri tahu saya pendapat Anda.

Terlihat sangat bagus untukku.

@drakenclimber di sini adalah draf cepat dokumen SECURITY.md, ada pendapat?

Proses Penanganan Kerentanan Keamanan libseccomp

https://github.com/seccomp/libseccomp

Dokumen dokumen ini mencoba untuk menjelaskan proses di mana bug sensitif keamanan yang relevan dapat diungkapkan secara bertanggung jawab ke proyek libseccomp dan bagaimana pengelola proyek harus menangani laporan ini. Sama seperti dokumen proses libseccomp lainnya, dokumen ini harus diperlakukan sebagai dokumen panduan dan bukan seperangkat peraturan yang keras dan pantang menyerah; reporter bug dan pengelola proyek didorong untuk bekerja sama untuk mengatasi masalah sebaik mungkin, dengan cara yang paling sesuai untuk semua pihak yang terlibat.

Melaporkan Masalah

Masalah dengan perpustakaan libseccomp yang tidak cocok untuk pengungkapan publik segera harus diemail ke pengelola libseccomp saat ini, daftarnya ada di bawah. Kami biasanya meminta paling lama 90 hari untuk mengatasi masalah tersebut sebelum dipublikasikan, tetapi kami akan melakukan segala upaya untuk mengatasi masalah tersebut secepat mungkin dan mempersingkat jendela pengungkapan.

• Paul Moore, [email protected]
• Tom Hromatka, tom. [email protected]

Menyelesaikan Masalah Keamanan Sensitif

Setelah pengungkapan bug, pengelola harus bekerja sama untuk menyelidiki masalah dan memutuskan solusi. Untuk mencegah pengungkapan awal masalah, mereka yang mengerjakan solusi harus melakukannya secara pribadi dan di luar praktik pengembangan libseccomp tradisional. Salah satu solusi yang mungkin untuk ini adalah dengan memanfaatkan fungsionalitas "Keamanan" GitHub untuk membuat garpu pengembangan pribadi yang dapat dibagikan di antara pengelola, dan secara opsional kepada pelapor. Masalah GitHub placeholder dapat dibuat, tetapi detailnya harus tetap sangat terbatas hingga masalah telah diperbaiki dan diungkapkan secara bertanggung jawab. Jika CVE, atau tag lain, telah ditetapkan untuk masalah, judul masalah GitHub harus menyertakan tag kerentanan setelah masalah diungkapkan.

Pengungkapan Publik

Bila memungkinkan, praktik pelaporan dan patch yang bertanggung jawab harus diikuti, termasuk pemberitahuan ke milis linux-distro dan oss-security.

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

dengan cara yang paling cocok untuk mereka.

nitpick - Saya akan tergoda untuk mengubah ini menjadi in a manner which works best for all parties involved.

Saya pikir dokumen kerentanan keamanan terlihat sangat bagus. Kerja bagus!

dengan cara yang paling cocok untuk mereka.

nitpick - Saya akan tergoda untuk mengubah ini menjadi in a manner which works best for all parties involved.

Saya suka itu, memperbarui draf sekarang.

Saya pikir kita cukup sepakat bahwa ada baiknya menyusun PR dengan pembaruan doc/proses, saya akan melakukannya sekarang dan memposting tautan kembali ke sini.

Tautan PR (juga termasuk dalam riwayat GH di atas): https://github.com/seccomp/libseccomp/pull/158

Saya pikir Anda sudah siap sekarang @drakenclimber , jika Anda melihat sesuatu yang salah, beri tahu saya.