Пакеты

Я публикую подписанный репозиторий пакетов, и вот как это работает.

Системный администратор настраивает репозитории, добавляя файл конфигурации, например /usr/local/etc/pkg/repos/JdeBP.conf . При этом xe сообщает диспетчеру пакетов открытый ключ, который будет использоваться для проверки подписей в репозитории. Xe получает этот ключ от меня надежным способом и сохраняет его в файле где-нибудь вроде /usr/local/etc/pkg/keys/JdeBP.pub . Затем Xe называет его файлом открытого ключа в /usr/local/etc/pkg/repos/JdeBP.conf .

Я подписываю репозиторий пакетов закрытым ключом, который есть только у меня, с помощью команды pkg repo. / в другом месте / ключ_пакета .Это создает подписанную информацию о репозитории и пакетах в трех файлах: meta.txz , digests.txz и packagesite.txz . В каждом из этих архивов есть два файла, один из которых является файлом сигнатуры для другого. Дайджесты и архивы сайтов пакетов содержат хэши каждого из файлов архивов пакетов. Мета-архив содержит только имена двух других и некоторую информацию о версиях инструмента pkg-ng.

Это очень похоже на Secure APT. Есть некоторые отличия:

• Вместо Release , дающей контрольные суммы для пакетов и пакетов , а затем хешей для фактических архивов пакетов, pkg-ng имеет всего один уровень. packagesite.yaml предоставляет хеши фактических архивов пакетов напрямую.
• Вместо того, чтобы разбивать файлы на отдельно загружаемые файлы Release и Release.gpg , а затем файлы Packages и Sources , файл packagesite.yaml (охватывающий весь репозиторий) и его подпись загружаются как единое целое за одну операцию fetch (и одну транзакцию HTTP / FTP) как файл packagesite.txz .

Но идея во многом та же. Системный администратор полагает, что файл packagesite.yaml пришел от меня, потому что сопровождающая его подпись может быть проверена на локально сохраненной доверенной копии моего открытого ключа. Системный администратор полагает, что redo-1.3.Файл txz пришел от меня, потому что его хеш соответствует хешам из (теперь) доверенного packagesite.yaml .

Порты

Порты - совсем другое дело. Безопасный APT Debian рассматривает пакеты с исходным кодом как просто дополнительные пакеты. Порты FreeBSD / TrueOS не являются пакетами с исходным кодом в смысле Debian, а представляют собой скорее автоматизированные способы получения и сборки пакетов с исходным кодом, опубликованных кем-то другим. Порт - это, по сути, make-файл с некоторыми инструкциями о том, откуда получить исходный код . В нем есть список хэшей (а) всего, что нужно получить.

Сам порт поступает из репозитория FreeBSD или TrueOS с использованием либо Subversion (если FreeBSD), либо git (если TrueOS или FreeNAS). Таким образом, применимы стандартные идеи доверия Subversion или git. В TrueOS, например, «удаленный» URL-адрес, используемый при выборке портов (самих себя) с помощью git, является URL-адресом HTTPS для репозитория GitHub, который iXsystems поручает (в Справочнике TrueOS ) является тем, которым он владеет.

Таким образом, системный администратор доверяет порту, потому что xe получил его с помощью Subversion или git fetch, которому доверяет xe. Xe доверяет исходному архиву, полученному портом, потому что он соответствует хэшу, указанному в (теперь) доверенном порте.

Примечания

Debian Release.gz и Packages.gz , по сути, представляют собой просто способы сжатия транспорта HTTP. Я замалчивал некоторые другие вещи, которые не имеют отношения к безопасности, например различия в том, как предполагается обрабатывать несколько выпусков операционной системы.

Debian на протяжении многих лет двигался к тому, как работает FreeBSD, и больше не работает, как говорится на этой странице вики. В настоящее время хеши и подпись хранятся в одном месте, больше похоже на репозиторий FreeBSD, в файле InRelease .Это предотвращает проблему "разрывов", которая возникает, когда один загружает Release , а затем Release.gpg , и владелец репозитория обновляет репозиторий между двумя загрузками, что приводит к несоответствию подписи .

(Первоначально Debian поступал таким образом только потому, что он развивал эти вещи поэтапно на протяжении многих лет, каждый из которых был построен на предыдущих механизмах, не меняя их: сначала система Package , затем Release , а затем механизм Release.gpg .)

Также: FreeBSD имеет другой, отличный способ сделать это, который включает «отпечатки пальцев» и подписанный файл дайджеста (в архиве digests.txz ).

Я также замалчивал соображения безопасности для ключа подписи, так как это не имеет отношения к ответу, в котором обсуждается, как это похоже / в отличие от Secure APT. Требования к безопасности закрытого ключа являются общими для всего понятия подписи вещей открытыми / закрытыми ключами и не зависят от структур репозитория.

Дополнительная литература

• Джонатан де Бойн Поллард (2016). Репозитории пакетов . Программное обеспечение.
• Колин Уотсон (8 апреля 2016 г.). Больше нет ошибок «Несоответствие хэш-суммы» .