ຊ່ອງໂຫວ່ດ້ານຄວາມປອດໄພ

ພວກເຮົາໃຫ້ຄວາມສຳຄັນກັບຊ່ອງໂຫວ່ດ້ານຄວາມປອດໄພຢ່າງຈິງຈັງ. ຖ້າທ່ານພົບເຫັນມັນ, ວິທີທີ່ດີທີ່ສຸດໃນການລາຍງານແມ່ນການສ້າງບັນຫາລັບ (confidential issue) ໃນ bug tracker ຂອງພວກເຮົາ. ໃຫ້ແນ່ໃຈວ່າທ່ານເລືອກ "This issue is confidential and should only be visible to team members with at least Reporter access" ເມື່ອສ້າງບັນຫາ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈະເລີ່ມເຮັດວຽກກັບບັນຫາທີ່ລາຍງານມາ. ພວກເຮົາອາດຈະຕິດຕໍ່ຫາທ່ານຜ່ານທາງບັນຫານັ້ນຖ້າມີຂໍ້ມູນເພີ່ມເຕີມທີ່ຕ້ອງການ. ແລະ ພວກເຮົາຈະກຳນົດການເປີດເຜີຍຂໍ້ມູນ.

ວິທີຈັດການການແກ້ໄຂຄວາມປອດໄພ

ສຳລັບສະມາຊິກການພັດທະນາ UBports, ເຫຼົ່ານີ້ແມ່ນຂັ້ນຕອນທີ່ແນະນຳໃນການຈັດການແກ້ໄຂບັນຫາໂດຍບໍ່ເປີດເຜີຍຕໍ່ສາທາລະນະກ່ອນທີ່ການແກ້ໄຂຈະພ້ອມ:

  1. ສຳລັບ main repo, ໃຫ້ຮັບປະກັນວ່າ <project>.secfix repo ມີຢູ່. ຖ້າບໍ່ມີ, ໃຫ້ fork ຈາກໂຄງການຫຼັກໄປຍັງ namespace ດຽວກັນ, ແຕ່ຕັ້ງຄ່າການເບິ່ງເຫັນເປັນ private.

Note

ຄຳຕໍ່ທ້າຍ .secfix ຈະປ້ອງກັນບໍ່ໃຫ້ CI ມາແຕະຕ້ອງ repo ນີ້, ປ້ອງກັນບໍ່ໃຫ້ repo ຮົ່ວໄຫຼ.

  1. ຖ້າຍັງບໍ່ມີບັນຫາສຳລັບມັນເທື່ອ, ໃຫ້ສ້າງບັນຫາລັບໃນໂຄງການຫຼັກ.

  2. ໃນບັນຫາ, ໃຫ້ໃຊ້ "Create confidential merge request". ກຳນົດຊື່ສາຂາ ແລະ ສາຂາຕົ້ນທາງໃຫ້ເໝາະສົມ. ຈາກນັ້ນ, push ໄປຍັງສາຂານີ້ຈາກ Git tree ໃນທ້ອງຖິ່ນຂອງທ່ານ.

Note

MR ນີ້ຈະມີເປົ້າໝາຍທີ່ .secfix repo, ບໍ່ແມ່ນ main repo [1]. ສິ່ງນີ້ອະນຸຍາດໃຫ້ການກວດສອບ patch ເກີດຂຶ້ນແບບລັບໆ.

  1. ຈາກນັ້ນນັກພັດທະນາຄົນອື່ນຈະກວດສອບ ແລະ merge merge request. ຖ້າຈຳເປັນຕ້ອງ backport, ມັນຕ້ອງເກີດຂຶ້ນໃນ .secfix fork ເຊັ່ນກັນ.

Note

ເນື່ອງຈາກພວກເຮົາຍັງບໍ່ມີ CI ແບບລັບໆເທື່ອ, ມັນເປັນຄວາມຮັບຜິດຊອບຂອງທັງນັກພັດທະນາ ແລະ ຜູ້ກວດສອບ ເພື່ອຮັບປະກັນວ່າໂຄ້ດຈະ compile, ຜ່ານການທົດສອບ, ແລະ ຖືກທົດສອບໃນທ້ອງຖິ່ນ.

  1. ປະມານ 1 ມື້ກ່ອນວັນປ່ອຍ release candidate, ນັກພັດທະນາ (ປົກກະຕິແລ້ວແມ່ນ release manager) ຈະ merge ສາຂາທັງໝົດຂອງ .secfix repo ໄປຍັງ main repo. ຫຼັງຈາກນັ້ນ, ບັນຫາລັບຈະຖືກໝາຍເປັນບໍ່ລັບ. ສິ່ງນີ້ເຮັດໃຫ້ບັນຫາຖືກເປີດເຜີຍຕໍ່ສາທາລະນະເປັນຄັ້ງທຳອິດ.

Note

ມາຮອດຈຸດນີ້, ມັນເປັນຄວາມຮັບຜິດຊອບຂອງນັກພັດທະນາຜູ້ນີ້ເພື່ອຮັບປະກັນວ່າຜົນຂອງການ merge ຜ່ານ CI ແທ້ ແລະ ຢ່າງໜ້ອຍການເຮັດວຽກພື້ນຖານຂອງອົງປະກອບນີ້ບໍ່ເສຍຫາຍ.

  1. Release manager ຈະຮັບປະກັນວ່າການແກ້ໄຂໄດ້ເຂົ້າໄປຢູ່ໃນ daily image ແທ້ ກ່ອນທີ່ຈະເລືອກ image ດັ່ງກ່າວເປັນ RC.

  2. ກ່ອນວັນປ່ອຍເວີຊັນ, ນັກພັດທະນາທີ່ແກ້ໄຂບັນຫາຈະກະກຽມຄຳແນະນຳດ້ານຄວາມປອດໄພ, ເຊິ່ງປະກອບດ້ວຍ (ລາຍການແມ່ນໄດ້ຮັບແຮງບັນດານໃຈຈາກຄຳແນະນຳຂອງ Curl [2]):

  • ຊື່

  • ຄວາມອ່ອນແອ (ຜູ້ໃຊ້ມີຄວາມສ່ຽງແນວໃດ)

  • ຂໍ້ມູນ (ຄວາມອ່ອນແອມີຢູ່ແນວໃດ)

  • ເວີຊັນທີ່ໄດ້ຮັບຜົນກະທົບ

  • ວິທີແກ້ໄຂ

  • ຂໍ້ແນະນຳ

  • ກຳນົດເວລາ

  • ເຄຣດິດ

  1. ໃນວັນປ່ອຍເວີຊັນ, ຄຳແນະນຳດ້ານຄວາມປອດໄພຈະຖືກເຜີຍແຜ່ໃນເວທີສົນທະນາ, ໃນພາກ "OS > Security advisories".