Статья полезна как Proof-of-Concept для миграции репозиториев, но... все-таки данное решение не должно восприниматься как "полная миграция" или как решение для безопасности. В статье честно описаны некоторые "ограничения" подхода, но все-таки не все, а они значительные:
Переносятся только история коммитов, ветки и теги (базовая функциональность Git)
НЕ переносятся Merge Requests — это упоминается в разделе "A. Поддержка Merge Request при миграции"
НЕ переносятся Issues
НЕ переносятся CI/CD pipelines (кроме их истории в репозитории)
НЕ переносятся все настройки доступа и permissions
НЕ переносятся webhook'и, custom hooks, protected branch rules
Это значит, что рабочий процесс команды (approval rules, CI/CD конфигурация, issue tracking) остаётся невостребованной на новой платформе.
ПО-поводу безопасности. Тут делает упор на "безопасность" и "избежание утечек", но:
НЕ обсуждается, что self-hosted GitLab сам по себе требует серьёзного hardening (Cycode обнаружил, что /explore endpoint экспонирует данные даже за SSO)
НЕ упоминается, что токены и secrets в git истории это не проблема self-hosted — это проблема практик разработки (Red Hat утечка 28k репозиториев)
НЕ рассматривается угроза инсайдеров — локальный сервер не защищает от администраторов с плохими намерениями
И, пожалуй, самая критическая ошибка в контексте безопасности: CVE-2025-8110 (Gogs RCE Zero-day)
По состоянию на январь 2026, в Gogs существует неисправленная уязвимость, позволяющая удалённое выполнение кода
700+ instансов скомпрометировано в интернете (по данным Wiz Research)
Уязвимость: improper symlink handling в file update API
Позволяет перезаписать .git/config и получить SSH access к серверу
Требует только прав на создание репозитория
Patch был выпущен только в версии v0.13.4 (23 января 2026)
Это означает, "мы боремся за безопасночть" и рекомендуем :) систему с критической RCE уязвимостью?
Что касается предлагаемого скрипта - тут пара советов (хотя вангую, что автор и сам догадывается "просто руки не дошли") - опять-таки проблемы с безопасностью - файл settings.ini содержит credentials в plaintext. Рекомендации:
Использовать все-таки переменные окружения или key management service
особо напрягает - надо следить, чтобы случайно не закоммитить settings.ini в git
Ротировать токены после миграции
Автор "костылит" миграцию аватаров, обращаясь напрямую к SQLite БД Gogs вместо использования API. Это проблематично потому что:
Привязывает скрипт к конкретной версии и конфигурации Gogs
Если БД находится на удалённом сервере — не будет работать (автор добавил проверку, но это костыль)
Статья полезна как Proof-of-Concept для миграции репозиториев, но... все-таки данное решение не должно восприниматься как "полная миграция" или как решение для безопасности.
В статье честно описаны некоторые "ограничения" подхода, но все-таки не все, а они значительные:
Переносятся только история коммитов, ветки и теги (базовая функциональность Git)
НЕ переносятся Merge Requests — это упоминается в разделе "A. Поддержка Merge Request при миграции"
НЕ переносятся Issues
НЕ переносятся CI/CD pipelines (кроме их истории в репозитории)
НЕ переносятся все настройки доступа и permissions
НЕ переносятся webhook'и, custom hooks, protected branch rules
Это значит, что рабочий процесс команды (approval rules, CI/CD конфигурация, issue tracking) остаётся невостребованной на новой платформе.
ПО-поводу безопасности. Тут делает упор на "безопасность" и "избежание утечек", но:
НЕ обсуждается, что self-hosted GitLab сам по себе требует серьёзного hardening (Cycode обнаружил, что /explore endpoint экспонирует данные даже за SSO)
НЕ упоминается, что токены и secrets в git истории это не проблема self-hosted — это проблема практик разработки (Red Hat утечка 28k репозиториев)
НЕ рассматривается угроза инсайдеров — локальный сервер не защищает от администраторов с плохими намерениями
И, пожалуй, самая критическая ошибка в контексте безопасности: CVE-2025-8110 (Gogs RCE Zero-day)
По состоянию на январь 2026, в Gogs существует неисправленная уязвимость, позволяющая удалённое выполнение кода
700+ instансов скомпрометировано в интернете (по данным Wiz Research)
Уязвимость: improper symlink handling в file update API
Позволяет перезаписать
.git/configи получить SSH access к серверуТребует только прав на создание репозитория
Patch был выпущен только в версии v0.13.4 (23 января 2026)
Это означает, "мы боремся за безопасночть" и рекомендуем :) систему с критической RCE уязвимостью?
Что касается предлагаемого скрипта - тут пара советов (хотя вангую, что автор и сам догадывается "просто руки не дошли")
- опять-таки проблемы с безопасностью - файл settings.ini содержит credentials в plaintext. Рекомендации:
Использовать все-таки переменные окружения или key management service
особо напрягает - надо следить, чтобы случайно не закоммитить
settings.iniв gitРотировать токены после миграции
Автор "костылит" миграцию аватаров, обращаясь напрямую к SQLite БД Gogs вместо использования API. Это проблематично потому что:
Привязывает скрипт к конкретной версии и конфигурации Gogs
Если БД находится на удалённом сервере — не будет работать (автор добавил проверку, но это костыль)
Нарушает принцип использования только API