Контрольные суммы пакетов Flatpak: как проверить целостность и версию приложения

В отличие от привычных deb- или rpm-пакетов, у приложения Flatpak нет одного файла с хешем, который можно сверить вручную перед установкой. Целостность здесь обеспечивается другой механикой: каждый пакет — это снимок файловой системы в репозитории OSTree, а его «контрольная сумма» — это хеш коммита, вычисляемый автоматически по содержимому всех файлов. Если хотя бы один байт изменён, изменится и хеш, поэтому подмена данных без смены идентификатора невозможна. В этой статье разберём, как посмотреть контрольную сумму установленного или доступного пакета, зачем она нужна на практике, как работает проверка подписей и что делать, когда нужно зафиксировать или откатить конкретную версию.

Что именно является контрольной суммой в Flatpak

Flatpak построен поверх OSTree — системы версионирования файлов, похожей по принципу на git, но работающей с бинарными данными. Когда разработчик публикует приложение, оно загружается в удалённый репозиторий (например, Flathub) как набор объектов, каждый из которых адресуется собственным хешем по алгоритму SHA-256. Вершина этой структуры — коммит: строка вида длинного шестнадцатеричного числа, которая однозначно описывает точное состояние всех файлов приложения, его метаданные и зависимости.

Из этого следуют три практических вывода:

• Хеш коммита — это и есть контрольная сумма пакета. Два устройства с одинаковым коммитом одного приложения имеют побайтово одинаковое содержимое.
• Проверка происходит автоматически. При установке и обновлении Flatpak сверяет полученные объекты с их хешами и подписью репозитория. Отдельно скачивать и сверять суммы, как это делается с ISO-образами, не нужно.
• Хеш меняется при каждом выпуске. Новая версия приложения — новый коммит, даже если изменился один значок в интерфейсе.

Важное ограничение: хеш подтверждает, что данные дошли до вас без искажений и соответствуют тому, что подписал владелец ключа репозитория. Он не подтверждает, что собранный бинарник побайтово совпадает с тем, что получил бы разработчик из исходного кода, — воспроизводимость сборки зависит от инфраструктуры конкретного репозитория и отдельно не гарантируется.

Как посмотреть контрольную сумму установленного приложения

Базовая команда для просмотра информации о пакете:

flatpak info org.example.App

Здесь и далее org.example.App — условный идентификатор; подставьте реальный, например тот, что показывает flatpak list —app. В выводе вас интересуют строки:

• Commit: — хеш текущего установленного коммита, то есть фактическая контрольная сумма содержимого;
• Version: — заявленная версия приложения;
• Installed: — размер и дата установки;
• Origin: — удалённый репозиторий, из которого установлен пакет.

Чтобы увидеть историю доступных коммитов на сервере и сравнить её с локальной, используйте:

flatpak remote-info —log origin org.example.App

Команда выведет список последних коммитов с датами, темами сообщений и номерами версий. Если верхний хеш в этом списке отличается от значения Commit в flatpak info, для приложения доступно обновление. Это удобный способ проверить наличие новой версии без запуска обновления.

Подписи репозиториев: вторая половина проверки целостности

Контрольная сумма защищает от случайных повреждений и подмены «по пути», но сама по себе не отвечает на вопрос, кому вы доверяете. Эту роль выполняют GPG-подписи. Каждый коммит в репозитории подписан ключом владельца, и клиент проверяет подпись при загрузке.

Механика выглядит так:

1. При добавлении удалённого репозитория командой flatpak remote-add —if-not-exists имя URL вместе с ним обычно добавляется GPG-ключ через параметр —gpg-key или файл ключа.
2. При установке и обновлении Flatpak проверяет, что метаданные и коммиты подписаны именно этим ключом.
3. Если подпись отсутствует, неверна или ключ не соответствует, установка прерывается с ошибкой проверки.

Проверить настройки конкретного удалённого источника можно так:

flatpak remotes —show-details

Обратите внимание на колонку с фильтрацией и параметры репозитория: для доверенных источников должна быть включена проверка GPG-подписи. Если вы когда-то добавляли репозиторий с отключённой верификацией, любой контент из него принимается без криптографического подтверждения авторства — такой источник стоит либо перенастроить с ключом, либо удалить.

Отдельный нюанс касается Flathub: приложения там могут публиковаться двумя способами. Часть собирается и подписывается самой инфраструктурой Flathub, часть — самим разработчиком, который загружает готовые бинарники. В обоих случаях подпись проверяется, но ключ подписи будет разным, и это нормально. Проверить, кем подписан конкретный коммит, можно через flatpak remote-info —log: в истории видны подписи и темы коммитов.

Практические сценарии использования контрольных сумм

Сверка версии на нескольких машинах

Если нужно убедиться, что на двух компьютерах стоит одно и то же состояние приложения, сравните значение Commit из flatpak info на обеих машинах. Совпадение хешей означает полное совпадение содержимого, тогда как номера версий иногда совпадают при различающихся пересборках.

Фиксация конкретной версии

Иногда новая версия приложения работает хуже предыдущей, и нужно остаться на старой. Flatpak позволяет установить конкретный коммит:

sudo flatpak update —commit=ХЕШ org.example.App

Хеш берётся из вывода flatpak remote-info —log. Учтите два момента: во-первых, при следующем обычном обновлении система снова предложит перейти на актуальную версию, поэтому фиксацию придётся повторять или временно исключать приложение из обновлений; во-вторых, старые коммиты со временем могут удаляться из репозитория, и тогда откат окажется невозможен.

