Как работают хеши пакетов Debian: контроль целостности от репозитория до установки

Каждый раз, когда вы запускаете apt install, система незаметно для вас сверяет хеш скачанного файла с эталонным значением. Если они не совпали — установка прервётся с ошибкой «Hash Sum mismatch». Этот механизм защищает от повреждённых загрузок, устаревших зеркал и подмены файлов. Разберём, какие именно хеши используются в Debian, где они хранятся, как связаны с цифровой подписью репозитория и что делать, когда проверка не проходит.

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

Зачем нужны хеши в системе пакетов

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

• Целостность при передаче. Пакет скачивается через цепочку зеркал, прокси и CDN. Хеш позволяет мгновенно обнаружить обрыв загрузки или повреждение на любом звене.
• Согласованность метаданных. apt сравнивает хеш скачанного пакета со значением из индексных файлов. Если зеркало частично обновилось и индексы не соответствуют файлам, вы получите ошибку вместо установленного «полусборного» состояния.
• Основа для подписи. Подписывать каждый .deb отдельно неудобно, поэтому Debian подписывает файлы с индексами, а внутри них уже лежат хеши тысяч пакетов. Одна подпись покрывает весь репозиторий.

Важно понимать ограничение: совпадение хеша доказывает, что файл тот же самый, что описан в индексах, но не говорит, можно ли этим индексам верить. За доверие отвечает отдельный механизм — GPG-подписи.

Какие алгоритмы использует Debian

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

Алгоритм	Статус в Debian	Роль
MD5	Устарел	Уязвим к коллизиям; сохраняется местами только для совместимости и быстрой проверки повреждений, не для защиты от атакующего
SHA-1	Не рекомендуется	Ранее основной вариант; сейчас практически вытеснен семейством SHA-2
SHA-256	Основной	Главная контрольная сумма для пакетов и индексов во всех актуальных выпусках
SHA-512	Поддерживается	Альтернатива SHA-256 там, где предпочтительна более длинная сумма

На практике ориентируйтесь так: если вы видите только MD5 — это либо очень старый источник, либо служебная совместимость, и полагаться на такую сумму в вопросах безопасности нельзя. Актуальные выпуски Debian используют SHA-256 как рабочую сумму по умолчанию.

Где живут хеши: структура файлов репозитория

Пакетный менеджер не хранит хеши «в воздухе» — они распределены по нескольким уровням.

Файлы Packages и Sources

Для каждого компонента репозитория (main, contrib, non-free) и архитектуры формируется индексный файл Packages (в сжатом виде — Packages.gz, Packages.xz). Внутри него для каждого бинарного пакета перечислены поля:

• Filename — путь к .deb относительно корня репозитория;
• Size — размер файла в байтах;
• SHA256 (и исторически MD5sum) — контрольные суммы содержимого;
• Description и другие метаданные пакета.

Для пакетов с исходным кодом аналогичную роль играет файл Sources: в нём указаны суммы архивов с исходниками, патчей и файлов описания.

Release-файл: единая точка доверия

Индексы сами по себе тоже могут быть подменены. Поэтому их хеши собираются в файл Release (или InRelease), который лежит в корне дистрибутива. Он содержит секцию с суммами всех индексных файлов и подписывается ключом архива Debian. Цепочка выглядит так:

1. apt загружает InRelease/Release и проверяет его GPG-подпись по заранее известному ключу архива;
2. из подписанного Release берутся хеши индексных файлов (Packages.xz, Sources.xz и т. д.) и сверяются после их скачивания;
3. из проверенных индексов берётся хеш конкретного .deb, который сверяется после загрузки пакета.

Таким образом, одна подпись транзитивно защищает тысячи пакетов. Если хотя бы одно звено не сходится — apt останавливается и не ставит пакет.

Служебные файлы на зеркалах

На зеркалах также встречаются файлы вроде by-hash-каталогов: индексы доступны не только по имени, но и по собственному хешу. Это решает проблему рассинхронизации: клиент может запросить именно ту версию индекса, которую видел в Release, даже если зеркало уже начало обновляться. Механизм включён по умолчанию в современных версиях apt.

Что происходит при установке: путь проверки шаг за шагом

1. Обновление списков. Команда apt update скачивает Release/InRelease, проверяет подпись, затем индексы — их суммы против Release.
2. Планирование. apt определяет, какие пакеты нужно скачать, и запоминает ожидаемые размеры и суммы.
3. Загрузка. Файлы берутся с зеркала; apt умеет докачивать частичные загрузки и переиспользовать кэш.
4. Сверка. Для каждого файла считается фактическая сумма и сравнивается с ожидаемой. Несовпадение — ошибка «Hash Sum mismatch», файл отбрасывается.
5. Распаковка и настройка. Только после успешной сверки пакет передаётся dpkg для установки.

