Регламент обновления пакетов в основных репозиториях ROSA Linux — различия между версиями
Материал из Rosalab Wiki
(→Команда контроля уязвимостей (SecTeam)) |
(→Публикатор) |
||
(не показана 21 промежуточная версия 2 участников) | |||
Строка 1: | Строка 1: | ||
=== Применимость === | === Применимость === | ||
− | Настоящий регламент описывает порядок добавления и исправления пакетов в | + | Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд: |
# Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов | # Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов | ||
− | # Команды сборщиков, собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей | + | # Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей |
# Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления | # Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления | ||
# Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками | # Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками | ||
− | # Публикатора, | + | # Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.) |
− | Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества (contrib) где контроль качества не производится. | + | Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится. |
=== Общий порядок обновления === | === Общий порядок обновления === | ||
− | # Общий порядок адресации каждого запроса на обновление - Репортеры -> Cборщики -> QA & | + | # Общий порядок адресации каждого запроса на обновление - |
+ | Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор | ||
# Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. | # Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их. | ||
− | |||
# Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление | # Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление | ||
Строка 22: | Строка 22: | ||
=== Сборщики === | === Сборщики === | ||
# Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы | # Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы | ||
− | # Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага | + | # Пакеты обновляются на основании заведенного в [http://bugs.rosalinux.ru багзилле] бага, называемого далее "запросом на обновление" |
− | # В комментариях к запросу на | + | # В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости) |
# После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?" | # После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?" | ||
+ | |||
+ | === Мейнтейнеры === | ||
+ | Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки. | ||
+ | # Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf | ||
+ | # В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов | ||
+ | # Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней) | ||
+ | # 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов с момента появления рабочих патчей, закрывающих уязвимость (за возможным исключением выходных и праздничных дней), критические - в течение недели | ||
+ | # Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения. | ||
+ | # Мейнтейнер пакета при необходимости самостоятельно взаимодействует с разработчиками пакетируемого ПО для исправления найденных службой QA или другими репортерами ошибок. | ||
+ | # В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера | ||
=== Команда контроля качества (QA) === | === Команда контроля качества (QA) === | ||
Строка 32: | Строка 42: | ||
# После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной. | # После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной. | ||
# При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?" | # При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?" | ||
+ | # QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю | ||
=== Команда поиска и устранения уязвимостей (SecTeam) === | === Команда поиска и устранения уязвимостей (SecTeam) === | ||
Строка 37: | Строка 48: | ||
# Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam. | # Список уязвимостей ведется на странице вики [http://wiki.rosalab.ru/ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:Security_Advisories Список уязвимостей] командой SecTeam. | ||
# Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг | # Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг | ||
+ | # После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости | ||
# Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam | # Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam | ||
+ | # При успешной проверке secteam_verified устанавливается в "+" | ||
=== Публикатор === | === Публикатор === | ||
# Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam | # Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam | ||
− | # Публикатор | + | # Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива |
+ | # Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки | ||
# После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым. | # После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым. | ||
+ | # При нахождении ошибок в отправленном на публикацию обновлении публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину | ||
+ | # Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней) | ||
[[Категория:Регламенты ROSA]] | [[Категория:Регламенты ROSA]] |
Текущая версия на 18:37, 29 апреля 2020
Содержание
Применимость
Настоящий регламент описывает порядок добавления и исправления пакетов в репозиториях ROSA при взаимодействии пяти команд:
- Команды репортеров, сообщающих об ошибках и уязвимостях в пакетной базе и выступающих с предложениями обновления пакетов
- Команды сборщиков (мейнтейнеров), собирающих пакеты с новыми версиями программ и исправлениями ошибок и уязвимостей
- Команды контроля качества (QA), контролирующих работоспособность исправленных пакетов и всей системы в целом после обновления
- Команда контроля уязвимостей (SecTeam), отслеживающих текущие уязвимости дистрибутива и корректность исправления этих уязвимостей сборщиками
- Публикатора, задачи которого - доступность исправленных пакетов на зеркалах дистрибутива, контроль целостности/замкнутости репозиториев после публикации, а также качества сборки самих пакетов (соответствие политикам сборки, принятым в дистрибутиве и т.п.)
Данный порядок относится к работе с основными репозиториями ROSA Linux, за исключением репозитория сообщества ROSA Fresh (contrib) где контроль качества не производится.
Общий порядок обновления
- Общий порядок адресации каждого запроса на обновление -
Репортеры (в т.ч. из SecTeam) -> Cборщики -> QA & SecTeam -> Публикатор
- Допустимо совмещение ролей "репортер", "сборщик" и "публикатор", но недопустима ситуация, когда человек проверяет результаты своей сборки и публикует их.
- Вся работа по обновлению пакетов происходит с помощью специально созданных в багзилле ROSA Linux багов - запросов на обновление
Репортеры
- Репортеры заводят в багзилле баги, обосновывающие необходимость исправления или добавления, с описанием ошибки, кодом уязвимости или необходимым им новым функционалом.
- Альтернативным путем создания запроса на изменение пакетов в репозиториях для репортеров является пул-реквест в системе сборки ABF.
- Репортеры являются заказчиками исправления, т.е. контролируют весь его процесс до попадания в репозитории.
Сборщики
- Сборщики получают информацию о багах от репортеров через почтовую рассылку багзиллы
- Пакеты обновляются на основании заведенного в багзилле бага, называемого далее "запросом на обновление"
- В комментариях к запросу на обновление указываются ссылки на контейнеры с собранным для указанной платформы обновлением пакета и advisory - написанное по-английски обоснование обновления (например выход новой версии, исправление уязвимости)
- После того, как закончено формирование запроса на обновление, он отправляется на контроль качества команде QA установкой флажка qa_verified в знак вопроса "?"
Мейнтейнеры
Мейнтейнер (сопровождающий) - совмещает в себе функции сборщика, репортера и ответственного за функциональность пакета. Мейнтейнер отслеживает его изменения, исправляет уязвимости и ошибки.
- Если какой-то пакет имеет мейнтейнера, это должно быть прописано на abf
- В пакет с указанным мейнтейнером имеет право вносить правки только сам мейнтейнер, остальные могут только предлагать правки, например с помощью пул-реквестов
- Пул-реквесты или другие предложения на обновление пакета должны рассматриваться мейнтейнером в течение недели, а критические - в течение 48 часов (за возможным исключением выходных и праздничных дней)
- 0-day уязвимости в своем пакете мейнтейнер должен исправлять и передавать на тестирование в течение 48 часов с момента появления рабочих патчей, закрывающих уязвимость (за возможным исключением выходных и праздничных дней), критические - в течение недели
- Баги в пакете, имеющем мейнтейнера, должны им рассматриваться (исправляться, отменяться или хотя бы комментироваться) в течение двух недель после назначения.
- Мейнтейнер пакета при необходимости самостоятельно взаимодействует с разработчиками пакетируемого ПО для исправления найденных службой QA или другими репортерами ошибок.
- В случае, если мейнтейнер не выдерживает указанные сроки по реагированию на предложения правок, исправления уязвимостей и ошибок, они могут быть исправлены другим сборщиком по процедуре, аналогичной для пакета, не имеющего мейнтейнера
Команда контроля качества (QA)
- Команда QA получает запросы с установленным сборщиками флажком qa_verified
- Команда QA проводит тестирование пакетов, используя Регламент тестирования
- Если обновление содержит исправления уязвимостей, устанавливается флажок sectime_verified в "?" для параллельной проверки корректности исправления уязвимостей командой SecTeam
- После проверки отсутствия регрессий функциональности у собранного пакета команда QA ставит флаг QA_verified "+" при успешной проверке и "-" при неуспешной.
- При отсутствии регрессий и, при необходимости, после получения одобрения запроса от команды SecTeam (флажок sectime_verified меняется на "+") запрос отправляется на публикацию установкой флажка publishied в "?"
- QA каждую пятницу публикует бюллетень с перечнем исправленных багов за истекшую неделю
Команда поиска и устранения уязвимостей (SecTeam)
- Подробности поиска уязвимостей описаны в документе Регламент по устранению уязвимостей
- Список уязвимостей ведется на странице вики Список уязвимостей командой SecTeam.
- Для каждой уязвимости из списка команда SecTeam выступает репортером и заводит баг
- После того, как сборщики соберут исправленные пакеты и QA установить флажок secteam_verified в "?", SecTeam проверяет исправление уязвимости
- Дополнительно могут проверяться и запросы с исправлениями уязвимостей, сделанные и не участниками команды SecTeam
- При успешной проверке secteam_verified устанавливается в "+"
Публикатор
- Публикатор получает запрос на обновление после его одобрения командами QA и (если он содержит исправления уязвимостей) SecTeam
- Публикатор отвечает за доступность пакетов обновлений для пользователей в репозиториях на зеркалах дистрибутива
- Задача публикатора - проверка контроля целостности/замкнутости репозиториев после публикации, оценка возможного неправильного взаимодействия различных компонентов с учетом внесенных обновлением изменений, оценка корректности сборки пакета с учетом принятых в дистрибутиве правил сборки
- После успешной публикации флажок "publishied" устанавливается в "+" и запрос на обновление считается полностью закрытым.
- При нахождении ошибок в отправленном на публикацию обновлении публикатор может установить флажок publishied в "-", таким образом отклонив публикацию, при этом он должен написать в запросе на обновление причину
- Публикатор должен опубликовать направленный на публикацию пакет или отклонить его публикацию в течение 48 часов (за исключением выходных и праздничных дней)