. Пакеты APT в основном и вселенной всегда гарантированы из источника Ubuntu или Debian Mantainers?
Интересно, если канонические (и / или Debian) предоставляют какую-либо гарантию, что все пакеты в основных и вселенных REPOS всегда либо построены из источника самостоятельно, либо подтверждены им (в случае детерминированного или подписанного воспроизводимых наращиваний ), в отличие от того, что только в том числе двоичные файлы, составленные другими (что подразумевает, что вы должны доверять им, чтобы не делать что-то тенистые или неяснить их процесс компиляции, или использовать что-нибудь за пределами публичного источника REPO, кроме частных ключей для подписания, где это применимо) Отказ
Что такое политика Debian и Ubuntu? У них есть официальные страницы или заявления по этому вопросу? Я ожидаю, что они сделают это хотя бы для главных, но как насчет вселенной? Кто я «доверяю» (предоставить то, что они утверждают, что скомпилированы), когда я устанавливаю что-то из Вселенной? Просто каноническое / Debian или также сами авторы?
связано: (Некоторые информация, которую я обнаружил на воспроизводимых сборках, в основном старых)
3 ответа
Пакеты в главном и вселенной построены в ферме сборки пусковой площадки, из исходников. Вам не нужно спрашивать об этом, так как вы можете найти его самостоятельно.
Например, на момент написания статьи последняя сборка bind, загруженная в Ubuntu 20.04 LTS (Focal) равна 1:9.16.1-0ubuntu2.5. Вы можете увидеть это в открытом списке рассылки focal-changes. А именно этот пост , который ссылается на пусковую панель , где вы можете увидеть исходные файлы и сборки, а также построить журналы для каждой поддерживаемой архитектуры. Например, сборка amd64 для этой версии пакета находится здесь с журналом сборки здесь.
Вы можете повторить этот процесс для каждого пакета в каждом выпуске Ubuntu.
Хотя я упомянул main и universe, то же самое верно и для ограниченных и мультиверсных пакетов, которые также собираются на launchpad. Однако они могут содержать несвободные компоненты, поэтому сборка "из исходных текстов" не гарантируется, но для каждого из них есть пакет исходных текстов, даже если он содержит некоторые бинарные компоненты.
Упрощенный ответ заключается в том, что пакеты в Ubuntu всегда собираются на автосборщиках Ubuntu из исходных пакетов в архиве. До недавнего времени Debian позволял двоичным пакетам, собранным отдельными сопровождающими, проходить тестирование и, в конечном итоге, быть стабильными, что больше не разрешалось с тех пор, как тестовая миграция была открыта для цикла "бычий глаз", но разработчикам Debian всё ещё разрешено и в некоторых случаях требуется загружать двоичные пакеты в нестабильном состоянии. В Ubuntu гораздо строже введены внешние двоичные пакеты.
Однако упрощённый ответ оставляет несколько пробелов.
Во-первых, нет никакой технической меры, гарантирующей, что материалы, используемые из пакета исходных текстов, на самом деле являются исходным текстом. В самом деле, этого не может быть, потому что понимание термина "исходный текст" в сообществе Debian больше похоже на определение GPL, чем на традиционное определение, и, следовательно, больше зависит от того, как файл создаётся и сопровождается, чем от того, в каком формате он представлен.
Во-вторых, содержание двоичного пакета Debian зависит не только от пакета исходного текста, но и от окружения, в котором он собран. Это окружение формируется путём установки двоичных пакетов.
Что подводит нас к вопросу, что некоторые программы требуют самостоятельно собирать. gcc, glibc, binutils, make и т.д. rust требует rust. freepascal требует freepascal. golang обычно собирается с помощью golang (он утверждает, что также может быть собран с помощью gccgo, но когда я попытался, на самом деле это не сработало).
В большинстве случаев для этого используется предыдущая версия, но иногда что-то идёт не так, и собрать один из этих пакетов обычным путём становится невозможно, потому что существующая версия пакета слишком поломана на одной или нескольких архитектурах.
Иногда сопровождающие будут работать над этим, включая в пакет исходного текста двоичные файлы, обвязывающие загрузку. В других случаях пакеты в архиве будут перезагружены с помощью вручную собранных двоичных пакетов. В debian это обычно делается разработчиком, который просто загружает двоичные пакеты в архив, а затем после этого загружает исходный текст, чтобы заставить пересобирать их на автосборщиках. В Ubuntu я не знаю точно, что это за процедура, но я знаю, что только относительно небольшое количество людей имеют на это разрешение.
Не используйте GCC-5, что вызывает Ubuntu специально искать GCC 5.x, который устарел в годы и не установлен на большинстве систем. Просто используйте «GCC» в качестве команды, которая будет делегировать по умолчанию, установлена версия GCC (в вашем случае 9.3).
Если вы следуете за руководством, который говорит вам, чтобы запустить скрипт, найдите новое руководство или отредактируйте скрипт.
-121--910007-С точки зрения Debian: все пакеты построены на наших выделенных серверах (Buildds). Пакеты, которые не настроен на Buildd, не могут перемещаться в тестирование и попасть в стабильный выпуск. Кроме того, каждый пакет, построенный с примерно в 2018 году, включает в себя файл .buildInfo: хотя это не гарантирует воспроизводимые сборки, он включает их. Все пакеты в Bullseye имеют этот файл, благодаря последним усилиям разработчика Debian, чтобы вызвать эти перестройки для редко обновленных пакетов (например, пакеты шрифтов).
В целом, люди на Debian - это большие вентиляторы воспроизводимых сборки, и многие люди, подталкивая их, являются частью проекта. Инструменты для сооружения воспроизводимости интегрированы в инфраструктуру: например, пакеты, как правило, будут построены со стандартизированными временными метками, и в ближайшее время будут построены стандартизированные местоположения.