Отдельный слой проверки добавляет debsums: эта утилита сверяет хеши уже установленных файлов с манифестами из /var/lib/dpkg/info/*.md5sums. Она полезна, чтобы убедиться, что файлы на диске не изменились после установки — например, из-за сбоя диска или постороннего вмешательства. Учтите, что эти локальные суммы — преимущественно MD5 и защищают от случайных повреждений лучше, чем от целенаправленной атаки, ведь атакующий с правами root мог бы изменить и сами манифесты.

Типичная ошибка: Hash Sum mismatch

Самая частая ситуация, с которой сталкивается пользователь, выглядит так: при apt update или установке появляется сообщение о несовпадении хеш-суммы. Причины почти всегда безобидны:

• Зеркало в процессе синхронизации. Индексы уже новые, а часть пакетов ещё старая (или наоборот). Самый простой выход — подождать несколько часов или временно переключиться на другой зеркало.
• Прозрачный прокси или корпоративный фильтр. Промежуточное оборудование кэширует или изменяет трафик, и файл приходит искажённым. Проверка — попробовать то же действие через другое подключение.
• Локальный кэш apt. Частично скачанные файлы в /var/cache/apt/archives конфликтуют с новыми версиями. Помогает очистка кэша (apt clean) и повторная попытка.
• Устаревший снимок стороннего репозитория. Если вы подключили зеркало-снимок, его состояние может не соответствовать текущим индексам основного архива.

Порядок действий обычно такой: очистить кэш, выполнить apt update заново, при повторении ошибки сменить зеркало или подождать завершения его синхронизации. Если ошибка возникает только на одном источнике — проблема почти наверняка на стороне этого источника, а не вашей системы.

Ручная проверка пакета вне apt

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

• Сверка с индексами. Скачайте Packages.xz нужного компонента, распакуйте, найдите запись пакета и сравните поле SHA256 с результатом sha256sum имя_файла.deb.
• Проверка через apt. Если пакет доступен в настроенном репозитории, надёжнее просто установить его через apt — все проверки выполнятся автоматически.
• Проверка ISO-образов. Для установочных образов Debian публикует файлы SHA256SUMS и SHA512SUMS вместе с подписью. Порядок: скачать образ и файлы сумм, импортировать ключ подписи, проверить подпись файлов сумм, затем сверить образ командой вида sha256sum -c SHA256SUMS. Подпись здесь критична: без неё сверка с файлом, взятым с того же сомнительного сервера, ничего не гарантирует.

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

Частые вопросы

Можно ли по хешу понять, что пакет «чистый» от уязвимостей?

Нет. Хеш подтверждает только неизменность файла относительно индексов репозитория. Уязвимости в самом пакете — отдельная тема, за ней следят службы безопасности Debian и выпускат обновления, которые вы получаете тем же механизмом.

Почему в индексах до сих пор встречаются MD5?

Для обратной совместимости со старыми инструментами и как быстрая проверка целостности при передаче. Решение о доверии принимается по SHA-256/512 и подписям, а не по MD5.

Что надёжнее: сверять хеш вручную или ставить через apt?

Через apt. Ручная сверка имеет смысл, когда пакет взят вне обычного потока репозитория, и она безопасна только при условии, что эталонная сумма получена из подписанного источника.

Может ли атакующий подменить и пакет, и индексы?

Только если он также подделает GPG-подпись Release-файла или добьётся того, что ваша система примет чужой ключ. Именно поэтому ключ архива Debian распространяется заранее и отдельно, а apt предупреждает о неподписанных или изменивших ключ репозиториях.

Что запомнить и что делать дальше

Хеши в Debian работают как многоуровневая система сверок: подписанный Release-файл защищает индексы, индексы защищают пакеты, а локальные манифесты позволяют проверять уже установленные файлы. Главный принцип — доверие передаётся по цепочке от подписанного ключа, и любое звено без подписи эту цепочку рвёт.

• Держите стандартную конфигурацию источников: apt сам выполнит все проверки, и вручную ничего сверять не придётся.
• При ошибке Hash Sum mismatch начинайте с очистки кэша и смены зеркала — в подавляющем большинстве случаев причина на стороне передачи данных, а не угрозы безопасности.
• При ручной проверке образов и отдельных пакетов сначала проверяйте подпись файла с суммами и только потом сам файл.
• Для аудита установленной системы используйте debsums, помня об ограничениях локальных MD5-манифестов.

Конкретные детали — набор поддерживаемых алгоритмов, формат полей индексов, поведение apt — зависят от выпуска Debian и версии пакетного менеджера. Перед принятием решений, связанных с безопасностью инфраструктуры, сверяйтесь с официальной документацией вашего выпуска и политикой безопасности вашей организации.