Содержание

Применимость

Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:

  1. Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов
  2. Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей
  3. Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления
  4. Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками
  5. Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)

Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.

Общий порядок обновления

  1. Общий порядок адресации каждого запроса на обновление -
 Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор
  1. Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их.
  2. Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление

Репортеры

  1. Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.
  2. Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.
  3. Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.

Сборщики

  1. Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы
  2. Пакеты обновляются на основании заведенного в багзилле бага, называемого далее "запросом на обновление"
  3. В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)
  4. После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"

Мейнтейнеры

Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.

  1. Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf
  2. В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов
  3. Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней)
  4. 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов с момента появления рабочих патчей, закрывающих уязвимость (за возможным исключением выходных и праздничных дней), критические - в течение недели
  5. Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.
  6. Мейнтейнер пакета при необходимости самостоятельно взаимодействует с разработчиками пакетируемого ПО для исправления найденных службой QA или другими репортерами ошибок.
  7. В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера

Команда контроля качества (QA)

  1. Команда QA получает запросы с установленным сборщиками флажком qa_verified
  2. Команда QA проводит тестирование пакетов, используя Регламент тестирования
  3. Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam
  4. После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.
  5. При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"
  6. QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю

Команда поиска и устранения уязвимостей (SecTeam)

  1. Подробности поиска уязвимостей описаны в документе Регламент по устранению уязвимостей
  2. Список уязвимостей ведется на странице вики Список уязвимостей командой SecTeam.
  3. Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг
  4. После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости
  5. Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam
  6. При успешной проверке secteam_verified устанавливается в "+"

Публикатор

  1. Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam
  2. Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива
  3. Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки
  4. После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.
  5. При нахождении ошибок в отправленном на публикацию обновлении публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину
  6. Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)