Почему Buildroot требует файлы хэшей в BR2_GLOBAL_PATCH_DIR

Почему Buildroot требует файлы хэшей в BR2_GLOBAL_PATCH_DIR

Buildroot требует добавления файлов хэшей в BR2_GLOBAL_PATCH_DIR в качестве меры безопасности для обеспечения целостности всех пакетов, даже тех, которые не патчатся напрямую. Это поведение является следствием системы проверки хэшей Buildroot, которая проверяет загруженные архивы на соответствие известным хорошим хэшам для предотвращения подделки и обеспечения воспроизводимых сборок. При настройке BR2_GLOBAL_PATCH_DIR Buildroot расширяет свою механизм проверки хэшей, включая этот каталог для всех пакетов, требуя существования файлов хэшей даже для пакетов, которые вы не изменяете.

Содержание

• Почему Buildroot требует файлы хэшей
• Механизм проверки хэшей
• Объяснение текущего поведения
• Возможные решения
• Лучшие практики
• Альтернативные подходы

Почему Buildroot требует файлы хэшей

Buildroot реализует проверку хэшей как основную функцию безопасности для обеспечения того, чтобы все загружаемые пакеты сохраняли свою целостность в процессе сборки. Согласно официальной документации Buildroot, эта система “проверяет целостность загруженных архивов” на соответствие известным хорошим хэшам.

Когда вы устанавливаете BR2_GLOBAL_PATCH_DIR, вы сообщаете Buildroot искать дополнительные патчи и файлы хэшей в этом каталоге. Система разработана для быть всеобъемлющей - если она проверяет патчи из каталога, она также проверяет наличие соответствующих файлов хэшей для поддержания согласованности безопасности. Это означает, что даже для пакетов, которые вы не патчите, Buildroot ожидает существования файлов хэшей в глобальном каталоге патчей.

Обоснование такого дизайна ориентировано на безопасность: если Buildroot собирается доверять патчам из каталога, он также должен доверять загрузкам пакетов, проверяя их хэши. Это предотвращает потенциальные уязвимости безопасности, когда кто-то может изменять загружаемые пакеты, оставляя патчи нетронутыми.

Механизм проверки хэшей

Система проверки хэшей работает через несколько ключевых компонентов:

1. Логика расположения файлов хэшей: Как показано в фрагменте pkg-generic.mk, который вы предоставили, Buildroot строит пути к файлам хэшей, перебирая несколько каталогов:

   makefile

   $(2)_HASH_FILES = \
       $$(strip \
           $$(foreach d, $$($(2)_PKGDIR) $$(addsuffix /$$($(2)_RAWNAME), $$(call qstrip,$$(BR2_GLOBAL_PATCH_DIR))),\
               $$(if $$(wildcard $$(d)/$$($(2)_VERSION)/$$($(2)_RAWNAME).hash),\
                   $$(d)/$$($(2)_VERSION)/$$($(2)_RAWNAME).hash,\
                   $$(d)/$$($(2)_RAWNAME).hash\
               )\
           )\
       )
   

2. Файлы хэшей, специфичные для версии: Система сначала ищет файлы хэшей, специфичные для версии (такие как package-version.hash), и переходит к общим файлам хэшей (таким как package.hash), если файлы для версии не существуют.

3. Процесс проверки хэшей: На этапе загрузки Buildroot сравнивает загруженные файлы с этими файлами хэшей. Если файл хэша не существует, сборка завершается ошибкой, как в вашем случае.

Этот механизм описан в руководстве по настройке патчей Buildroot, где объясняется, что “дополнительные хэши ищутся аналогично дополнительным патчам” и что “для каждого каталога в BR2_GLOBAL_PATCH_DIR используется первый найденный файл”.

Объяснение текущего поведения

Поведение, с которым вы столкнулись, является намеренным и задокументированным. Когда вы устанавливаете BR2_GLOBAL_PATCH_DIR, Buildroot рассматривает этот каталог как доверенное расположение как для патчей, так и для проверки хэшей для всех пакетов.

Из вашего примера вывода:

DTC_HASH_FILES=package/dtc//dtc.hash /home/admin/buildroot-external-my/patches/dtc/dtc.hash

Это показывает, что Buildroot ищет файлы хэшей в двух местах:

