18 октября вышла Gitea 28.2.0 с исправлениями безопасности. Команда проекта рекомендует пользователям обновиться как можно скорее. Gitea используется для хранения Git-репозиториев, обсуждения изменений, задач и автоматических сборок на собственном сервере. В Mentoring.digital объясняем, почему этот выпуск стоит включить в ближайший план обслуживания инфраструктуры разработки.
Коротко: обновление исправляет ошибки в проверке доступа, аутентификации и работе с вложениями. Также изменена работа Actions и запросов на слияние. Проверка обновления должна охватывать привычные действия команды, а не только открытие главной страницы Gitea.
Какие проблемы безопасности описали разработчики
В анонсе разобрана ошибка привязки OpenID: обработчик не проверял, что текущий пользователь действительно начал связывание учётной записи. Исправление добавляет короткоживущее значение состояния, связанное с пользователем. OpenID в данном случае относится к внешнему способу входа, а не к хранению Git-коммитов.
Другой пример касается черновиков релизов: ответ мог включать вложения из репозиториев, к которым у вызывающего пользователя не было доступа. Кроме того, разработчики устранили ошибки в проверках прав и ограничили размер тела запроса в одном из интерфейсов артефактов Actions.
Важная деталь анонса: часть перечисленных проблем исправлена в предыдущих версиях и раскрыта только сейчас. Поэтому нельзя считать весь список набором новых ошибок именно версии 28.1.0. Условия применимости нужно сверять с конкретной установкой и описанием каждого исправления.
Обновление затрагивает и повседневную работу команды
В Actions исправлены зависающие отменённые повторно используемые процессы и обработка расписаний после смены основной ветки. Также устранены ошибки определения слияния пустых pull request. Pull request, или запрос на слияние, помогает обсудить и проверить изменения до включения в общую ветку проекта.
Наш вывод: после обновления полезно проверить собственную цепочку работы целиком. Например, в условной команде библиотека собирается по расписанию, а релиз содержит готовый архив. Успешный вход администратора ещё не подтверждает, что расписание запускается, отмена сборки завершается, а архив доступен нужной группе пользователей.
Такой сценарий даёт понятный критерий приёмки: разработчик создаёт изменение, коллега его просматривает, сборка проходит, а результат получает именно тот, кому он предназначен. Углубить понимание веток и совместной работы можно на занятиях по Git.
Как подготовить обновление без потери пути назад
Официальная инструкция Gitea рекомендует заранее проверить несовместимые изменения и устаревшие параметры конфигурации. Резервная копия должна учитывать базу данных, конфигурацию, файлы приложения и внешнее хранилище, если оно используется. Нельзя рассчитывать, что возврат старого исполняемого файла всегда отменит изменения структуры базы.
Для ответственного за установку мы предлагаем такой порядок:
- Зафиксировать текущую версию и используемые способы входа, сборки и хранения файлов.
- Подготовить согласованную резервную копию и понятный способ восстановления.
- Проверить обновление на копии окружения с подходящими тестовыми данными.
- После перехода проверить вход обычного пользователя, доступ к закрытому репозиторию, сборку и получение её результата.
Отдельный полезный тест прав: учётная запись без доступа к проекту не должна получать его закрытые вложения. Это рекомендация для собственной проверки, а не сообщение о выполненном нами тесте Gitea.
Если установка обслуживается другой командой, передайте ей номер релиза и согласуйте окно работ. Для самостоятельного сопровождения полезно разобрать резервирование, права и сборки с ментором по инфраструктуре разработки. Главная задача после этого выпуска: подтвердить обновлённую версию и работу ваших процессов с корректными правами доступа.
Обложка: редакционная иллюстрация.