Откат после неудачного обновления

Если приложение уже обновилось и перестало работать, сначала посмотрите историю:

flatpak remote-info —log origin org.example.App

Найдите в списке предыдущий коммит и выполните откат той же командой flatpak update —commit=…. Это штатный механизм, он не требует переустановки и сохраняет пользовательские данные приложения, поскольку они лежат отдельно от самого пакета.

Диагностика повреждённой установки

Признаки проблемы: приложение падает при запуске после сбоя питания или переполнения диска, появляются ошибки про отсутствующие объекты. Поскольку OSTree адресует файлы по хешам, любое повреждение обычно проявляется сразу при обращении к данным. Стандартное решение — переустановка пакета:

1. Удалите приложение: flatpak uninstall org.example.App.
2. Очистите неиспользуемые объекты: flatpak uninstall —unused.
3. Установите заново: flatpak install org.example.App.

Повторная установка заново скачает и сверит все объекты, поэтому после неё проблема повреждённых данных, если она была, исчезает. Ручная правка файлов внутри каталогов установки бессмысленна: любое изменение нарушит соответствие хешам, а некоторые системные каталоги дополнительно доступны только для чтения.

Чем подход Flatpak отличается от классических пакетов

Аспект	Flatpak / OSTree	deb / rpm
Единица проверки	Хеш каждого объекта и хеш коммита целиком	Хеш всего файла пакета или отдельных файлов внутри него
Когда проверяется	Автоматически при каждой загрузке и обновлении	При установке пакета менеджером
Авторство	GPG-подпись коммитов репозитория	Подпись пакета ключом дистрибутива или вендора
Ручная сверка суммы	Не требуется, хеш виден через flatpak info	Возможна и иногда практикуется для скачанных файлов
Откат версии	Штатно, по хешу коммита	Зависит от дистрибутива, часто нужна ручная установка старого пакета

Главное отличие в том, что модель Flatpak смещает ответственность с пользователя на инфраструктуру: вместо «скачай файл и сверь сумму» предлагается «доверяй подписанному репозиторию, а целостность проверяется постоянно». Это снижает вероятность человеческой ошибки, но повышает цену неправильной настройки источников — поэтому вопросу доверия к репозиторию стоит уделить внимание один раз при настройке системы.

Типичные ошибки и заблуждения

• Поиск «файла контрольных сумм» для Flatpak. Его не существует в привычном виде: суммы встроены в структуру репозитория. Если вы ищете хеш для ручной сверки, вам нужен Commit из flatpak info или flatpak remote-info.
• Добавление сторонних репозиториев без GPG-ключа. Такую конфигурацию некоторые инструкции предлагают «для простоты». Она отключает проверку авторства, и вся защита сводится к HTTPS-транспорту. Для доверенных источников всегда настраивайте верификацию подписи.
• Ожидание, что хеш подтвердит соответствие исходному коду. Хеш гарантирует неизменность данных относительно того, что подписано в репозитории. Аудит сборки — отдельная задача, и для неё нужны исходники и инструменты сборки проекта.
• Правка файлов внутри установленного пакета. Изменения либо не сохранятся из-за защиты каталогов, либо приведут к рассогласованию с хешами. Кастомизацию приложения делают через его пользовательские данные и настройки, а не через файлы пакета.
• Сравнение хешей разных архитектур. Один и тот же коммит может существовать в вариантах для x86_64 и ARM; при сравнении машин убедитесь, что архитектура совпадает.

Быстрая шпаргалка по командам

• flatpak list —app — список установленных приложений с идентификаторами.
• flatpak info ИДЕНТИФИКАТОР — текущий коммит, версия, источник, размер.
• flatpak remote-info —log ИСТОЧНИК ИДЕНТИФИКАТОР — история коммитов с хешами и датами.
• flatpak remotes —show-details — список источников и их параметры, включая проверку подписи.
• flatpak update —commit=ХЕШ ИДЕНТИФИКАТОР — установка или откат к конкретному коммиту.
• flatpak uninstall —unused — очистка неиспользуемых сред выполнения и объектов.

Точные названия опций могут немного отличаться между версиями Flatpak, поэтому при расхождении поведения с описанным сверьтесь со справкой: flatpak —help и страницы руководства (man flatpak, man flatpak-remote-info) на вашей системе отражают актуальный синтаксис именно вашей версии.

Что важно понимать в итоге

Контрольные суммы в Flatpak работают незаметно для пользователя, и это осознанный дизайн: целостность проверяется на каждом обновлении, а доверие закрепляется за подписанным репозиторием, а не за отдельным файлом. Практически вам достаточно трёх вещей. Первое — добавлять только те источники, которым вы доверяете, и обязательно с включённой проверкой GPG-подписи. Второе — знать, что хеш коммита из flatpak info однозначно идентифицирует содержимое пакета и служит точкой отсчёта для сравнения и отката. Третье — при любых подозрениях на повреждение не чинить файлы вручную, а переустановить пакет: полная повторная сверка объектов произойдёт автоматически.

Конкретный следующий шаг: выполните flatpak remotes —show-details и убедитесь, что все ваши источники настроены с проверкой подписи. Затем выберите одно важное для вас приложение и посмотрите его историю командой flatpak remote-info —log — так вы увидите, как выглядят коммиты и хеши на практике, и в случае проблем будете готовы быстро откатиться к рабочей версии.