1. Стандартный каталог пакетов (package/dtc//dtc.hash)
2. Ваш глобальный каталог патчей (/home/admin/buildroot-external-my/patches/dtc/dtc.hash)

Система требует существования хотя бы одного из этих файлов хэшей. Если вы не изменяете исходный код пакета (не добавляете патчи), стандартный хэш пакета должен быть достаточным, но Buildroot все равно проверяет глобальный каталог патчей как часть своего всеобъемлющего процесса проверки.

Как отмечено в обсуждении на почтовом списке Buildroot, когда вы сталкиваетесь с ошибками хэшей, вы можете либо полностью отключить проверку хэшей, либо “создать каталог, где вы храните свои собственные файлы хэшей, и добавить его в BR2_GLOBAL_PATCH_DIR”.

Возможные решения

Вариант 1: Создание файлов хэшей для всех пакетов

Прямое решение - создать требуемые файлы хэшей. Вы можете использовать скрипт utils/add-custom-hashes, упомянутый в коммите Buildroot, для управления этим:

make foo_defconfig
./utils/add-custom-hashes

Этот скрипт помогает генерировать и управлять файлами хэшей для вашего глобального каталога патчей.

Вариант 2: Отключение проверки хэшей для конкретных пакетов

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

Вариант 3: Изменение pkg-generic.mk (не рекомендуется)

Хотя вы можете изменить pkg-generic.mk, чтобы сделать проверку файлов хэшей условной, это обычно не рекомендуется, потому что:

• Это нарушает модель безопасности, реализованную в Buildroot
• Требует поддержки пользовательских патчей для самого Buildroot
• Может вызвать проблемы с будущими обновлениями Buildroot
• Может скрыть потенциальные проблемы безопасности

Лучшие практики

1. Использование отдельных каталогов: Рассмотрите возможность использования отдельных каталогов для патчей и файлов хэшей. Вы можете установить BR2_GLOBAL_PATCH_DIR в каталог патчей и обрабатывать файлы хэшей иначе.

2. Автоматическая генерация файлов хэшей: Используйте скрипт utils/add-custom-hashes для генерации файлов хэшей для пакетов, которые вы хотите проверить во внешнем каталоге.

3. Выборочное управление хэшами: Создавайте файлы хэшей только для пакетов, которые вы действительно настраиваете или хотите проверять из вашего внешнего каталога.

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

5. Контроль версий: Включайте сгенерированные файлы хэшей в систему контроля версий для обеспечения воспроизводимых сборок в разных средах.

Альтернативные подходы

Если вы хотите сохранить преимущества безопасности без административных накладных расходов, рассмотрите эти альтернативы:

1. BR2_PACKAGE_OVERRIDE_SRCDIR: Для пакетов, которые вы не патчите, но хотите использовать пользовательские источники, рассмотрите использование механизма BR2_PACKAGE_OVERRIDE_SRCDIR, упомянутого в руководстве пользователя Buildroot. Это позволяет указывать пользовательские расположения исходного кода без требования файлов хэшей в глобальном каталоге патчей.

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

3. Внешнее дерево Buildroot: Используйте систему br2-external для поддержки ваших пользовательских пакетов и конфигураций отдельно от основного дерева Buildroot, что может помочь более чисто управлять требованиями к файлам хэшей.

Ключевой вывод заключается в том, что система проверки хэшей Buildroot разработана с безопасностью в качестве основного concern, а требование файлов хэшей в BR2_GLOBAL_PATCH_DIR является намеренным поведением, а не ошибкой. Хотя это создает некоторые административные накладные расходы, оно обеспечивает сохранение целостности всех пакетов в процессе сборки.

Источники

1. Документация по настройке патчей Buildroot
2. Механизм файлов хэшей в pkg-generic.mk
3. Обсуждение на почтовом списке Buildroot о файлах хэшей
4. Коммит в git Buildroot о скрипте пользовательских хэшей
5. Руководство пользователя Buildroot о переопределении каталога исходного кода
6. Обсуждение на Stack Overflow о BR2_GLOBAL_PATCH_DIR

Заключение

Требование Buildroot к файлам хэшей в BR2_GLOBAL_PATCH_DIR является сознательной функцией безопасности, предназначенной для обеспечения целостности пакетов. Хотя это создает административные накладные расходы, оно служит важной цели поддержания безопасности сборки и воспроизводимости. Вместо изменения основной логики Buildroot рекомендуется либо генерировать требуемые файлы хэшей с помощью доступных инструментов, либо пересмотреть структуру каталога для лучшего соответствия предполагаемым шаблонам использования Buildroot. Скрипт utils/add-custom-hashes предоставляет эффективный способ управления этими файлами хэшей после понимания базовой модели безопасности.