Вразливості безпеки

Ми серйозно ставимося до вразливостей безпеки. Якщо десь їх зустрінете, найкраще повідомити про це через створення відповідного запиту на баг-трекері. Переконайтеся, що під час створення запиту / заявки Ви обрали «Це питання є конфіденційним і повинно бути видиме лише членам команди з принаймні доступом до Звітів». Після цього ми почнемо працювати над проблемою. Можливо, хтось до Вас звернеться за деякими уточненнями і ми визначимо рівень впливу.

Як поводитися з виправленням безпеки

Для учасників розробки UBports ці кроки — які допоможуть розв’язати проблему, не розголошуючи її до готового виправлення — є рекомендованими:

  1. Для основного сховища переконайтеся, що сховище <project>.secfix існує. Якщо ні, зробіть відгалуження від основного проєкту у тому самому просторі імен, але встановіть видимість приватною.

Примітка

Суфікс .secfix не дозволить CI торкатися цього репозиторію, запобігаючи витоку.

  1. Якщо для проблеми ще немає заявки, створіть конфіденційну заявку в основному проєкті.

  2. Що стосується запиту, використовуйте «Створити конфіденційний запит на злиття». Встановіть назву нової гілки (branch) та відповідну джерельну гілку. Потім додайте (push) цю гілку зі свого локального дерева Git.

Примітка

Цей запит на злиття MR стосується .secfix у репозиторії, НЕ в основному [1]. Це дозволить переглянути цю латку приватно.

  1. Інший розробник потім перегляне та погодить запит на злиття. Якщо потрібен патч для попередніх версій (backport), він повинен бути у форку .secfix.

Примітка

Оскільки у нас наразі немає чіткої неперервної інтеграції (CI), відповідальність за те, щоб код компілювався, проходив тести та тестувався локально несуть розробник та рецензент.

  1. За ~1 день до дати випуску реліз-кандидата розробник (зазвичай реліз-менеджер) зливає усі гілки репозиторію .secfix до основного репозиторію. Після цього конфіденційний випуск позначається неконфіденційним. Це робить випуск публічним вперше.

Примітка

На цьому етапі саме розробник несе відповідальність за те, щоб результат злиття дійсно пройшов перевірку CI та щоб принаймні базова функціональність цього компонента не була порушена.

  1. Перед вибором цього образу як RC, відповідальний за випуск переконується, що виправлення дійсно потрапляє до щоденного образу.

  2. Перед датою випуску розробник виправлення готує повідомлення про безпеку, яке міститиме (список натхненний порадами Curl [2]):

  • Назва

  • Вразливість (як вразливий користувач)

  • Інформація (як / де вразливість існує)

  • Уражені версії

  • Виправлення

  • Рекомендації

  • Розклад

  • Подяки

  1. У день випуску інформація щодо безпеки буде опублікована на форумі в розділі «ОС > Інформація щодо безпеки» («OS > Security advisories»).