В современном мире программного обеспечения поддержка и обновление пакетов играет ключевую роль в безопасности и стабильности операционных систем, особенно для Linux-дистрибутивов, основанных на Debian. Технология Acquire-By-Hash стала важным шагом к повышению надежности процесса обновления пакетов в репозиториях APT. Несмотря на то что она появилась достаточно давно, она не получила единодушной поддержки во всех дистрибутивах, что приводит к различным проблемам и ошибкам у конечных пользователей. Рассмотрение работы Acquire-By-Hash, особенности её реализации и примеры сложностей на примере Kali Linux помогут лучше понять, почему эта технология имеет большое значение для разработчиков репозиториев и пользователей систем на базе APT. Ключевой этап при обновлении пакетов с помощью команды apt update заключается в скачивании релизного файла (Release file), который содержит список доступных индексационных файлов, а также контрольные суммы для них.
Эти индексационные файлы — это различные пакеты данных, такие как Packages, Sources, Contents и другие, которые информируют пакетный менеджер о доступных пакетах и их метаданных. При нормальной работе apt сначала скачивает Release, затем — перечень указанных в нем файлов, проверяет их контрольные суммы и только после этого обновляет локальную базу данных. Проблема возникает в момент обновления репозитория на сервере. Если файлы обновляются «на месте», то происходит ситуация, когда Release файл указывает на один набор индексационных файлов, а сами файлы в момент скачивания клиентом могут быть уже обновлены или частично обновлены. Это приводит к ошибкам проверки контрольных сумм — известному сообщению "Hash Sum Mismatch", с которым сталкивались многие пользователи.
АPT не может гарантировать консистентность данных, так как индексные файлы не являются неизменяемыми. Чтобы решить эту проблему, была введена концепция Acquire-By-Hash. Она основана на том, что все индексные файлы, размещаемые в репозитории, именуются и доступны по адресам, основанным на их хэшах, например, SHA256. Таким образом, каждый индексный файл становится уникальным и неизменным по своему адресу. Сам релизный файл ссылается на эти хэшированные пути вместо стандартных канонических имен.
Благодаря этому можно обеспечить, что клиент скачивает именно тот файл, который описан в релизе, независимо от того, как и когда сервер его обновлял. Именно благодаря этой архитектуре достигается атомарность обновлений репозитория. Новые индексные файлы добавляются в директорию по хэшу, старые остаются доступными на некоторое время, что позволяет клиентам переходить между старой и новой версией набора данных без ошибок. По сути, обновление репозитория становится бесшовным для пользователя. Разумеется, для использования Acquire-By-Hash на стороне клиента пакетный менеджер должен поддерживать это поведение.
В настоящее время Debian, Ubuntu и многие другие популярные дистрибутивы поддерживают эту функцию. Это можно проверить, взглянув на заголовок Acquire-By-Hash в Release файле репозитория — если там указано Acquire-By-Hash: yes, значит функциональность активна и используется. Однако не все Debian- производные дистрибутивы перешли на эту технологию. Одним из ярких примеров является Kali Linux — специализированный дистрибутив для тестирования на проникновение и информационной безопасности. Kali по-прежнему не поддерживает Acquire-By-Hash в своем репозитории.
Это связано с тем, что Kali при формировании своего репозитория использует популярный инструмент reprepro, который до сих пор не интегрировал поддержку Acquire-By-Hash. Такая ситуация создает ряд проблем, связанных с надежностью обновления и стабильностью работы apt в Kali. У уникальной структуры репозитория Kali есть одна особенность: вместо обращения напрямую к определенному серверу APT запросы клиентов перенаправляются на так называемый redirector — веб-сервер, который далее перенаправляет запросы на ближайшие к пользователю зеркала. На первый взгляд, это позволяет ускорить загрузку пакетов и оптимизировать нагрузку. Но в условиях отсутствия Acquire-By-Hash это создает риск возникновения ошибок.
Например, если зеркало было недавно обновлено, а соседнее — еще нет, пользователь может получить несовместимые версии релизного файла и пакетов, что вызовет ошибку "Hash Sum Mismatch". Продолжительность этого «окна» несогласованности может варьироваться от нескольких секунд до многих минут в зависимости от географического расположения пользователя и скорости обновления зеркал. Интересной деталью является существование в пуле зеркал Kali своего рода «суперзеркала» — CDN-сервиса Cloudflare (kali.download), который синхронизируется сразу и быстрее остальных. Это приводит к ситуации, когда часть запросов пользователя идет на CDN с уже обновленным репозиторием, а часть — на локальное зеркало, которое ещё не завершило обновление.
В результате время, в течение которого возникают ошибки, может достигать получаса. Тем не менее APT использует один хитрый прием. При обнаружении перенаправления при запросе Release файла, последующие запросы на индексационные файлы ставятся именно к тому же серверу, куда произошел редирект. Благодаря этому клиент получает единообразные данные и минимизируется риск ошибок в пределах одного сеанса обновления. При этом данное решение становится неэффективным, если между клиентом и сервером находится кеширующий прокси.
Прокси, например approx, сглаживает все запросы и не передает информацию о редиректах клиенту. В результате значит, что при обновлении пакетов кеширующий прокси может сталкиваться с неоднородностью репозиториев разных зеркал, что приводит к частым ошибкам и нарушению работы apt. В таких ситуациях рекомендуют не использовать redirector, а напрямую указывать конкретное зеркало или суперзеркало. Еще одна область, где отсутствия поддержки Acquire-By-Hash дает о себе знать — это установка Kali Linux через debootstrap. Этот инструмент для минимальной установки системы использует wget без сложной логики работы с редиректами.
Из-за этого debootstrap может получить Release файл с одного зеркала, а затем Packages с другого, что приводит к ошибкам проверки и повторным попыткам загрузки. Хотя debootstrap пытается исправить ситуацию, повторяя запросы, процесс становится более долгим и ненадежным. Впоследствии, при переходе из базовой установки на полноценную систему с полным списком компонентов, вновь возникают сложности. При обращении apt update после добавления новых компонентов, если релизный файл локально не обновляется (получая ответ 304 Not Modified), клиент делает запросы к redirectorу для скачивания новых индексов. В случае отсутствия правильной обработки редиректов у индексов он снова может попасться на зеркала, которые не синхронизированы между собой.
Это особенно заметно у разработчиков и продвинутых пользователей. Для решения подобных ситуаций есть несколько подходов. Самый логичный — внедрить полноценную поддержку Acquire-By-Hash в инструменты формирования репозиториев Kali, в частности в reprepro. Несмотря на сложности и масштаб кода, это решило бы фундаментально проблему атомарности обновлений и сделало бы работу пакетов более надежной. Альтернативным способом является использование других решений для создания репозиториев, таких как aptly.
Этот инструмент уже поддерживает Acquire-By-Hash и может быть внедрен в инфраструктуру Kali для улучшения стабильности. Параллельно можно применять разные обходные пути — отключение redirector, использование конкретных зеркал или суперзеркал, сброс локального кеша. Тем не менее эти способы носят временный и не идеальный характер, оставляя проблемы сложными для непрофессиональных пользователей. Подводя итог, можно сказать, что технология Acquire-By-Hash оказалась важной ступенью в эволюции систем обновления пакетов на базе APT. Она качественно уменьшает вероятность возникновения критических ошибок, связанных с обновлением репозиториев, особенно в конфигурациях с большим количеством зеркал и высокой частотой обновлений.
Несмотря на это, неполная поддержка в некоторых популярных дистрибутивах создает множество технических вызовов и усложняет работу. Внедрение поддержки Acquire-By-Hash в Kali Linux и другие системы, использующие reprepro, позволит сделать обновления стабильнее и практичнее для пользователей и разработчиков. Это станет логичным шагом к улучшению инфраструктуры по управлению пакетами, обеспечивающим безопасность и удобство работы с Linux-системами в будущем.
