Репозиторий не подписан debian

Обновлено: 21.11.2024

Все о безопасном соединении

Debian использует надежную криптографию для проверки загруженных пакетов. Это обычно называется «secure apt» (или «apt-secure») и было реализовано в Apt версии 0.6 в 2003 году, на которую Debian перешел в 2005 году. с точки зрения администратора, в этом документе мы попытаемся подробно объяснить, как работает secure apt и как его использовать.

В этой статье обсуждаются вопросы на относительно высоком уровне. Подробнее о формате файлов репозиториев Debian см. на странице DebianRepository/Format. Для получения подробной информации о командах обратитесь к справочным страницам инструментов.

  1. Все о безопасном подключении
  2. Основные понятия
  3. Надежная основа: контрольные суммы
  4. Подписанные файлы выпуска
  5. Как apt использует Release.gpg
  6. Как определить, чему доверять
  7. Как найти и добавить ключ
  8. Как узнать, безопасен ли ключ
  9. Срок действия ключа архива Debian
  10. Как вручную проверить целостность пакета
  11. Другие проблемы
  12. Настройка безопасного репозитория apt
  13. Неудачные обновления и отсутствующие ключи
  14. История
  15. Комментарии и вопросы

Основные понятия

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

Защищенная хэш-функция (разновидность контрольной суммы) – это метод, позволяющий взять файл и свести его к достаточно короткому числу, которое однозначно идентифицирует содержимое файла, даже если люди намеренно пытаются создать пару разные файлы с одинаковой контрольной суммой или создать новый файл, соответствующий предыдущей контрольной сумме. Первоначально APT был разработан на основе MD5, но с тех пор людям удалось создать коллизии, поэтому была добавлена ​​поддержка новых хэш-функций.

Криптография с открытым ключом основана на паре ключей: открытом ключе и закрытом ключе. Открытый ключ выдается миру; закрытый ключ должен храниться в секрете. Любой, у кого есть открытый ключ, может зашифровать сообщение, чтобы его мог прочитать только тот, у кого есть закрытый ключ. Также можно использовать закрытый ключ для подписи файла, а не для его шифрования. Если для подписи файла используется закрытый ключ, то любой, у кого есть открытый ключ, может проверить, был ли файл подписан этим ключом. Любой, у кого нет закрытого ключа, не может подделать такую ​​подпись.

Эти ключи представляют собой довольно длинные числа (не менее 1024 бит, т.е. 256 или более шестнадцатеричных цифр, а лучше намного больше), и для облегчения работы с ними у них есть более короткий идентификатор ключа, 8 или 16. цифровое число, которое можно использовать для обозначения их. Однако следует соблюдать осторожность с идентификаторами ключей, особенно с коротким идентификатором из 8 символов, так как это может привести к конфликтам.

gpg — это инструмент, используемый в безопасном apt для подписи файлов и проверки их подписей.

apt-key — это программа, которая используется для управления набором ключей gpg для безопасного доступа к apt. Брелок хранится в файле /etc/apt/trusted.gpg (не путать с родственным, но не очень интересным файлом /etc/apt/trustdb.gpg). apt-key можно использовать для отображения ключей в связке ключей, а также для добавления или удаления ключа. В более поздних версиях Debian GNU/Linux (например, Wheezy) наборы ключей хранятся в определенных файлах, расположенных в каталоге /etc/apt/trusted.gpg.d. Например, этот каталог может содержать следующие файлы: debian-archive-squeeze-automatic.gpg или debian-archive-wheezy-automatic.gpg. Между прочим, оба файла входят в состав пакета debian-archive-keyring.

Надежная основа apt: контрольные суммы

Архив Debian содержит файл Release, который обновляется каждый раз при изменении любого из пакетов в архиве. Помимо прочего, файл Release содержит некоторые контрольные суммы других файлов в архиве. Фрагмент примера файла Release:

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

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

В этом нет ничего нового для secure apt, но они обеспечивают основу. Обратите внимание, что пока есть один файл, который apt не может проверить: файл Release. Безопасный apt заключается в том, чтобы заставить apt проверять файл Release, прежде чем делать с ним что-либо еще, и затыкать эту дыру, чтобы существовала цепочка проверки от пакета, который вы собираетесь установить, до провайдера. пакет.

Подписанные файлы релиза

Чтобы закрыть дыру, secure apt добавляет подпись gpg к файлу Release. Это помещается в файл с именем Release.gpg, поставляемый вместе с файлом Release. Выглядит это примерно так, хотя реально нормально просматривает его содержимое только gpg:

(Технически говоря, это отдельная gpg-подпись в формате ascii.)

Как apt использует Release.gpg

Secure apt всегда загружает файлы Release.gpg при загрузке файлов Release, и если он не может загрузить Release.gpg или если подпись неверна, он будет жаловаться и отмечать, что файлы Packages, которые файл Release указывает на, и все перечисленные в нем пакеты получены из ненадежного источника. Вот как это выглядит во время обновления apt-get:

Обратите внимание, что вторая половина длинного числа — это идентификатор ключа, о котором apt не знает, в данном случае это 2D230C5F.

Если вы проигнорируете это предупреждение и попытаетесь установить пакет позже, apt снова выдаст предупреждение:

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

Обратите внимание, что вы можете отключить эти проверки, запустив apt с параметром --allow-unauthenticated.

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

Как определить, чему доверять

Таким образом, безопасность всей системы зависит от наличия файла Release.gpg, который подписывает файл Release, и от правильной проверки этой подписи с помощью gpg. Для проверки подписи необходимо знать открытый ключ лица, подписавшего файл. Эти ключи хранятся в собственной связке ключей apt (/etc/apt/trusted.gpg), и управление ключами — это место, где вступает в действие безопасный apt.

По умолчанию системы Debian поставляются с предварительно сконфигурированным ключом архива Debian в наборе ключей.

Здесь 55BE302B — это идентификатор ключа, и обратите внимание, что этот ключ действителен только в течение ограниченного периода времени. Debian время от времени меняет эти ключи в качестве последней линии защиты от какого-либо нарушения безопасности, ломающего ключ.

Это позволит apt доверять официальному архиву Debian, но если вы добавите какой-либо другой репозиторий apt в /etc/apt/sources.list, вам также придется указать ключ apt, если вы хотите, чтобы ему доверяли. После того, как у вас есть ключ и вы его проверили, добавить его можно просто с помощью команды «apt-key add file». Получение ключа и его проверка — более сложная часть.

Как найти и добавить ключ

Пакет debian-archive-keyring используется для распространения ключей на apt. Обновления этого пакета могут добавлять (или удалять) ключи gpg для основного архива Debian.

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

Gpg сама распределяет ключи стандартным способом, используя сервер ключей, с которого gpg может загрузить ключ и добавить его в свою связку ключей. Например:

Затем вы можете экспортировать этот ключ из своей связки ключей и передать его в apt-key:

(Что означает предупреждение «gpg: не найдено ни одного надежного ключа»? --> Предупреждение: «не найдено абсолютно надежного ключа» означает, что gpg не был настроен на максимальное доверие определенному ключу. Параметры доверия являются частью OpenPGPs Web-of-Trust, который здесь не применяется. Таким образом, с этим предупреждением нет проблем. В обычных настройках в конечном итоге доверяется собственному ключу пользователя.)

Как узнать, безопасен ли ключ

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

(Примечание. Не все ключи репозитория apt вообще подписаны другим ключом. Возможно, у человека, настраивающего репозиторий, нет другого ключа, или, может быть, ему неудобно подписывать такой ролевой ключ своим основным ключом. .)

Если вы не можете позволить себе такой уровень паранойи, делайте все, что считаете нужным, при добавлении нового подходящего источника и нового ключа. Возможно, вы захотите написать человеку, предоставившем ключ, и проверить его, или, может быть, вы готовы рискнуть, загрузив его и предполагая, что вы получили настоящую вещь.Важно то, что, сводя проблему к тому, каким архивным ключам доверять, secure apt позволяет вам быть настолько осторожным и безопасным, насколько вам удобно.

Вот сообщение в блоге с процедурой проверки целостности ключа. См. также Защита Debian, глава 7.

Срок действия ключа архива Debian

С тех пор, как был представлен безопасный apt, ключи, используемые для подписи основного архива Debian, несколько раз менялись. Так как secure apt молодой, у нас нет большого опыта смены ключа, и до сих пор есть шероховатости.

В январе 2006 года был создан новый ключ для 2006 года, и файл Релиза стал подписываться им, но во избежание поломки систем, в которых был старый ключ 2005 года, файл Релиза также был подписан им. Намерение состояло в том, что apt будет принимать ту или иную подпись в зависимости от имеющегося у него ключа, но apt оказался ошибочным и отказался доверять файлу, если у него нет обоих ключей и он не может проверить обе подписи. Это было исправлено в версии 0.6.43.1. Также возникла путаница в отношении того, как ключ распространялся среди пользователей, у которых уже были системы, использующие безопасный apt; изначально он был загружен на веб-сайт без объявления и без реального способа проверить его, и пользователи были вынуждены загружать его вручную. Это было исправлено введением пакета debian-archive-keyring, который управляет корректными обновлениями набора ключей.

В конце 2006 г. был создан новый ключ, который будет использоваться для подписи архива в течение всего времени существования выпуска Debian 4.0 (до 01 июля 2009 г.). Архив начал подписываться этим новым ключом в дополнение к годовому ключу подписи на 2006 год. Это немного сбивало с толку, потому что ключ начали использовать до того, как он был объявлен, и до того, как debian-archive-keyring был обновлен, чтобы включить его! Предупреждающее сообщение Apt в этой ситуации немного непрозрачно для конечных пользователей. Очевидно, что еще есть возможности для улучшения того, как мы развертываем новые ключи. Этот новый ключ отвечает на вопрос, как пользователи версии 4.0 (etch) смогут проверять свое программное обеспечение на протяжении всего срока службы этой версии. Этот новый ключ также используется для подписи других версий Debian (например, нестабильных).

7 февраля 2007 г. срок действия ключа 2006 г. истек. В настоящее время единственная известная поломка этого заключается в том, что он сломал rc1 установщика etch, поскольку образы установщика знают только о ключе 2006 года. Ежедневные сборки установщика имеют ключ 2007 и продолжают работать.

Недавно был добавлен новый ключ стабильной версии Etch. Это автономный ключ, который будет использоваться для подписи выпусков Etch (включая точечные выпуски).

Как вручную проверить целостность пакета

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

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

Примечание: вам придется импортировать открытый ключ для архива, если его нет в вашей связке ключей; и используйте ваш текущий дистрибутив вместо "sid".

После этого вы проверяете md5sums файла Packages для каждого из компонентов. Например:

Наконец, мы проверяем контрольную сумму MD5 или SHA самого пакета.

Этот раздел далек от завершения, но мы ожидаем, что он станет хорошим вводным материалом для изучения цепочки доверия пакетов Debian.

TODO: Добавить проверку подписи: краткое введение в dscverify.

Другие проблемы

  • Одна не столь очевидная проблема заключается в том, что если ваши часы сильно отстают, безопасный apt не будет работать. Если установлена ​​дата в прошлом, например, 1999 год, apt завершится ошибкой с бесполезным сообщением, например: рассматривать ключи как просроченные.
  • Еще одна проблема, с которой вы можете столкнуться при использовании тестовой или нестабильной версии, заключается в том, что если вы давно не запускали apt-get update и apt-get не устанавливали пакет, apt может сообщить, что не может быть аутентифицирован (почему он это делает?). Обновление apt-get исправит это.
  • Если apt выдает следующее предупреждение:
    • Это означает, что архив начал подписываться новым ключом, о котором ваша система не знает. В этом примере новый ключ — это выделенный ключ, который будет использоваться для подписи выпуска Debian 4.0. Поскольку архив по-прежнему был подписан другим ключом, о котором знает apt, это просто предупреждение, и как только системе будет передан новый ключ (путем обновления пакета debian-archive-keyring), предупреждение исчезнет.

    Настройка безопасного репозитория apt

    От man apt-secure

    • Создайте файл выпуска верхнего уровня.если его еще нет. Вы можете сделать это, запустив выпуск apt-ftparchive (предоставляется inftp apt-utils).
    • Подпишите его. Вы можете сделать это, запустив gpg -abs -o Release.gpg Release.
    • Опубликуйте отпечаток ключа, чтобы ваши пользователи знали, какой ключ им нужно импортировать для проверки подлинности файлов в архиве.

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

    Неудачные обновления и отсутствующие ключи

    Не удивляйтесь, если при попытке apt-get upgrade что-то пойдет не так. Кроме того, попытка разрешить отсутствующий ключ с помощью процедур на этой странице также не удастся. Если вы столкнулись с проблемами, отправьте отчет об ошибке.

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

    История

    Conectiva реализовала нечто подобное в своем форке APT. Разработчики Debian Колин Уолтерс и Исаак Джонс реализовали APT Secure для Debian в 2003 году. Около Рождества 2003 года Мэтт Циммерман (?) интегрировал этот патч в APT 0.6. В феврале 2005 г. Debian начал переход на apt-secure.

    Комментарии и вопросы

    Debian — это не Ubuntu, и sudo не будет установлен по умолчанию. Возможно, стоит изменить использование sudo и сделать так, чтобы в примерах явно использовалась учетная запись root -- SteveKemp

    Учитывая режимы сбоев, которые я видел в gpg --recv-keys, предлагать пользователю запускать его от имени пользователя root не кажется мне разумным. Но на самом деле я никогда не проверял его. Несмотря на то, что sudo не установлен по умолчанию (в sarge), я думаю, что большая часть аудитории этой страницы знакома с ним или может пропустить его. -- Джоуи Хесс

    Да, пакет debian-archive-keyring будет нашим ключевым путем обновления для всех систем Debian, поэтому его следует установить на всех из них, и я предполагаю, что он будет стандартным. -- Джоуи Хесс

    Можем ли мы как-то интегрировать эту идею в эту страницу? Думаю, важно, чтобы мы тоже двигались в этом направлении. -- сумасшедший

    Я попытался создать локальный репозиторий с помощью apt-move, который обслуживает тестируемые и стабильные машины. Я не мог использовать один и тот же репозиторий как для стабильной версии, так и для тестирования из-за несовместимости между apt v5 и v6. Вы можете выделить это, когда будете писать немного о создании репозитория. Я мог заставить v6 работать для тестирования, но не для sarge. --?МартинХоджес

    Что означает поломка md5sum? Поскольку это контрольная сумма, я подумал, что единственный способ ее взломать — это не вычислить правильную контрольную сумму. У меня есть ощущение, что имеется в виду какое-то другое значение. --?РоссБойлан

    **это не работает, так как люди смогли фактически создать поддельный сертификат, который мог подписывать что угодно и которому доверяли, они сделали это, обнаружив коллизию, они создали сертификат с той же суммой md5, что и сертификат, который они выдали , и где таким образом они могут дать себе право, отличное от того, что им было предоставлено. -- Науки

    ***apt поддерживает контрольные суммы sha256, начиная с версии 0.7.7, поэтому они будут использоваться в lenny и будущих выпусках. --ДжоуиХесс

    Идея состоит в том, что сгенерировать контрольную сумму из файла легко, но воссоздать файл из контрольной суммы (или заставить другой файл сгенерировать ту же контрольную сумму) очень сложно (в идеале это было бы невозможно). "md5sum ломается" означает, что этот "очень трудный" путь становится вполне возможным. Другими словами, становится (или, может быть, даже стало) возможным создание «мошеннического» пакета Debian, который по-прежнему генерирует ту же контрольную сумму, что и исходный настоящий пакет. --ДжонЗайцев

    Я бы сказал "теоретически возможно в некоторых случаях, которые могут включать или не включать файлы пакетов Debian", а не "вполне возможно" --JoeyHess

    Предусматривает ли Secure APT возможность взлома самой архивной машины? Что может помешать кому-то «вставить» мошенническую версию пакета Debian и просто перегенерировать файлы Packages и Release/Release.gpg? Я сильно подозреваю, что это рассматривалось, но в этом документе об этом не упоминается. Возможно, ссылка на соответствующую документацию, если таковая существует? --ДжонЗайцев

    Если у кого-то есть root-доступ к вашей машине, у него уже есть все, и ему не нужно ломать apt. Обнаружение того, что ваша машина была взломана, — это другая тема и нечто чрезвычайно сложное, хотя, безусловно, есть некоторые вещи, которые Debian мог бы сделать лучше. --Науки

    Да, если это произойдет, мы можем отозвать ключ архива и ввести новый ключ для новой установки ftp-master и отката архива до его последнего известного исправного состояния, что нам пришлось бы сделать после такого инцидента. . --ДжоуиХесс

    Не могли бы вы добавить объяснение того, почему apt-get, apt-key и т. д. могут привести к "ограничению ресурсов" GnuPG и как это исправить? Кажется, это приводит к предупреждениям «NO_PUBKEY», даже если соответствующие ключи находятся в файле trustdb trust.gpg. Например:

    Примечание: apt-key считается устаревшим, по крайней мере, для управления ключами. Обсуждение ошибки Debian 851774 .

    Я использую неподписанный репозиторий в Ubuntu 16.04 из мультимедиа Debian:

    Чтобы установить deb-multimedia-keyring , я запускаю:

    Выдает ошибку:

    8 ответов 8

    Вы можете установить параметры в файле sources.list (расположенном в /etc/apt/sources.list):

    Доверенный вариант отключает проверку GPG. Подробности смотрите в man 5 sources.list.

    Вы можете отредактировать файл в терминале с помощью vim (или как вам удобнее) или любого нетерминального редактора, такого как gedit.

    Он находится в /etc/apt/sources.list. Вы можете отредактировать его в терминале с помощью vim (или как вы предпочитаете) или любого нетерминального редактора, такого как gedit.

    jessie — это название выпуска дистрибутива, а main — это имя компонента. Вы можете найти информацию об именах компонентов здесь

    моя проблема была с репозиторием, добавленным с помощью add-apt-repository. Обязательно проверьте /etc/apt/sources.list.d/ на наличие любых файлов .list, которые могут содержать источник, которому вы пытаетесь доверять, в дополнение к источникам в /etc/apt/sources.list

    Вы можете обойти некоторые важные меры безопасности, используя следующую опцию:

    Из справочных страниц для apt-get:

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

    сказал мне, что "эту опцию нельзя интерпретировать вместе с другими опциями" при выполнении sudo apt-get update --allow-unauthenticated

    Интересно; возможно, на машине может быть что-то еще другое, я пробовал из-за ошибок, которые я наблюдал. В любом случае добавление поля [trusted=yes] в sources.list сработало. Спасибо за усердие @andrew.46 :)

    Другим общим решением может быть

    Примечание. Я не тестировал решение с этим репозиторием, но я сделал это с репозиторием Skype, и оно работало нормально.

    Еще одно решение, характерное для вашего случая, — установить ключи

    Как описано в полном обзоре здесь

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

    Этот ответ кажется неполным, когда я сталкиваюсь с Ubuntu 18.04. Там он пытается разозлить меня, говоря неприятные вещи, такие как . Релиз еще недействителен (недействителен еще 44 мин 35 с). Обновления для этого репозитория не будут применяться. Даже после исправления /var/lib/apt/lists/* вещей.

    Это просто проблема зеркальной репликации, которая не должна влиять на аутентификацию или подписание пакетов в репозиториях. Поскольку версия 1804 только выходит из бета-версии, многие зеркала пытаются наверстать упущенное, и служба зеркалирования может указать вам на сервер, который еще не полностью синхронизирован.

    Вы можете получить PUBLIC_KEY с сервера ключей и добавить его в apt-key. Предполагая, что сервер ключей pgpkeys.mit.edu , вам сначала нужно ввести:

    Замените ключ KEY_IN_ERROR на тот, который указан в сообщении об ошибке, например 5C808C2B65558117.

    Кроме того, если вы действительно заинтересованы в добавлении неподписанного репозитория, вы можете добавить флаг a в запись нужного репозитория в sources.list следующим образом:

    Это действительно полезно, если вы хотите точно настроить параметры безопасности для отдельных записей.

    N: см. справочную страницу apt-secure(8) для получения сведений о создании репозитория и настройке пользователя.

    следующая попытка удалить их с помощью

    например: sudo rm -i /etc/apt/sources.list.d/wireshark-dev-ubuntu-stable-focal.list

    Это было на ноутбуке Lenovo X140e с предустановленной Windows, который выдавался тем, кто прошел компьютерный курс.

    Я переустанавливал несколько раз, но без лучших результатов, возможно, потому, что применяется определение безумия. Затем я записал 16.04 LTS на флешку и установил ее. Пришлось повозиться с настройками биоса для установки. Интересно, что сетевые приложения были установлены, и Wi-Fi нашел соединения. Я получил такое же сообщение (репозиторий не подписан и т. д.) сначала от Software Updater, но потом он сказал мне, что есть новый выпуск, и спросил меня, хочу ли я его.

    Я попробовал, и теперь все работает в версии 18.04. Сделайте из этого что хочешь. Я хотел бы добавить, что ни один из других ответов на этой странице не работал. Вот почему я предлагаю это «решение».

    Несколько дней назад я попытался обновить Ubuntu 20.04 ПК, и я столкнулся с ошибкой «репозиторий не подписан», и я не мог пройти мимо этого. В других случаях вы можете столкнуться с ошибкой «В репозитории нет файла выпуска» при попытке добавить сторонний репозиторий. Если вы сталкивались с такими ошибками раньше и застряли, не теряйте сон. В этом руководстве мы сосредоточимся на том, как устранить такие ошибки в Ubuntu 20.04. Давайте без лишних слов приступим к делу.

    Исправить ошибку репозиторий не подписан в Ubuntu

    Прежде чем мы углубимся в основную причину этой ошибки. Кратко упомянем о PPA. Что это такое? PPA (Personal Package Archive) — это платформа, которая позволяет разработчикам предоставлять свои собственные репозитории и распространять свои приложения.

    Зачем использовать PPA вместо основных репозиториев Ubuntu?

    Это вопрос, который вы можете задать, учитывая, что каждая версия Ubuntu поставляется с собственным набором репозиториев, которые предоставляют широкий выбор пакетов программного обеспечения. На самом деле Ubuntu имеет более 47 000 пакетов программного обеспечения, представленных в 4 основных репозиториях. Каждая версия Ubuntu поставляется с 4 основными репозиториями:

    1) Основная — поддерживается Canonical и предоставляет бесплатное программное обеспечение с открытым исходным кодом.

    2) Вселенная — поддерживается сообществом и предоставляет бесплатное программное обеспечение с открытым исходным кодом.

    3) Restricted — содержит проприетарные драйверы для дополнительных устройств.

    4) Multiverse — содержит программное обеспечение, защищенное авторскими правами.

    Диспетчер пакетов APT в Ubuntu хранит список репозиториев в файле /etc/apt/sources.list.

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

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

    И здесь на помощь приходит PPA.

    Установка программных приложений с помощью PPA.

    К счастью, в Ubuntu есть Launchpad — платформа, позволяющая разработчикам создавать собственные репозитории. Как конечный пользователь, вы можете добавить репозиторий PPA в свой файл sources.list, и после обновления вашей системы Ubuntu ваша система узнает о доступности программного обеспечения и позволит вам установить его с помощью диспетчера пакетов APT.

    Например, чтобы установить FFmpeg4, вы должны добавить PPA-репозиторий панели запуска ffmpeg4 следующим образом:

    После этого вам будет предложено нажать кнопку «ВВОД», чтобы продолжить добавление PPA.

    После добавления PPA обновите систему и установите приложение, как показано на рисунке.

    Проблема со сторонними PPA

    Иногда некоторые сторонние PPA могут нанести ущерб вашей системе, и вы можете получить предупреждения на терминале, такие как указанные ниже, при обновлении Ubuntu.

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

    Решение проблемы «репозиторий не подписан»

    Чтобы устранить эту ошибку, вам необходимо удалить проблемный PPA из репозитория в вашей системе. Для этого запустите инструмент «Программное обеспечение и обновления», как показано на рисунке.

    В окне «Программное обеспечение и обновления» нажмите вкладку «Другое программное обеспечение». Затем снимите флажок и очистите проблемные PPA.

    Укажите свой пароль для проверки подлинности удаления рассматриваемых репозиториев.

    Если вы используете терминал, вы можете использовать синтаксис:

    После удаления проблемных PPA-репозиториев теперь вы сможете легко обновлять свою систему и управлять своими пакетами. Вот так, ребята. В этом руководстве мы показали вам, как устранить ошибку «репозиторий не подписан» в Ubuntu. Я надеюсь, что это руководство было полезным.

    О Джеймсе

    Привет!Это Джеймс, администратор Linux и технический энтузиаст. Мне нравится экспериментировать с различными дистрибутивами Linux и следить за новинками в мире Linux.

    Статьи по теме

    ⚡ Популярные путеводители

    • Как установить рабочий стол и VNC в Ubuntu 16.04 14711 13
    • Установите пакеты в Arch Linux из AUR 14644 10
    • 11 способов освободить место на диске на серверах cPanel 14422 5
    • Как настроить статический IP-адрес в Linux 13400 6
    • Установка пакетов из исходного кода в Arch Linux 12985 6
    • Как установить Zimbra Mail server 8.8.8 на Cent OS 7 12968 6
    • Как ограничить доступ по SSH только к определенным IP-адресам 12717 16
    • КАК УСТАНОВИТЬ РАСШИРЕНИЯ GNOME SHELL В LINUX 12200 3
    • Как установить Moodle в Ubuntu 18.04 11679 11
    • Установка cPanel на ваш сервер Centos 7 11483 5
    • Как установить GitLab на CentOS 7, RHEL и Scientific Linux 11219 5
    • Как установить графический интерфейс на сервере Ubuntu 18.04 10936 3
    • Как установить NextCloud на Debian 10 10702 7
    • Как изменить порт Nginx по умолчанию в Linux 9208 3
    • Как установить помощник Yay на ArchLinux 8608 7
    • Как проверить пропускную способность сети с помощью инструмента iperf3 8467 10
    • Как установить PostgreSQL 11 в Ubuntu 18.04 7867 1
    • Как установить pgAdmin4 в Ubuntu 18.04 7648 1
    • Как установить Centreon на CentOS 7 7609 5
    • Как создать пользователя в Ubuntu 20.04 7276 4

    Клаудкон, ООО

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

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

    По возможности в этом документе используется терминология, подобная RFC, как определено в RFC 2119. Обратите внимание, что эти инструкции в первую очередь предназначены для Debian 9 "stretch" или более поздней версии.

    Обратите внимание, что задокументированные здесь процедуры направлены на предотвращение отправки репозиторием пакетов, которые администратор не ожидает от этого репозитория. Например, репозиторий, поставляющий эмулятор видеоигры и его моды, не должен переопределять libc6.

    Однако установка любого отдельного вредоносного пакета из вредоносного репозитория в настоящее время может отменить эту защиту, например, запустив команду MaintenanceScripts для переопределения настроенных параметров или авторизовав новые ключи OpenPGP. Для целей этой страницы атаки со стороны пакета, принадлежащего данному репозиторию, не рассматриваются. Чтобы ограничить возможности установленного пакета, см. более крупную проблему UntrustedDebs и, в частности, Teams/Dpkg/Spec/DeclarativePackaging для потенциального решения.

    1. Инструкции по подключению к стороннему репозиторию
      1. Распределение ключей OpenPGP
      2. Запись Sources.list
      3. Стандартное закрепление
      4. Смена ключей и обновления
      5. Полный пример
      6. Устранение неполадок
      7. Обработка ключей OpenPGP
      8. Кредиты
      9. Ссылки

      Распределение ключей OpenPGP

      Репозитории ДОЛЖНЫ быть подписаны ключом OpenPGP. Двоичный экспорт (gpg --export) ключа ДОЛЖЕН быть доступен в корне репозитория под именем файла deriv-archive-keyring.gpg, где deriv — это короткое имя репозитория. Файл НЕ ДОЛЖЕН иметь кодировку ascii (gpg --export --armor), хотя МОЖЕТ быть доступна отдельная версия в формате deriv-archive-keyring.asc. р>

      Например, пользователям МОЖЕТ быть предложено выполнить эту команду для загрузки ключа:

      Скорее всего, распространяемый ключ имеет кодировку ascii. В этом случае вам нужно будет удалить его:

      Запись Sources.list

      Запись sources.list ДОЛЖНА иметь установленную опцию signed-by. Запись подписано ДОЛЖНА указывать на файл, а не на отпечаток пальца.

      Запись suite ДОЛЖНА соответствовать целевому выпуску Debian, если двоичные файлы созданы для определенного набора. В других случаях suite ДОЛЖЕН быть строкой «stable» или МОЖЕТ быть строкой для конкретного репозитория, кратко описывающей набор. Если пакет не соответствует целевому выпуску Debian, соглашение об именах комплекта ДОЛЖНО быть четко задокументировано.

      Если репозиторий не имеет смысла разделять на несколько компонентов, то именем component СЛЕДУЕТ быть main. Если есть причина для разделения репозитория на несколько компонентов, причина разделения должна быть четко задокументирована (например, задокументированное разделение Debian), а имена компонентов должны кратко отражать это разделение.

      Записи ДОЛЖНЫ быть добавлены в каталог /etc/apt/sources.list.d с использованием сокращенного имени репозитория (например, deriv.list). Вместо этого МОЖЕТ использоваться формат файла «Deb822» для повышения ясности сложных записей (например, deriv.sources). (См. sources.list(5))

      Например, это может быть содержимое файла /etc/apt/sources.list.d/deriv.list:

      Выше приведена строка sources.list для вымышленной производной Deriv от Debian. комплект является стабильным, а component является стандартным компонентом main.

      Это эквивалентно следующему формату файла Deb822 в разделе deriv.sources:

      Причина, по которой мы указываем файл вместо отпечатка пальца, заключается в том, что последний вынуждает пользователя добавлять ключ к глобальному якорю доверия SecureApt в /etc/apt/trusted.gpg.d, что заставит систему принимать подписи от стороннего держателя ключей во всех других репозиториях, настроенных в системе, которые не имеют параметр signed-by (включая официальный репозиторий Debian).

      Стандартное закрепление

      Когда репозиторий добавляется в sources.list.d, СЛЕДУЕТ создать соответствующий файл настроек, чтобы ограничить возможные эффекты репозитория. Если используется такой файл настроек, он ДОЛЖЕН закрепляться с контролируемой пользователем меткой (например, имя хоста URI или какая-либо будущая локальная метка, см. 858406) и НЕ ДОЛЖЕН использовать поле, предоставленное исходным файлом Release. Поле Pin-Priority МОЖЕТ быть установлено таким образом, чтобы пакеты обновлялись по умолчанию (Pin-Priority: 100) или нет (Pin-Priority: 1), но НЕ ДОЛЖНО быть установлено более высокое значение, которое может привести к перезаписи пакетов, поставляемых с дистрибутивом Debian по умолчанию.

      Если файл настроек не предоставлен или используется другой PIN-Priority, пользователь ДОЛЖЕН быть предупрежден о последствиях для безопасности.

      В качестве альтернативы эта конфигурация позволит пользователю устанавливать пакеты из репозитория deriv, но запретит автоматические обновления:

      Упомянутая выше конфигурация origin не подвергалась аудиту. МОЖЕТ быть возможным, что репозиторий может переопределить это значение. Необходимы дальнейшие тесты, чтобы подтвердить, что вышеуказанная конфигурация устойчива к атакам со стороны владельца репозитория.

      Обратите внимание, что если локальная система извлекает несколько репозиториев с одного и того же хоста (например, разные пути, разные наборы или разные компоненты), то предлагаемый Pin: origin не может их различить. Чтобы исправить это, потребуются улучшения в apt, см. 858406.

      Смена ключей и обновления

      Обновления ключей СЛЕДУЕТ распространять с помощью пакета Debian под названием deriv-archive-keyring. Этот пакет ДОЛЖЕН распространять ключ в двоичной форме в вышеупомянутом месте (/usr/share/keyrings/deriv-archive-keyring.gpg) и МОЖЕТ также включать в себя /etc/apt/sources. .list.d/deriv.sources или /etc/apt/sources.list.d/deriv.list и файлы /etc/apt/preferences.d/deriv .pref файл.

      Если такой механизм используется для распространения обновлений ключей, файл настроек ДОЛЖЕН разрешать автоматические обновления (PIN-Priority: 100) или включать определенную запись для пакета набора ключей, которая добавляет исключение для этого пакет:

      Полный пример

      Этот пример может служить шаблоном для инструкций в корне архива, которые помогут пользователям настроить репозиторий APT.

      Это репозиторий Debian. Чтобы установить пакеты из этого репозитория, вы должны сначала загрузить якорь доверия в свою систему с помощью этой команды:

      Затем вы можете добавить репозиторий в свой sources.list, создав текстовый файл в /etc/apt/sources.list.d/deriv.sources, содержащий следующее:

      Наконец, вы также должны добавить следующий файл настроек, чтобы ограничить то, что может устанавливать этот репозиторий, создав следующий файл в /etc/apt/preferences.d/deriv.pref:

      После этого вы можете запустить apt-get update, чтобы изменения вступили в силу, и использовать apt-get install deriv-archive-keyring, чтобы убедиться, что обновления на связку ключей получены своевременно.

      Устранение неполадок

      Это сообщение об ошибке обычно появляется, когда ключ GPG, который вы используете, имеет формат ascii, а не двоичную форму.

      Обработка ключей OpenPGP

      APT несколько своеобразен в том, как он обрабатывает ключи OpenPGP. Как указано выше, вы НЕ ДОЛЖНЫ использовать ключи с кодировкой ascii. Если у вас есть такой ключ, вы должны преобразовать его в двоичную форму примерно так:

      Тогда $KEY.gpg может распространяться везде корректно.

      Кредиты

      Этот документ был написан TheAnarcat при обширной помощи и обзоре Даниэля КанГиллмора.

      7.5. Подписание пакетов в Debian

      Этот раздел также можно было бы назвать "как безопасно обновить/обновить систему Debian GNU/Linux", и он заслуживает отдельного раздела в основном потому, что является важной частью инфраструктуры безопасности. Подписание пакетов — важный вопрос, поскольку он позволяет избежать подделки пакетов, распространяемых на зеркалах, и загрузок с помощью атак «человек посередине». Автоматическое обновление программного обеспечения является важной функцией, но также важно устранять угрозы безопасности, которые могут способствовать распространению троянов и компрометации систем во время обновлений [47]

      FIXME: вероятно, обработка уязвимостей Internet Explorer. цепочки сертификатов влияют на обновления безопасности в Microsoft Windows.

      Debian не предоставляет подписанные пакеты, но предоставляет механизм, доступный, начиная с Debian 4.0 (кодовое имя etch), для проверки целостности загруженного пакета [48] . Дополнительные сведения см. в Разделе 7.5.2, «Безопасность apt».

      7.5.1. Текущая схема проверки подписи пакетов

      Файл Release включает сумму MD5 для Packages.gz (который содержит суммы MD5 для пакетов) и будет подписан. Подпись является одним из надежных источников.

      Подписанный файл Release проверяется (подпись в порядке) и извлекает из него сумму MD5 для файла Packages.gz, генерируется контрольная сумма Packages.gz и (если все в порядке) сумма MD5 загруженного пакета извлекается из это.

      Если сумма MD5 из загруженного пакета совпадает с суммой в файле Packages.gz, пакет будет установлен, в противном случае администратор получит предупреждение и пакет останется в кеше (чтобы администратор мог решить устанавливать или нет). Если пакета нет в Packages.gz и администратор настроил систему на установку только проверенных пакетов, он также не будет установлен.

      Следуя цепочке сумм MD5, apt может проверить, что пакет происходит из определенного выпуска. Это менее гибко, чем подписание каждого пакета по отдельности, но его также можно комбинировать с этой схемой (см. ниже).

      7.5.2. Защитить объект

      Выпуск apt 0.6, доступный начиная с Debian 4.0 etch и более поздних выпусков, включает apt-secure (также известный как secure apt), который это инструмент, который позволит системному администратору проверить целостность пакетов, загруженных по вышеуказанной схеме. Этот выпуск включает инструмент apt-key для добавления новых ключей в связку ключей apt, которая по умолчанию включает только текущий ключ подписи архива Debian.

      Secure apt работает путем проверки дистрибутива через файл Release, как описано в Разделе 7.5.3, «Проверка выпуска для каждого дистрибутива». Как правило, этот процесс будет прозрачен для администратора, хотя вам нужно будет вмешиваться каждый год [49], чтобы добавить новый ключ архива при его ротации. , «Безопасное добавление ключа».

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

      7.5.3. Проверка выпуска дистрибутива

      7.5.3.1. Основные понятия

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

      Криптография с открытым ключом основана на паре ключей: открытом ключе и закрытом ключе. Открытый ключ выдается миру; закрытый ключ должен храниться в секрете. Любой, у кого есть открытый ключ, может зашифровать сообщение, чтобы его мог прочитать только тот, у кого есть закрытый ключ. Также можно использовать закрытый ключ для подписи файла, а не для его шифрования. Если для подписи файла используется закрытый ключ, то любой, у кого есть открытый ключ, может проверить, был ли файл подписан этим ключом. Никто, у кого нет закрытого ключа, не может подделать такую ​​подпись.

      Эти ключи представляют собой довольно длинные числа (от 1024 до 2048 цифр или длиннее), и для облегчения работы с ними у них есть идентификатор ключа, который представляет собой более короткий 8- или 16-значный номер, который можно использовать для ссылки на них. .

      apt-key — это программа, которая используется для управления набором ключей gpg для безопасного доступа к apt. Брелок хранится в файле /etc/apt/trusted.gpg (не путать с родственным, но не очень интересным /etc/apt/trustdb.gpg). apt-key можно использовать для отображения ключей в связке ключей, а также для добавления или удаления ключа.

      7.5.3.2. Освобождение контрольных сумм

      Архив Debian содержит файл Release, который обновляется каждый раз при изменении любого из пакетов в архиве.Среди прочего, файл Release содержит некоторые суммы MD5 других файлов в архиве. Фрагмент примера файла Release:

      Файлы Release также включают контрольные суммы SHA-1, которые будут полезны, когда суммы MD5 будут полностью нарушены, однако apt пока их не использует.

      Теперь, если мы заглянем внутрь файла Packages, мы обнаружим больше сумм MD5, по одной для каждого пакета, указанного в нем. Например:

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

      В этом нет ничего нового для secure apt, но они обеспечивают основу. Обратите внимание, что пока есть один файл, который apt не может проверить: файл Release. Безопасный apt заключается в том, чтобы заставить apt проверять файл Release, прежде чем делать с ним что-либо еще, и затыкать эту дыру, чтобы существовала цепочка проверки от пакета, который вы собираетесь установить, до провайдера. пакет.

      7.5.3.3. Проверка файла релиза

      Чтобы проверить файл выпуска, для файла выпуска добавляется подпись gpg. Это помещается в файл с именем Release.gpg, который поставляется вместе с файлом Release. Выглядит это примерно так [50] , хотя на самом деле только gpg нормально смотрит на его содержимое:

      7.5.3.4. Проверка Release.gpg с помощью apt

      Secure apt всегда загружает файлы Release.gpg при загрузке файлов Release, и если он не может загрузить Release.gpg или если подпись неверна, он будет жаловаться и отмечать, что файлы Packages, которые файл Release указывает на, и все перечисленные в нем пакеты получены из ненадежного источника. Вот как это выглядит во время обновления apt-get:

      Обратите внимание, что вторая половина длинного числа — это идентификатор ключа, о котором apt не знает, в данном случае это 2D230C5F.

      Если вы скажете здесь Y, вы не сможете узнать, является ли полученный вами файл пакетом, который вы должны установить, или это что-то совершенно другое, что кто-то может перехватить связь с сервером [51] подготовил для вас неприятный сюрприз.

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

      7.5.3.5. Как определить, чему доверять

      Таким образом, безопасность всей системы зависит от наличия файла Release.gpg, который подписывает файл Release, и от правильной проверки этой подписи с помощью gpg. Для проверки подписи необходимо знать открытый ключ лица, подписавшего файл. Эти ключи хранятся в собственной связке ключей apt ( /etc/apt/trusted.gpg ), и управление ключами — это место, где вступает в действие безопасный apt.

      Здесь 4F368D5D — это идентификатор ключа, и обратите внимание, что этот ключ действителен только в течение одного года. Debian меняет эти ключи в качестве последней линии защиты от какого-либо нарушения безопасности, ломающего ключ.

      Это приведет к тому, что apt будет доверять официальному архиву Debian, но если вы добавите какой-либо другой репозиторий apt в /etc/apt/sources.list , вам также придется указать ключ apt, если вы хотите, чтобы ему доверяли. Получив ключ и проверив его, достаточно просто запустить apt-key add file, чтобы добавить его. Получение ключа и его проверка — более сложная часть.

      7.5.3.6. Поиск ключа для репозитория

      Пакет debian-archive-keyring используется для распространения ключей в apt . Обновления этого пакета могут добавлять (или удалять) ключи gpg для основного архива Debian.

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

      Gpg сама распределяет ключи стандартным способом, используя сервер ключей, с которого gpg может загрузить ключ и добавить его в свою связку ключей. Например:

      Предупреждение "gpg: окончательно доверенные ключи не найдены" означает, что gpg не был настроен для окончательного доверия конкретному ключу. Настройки доверия являются частью Web-of-Trust OpenPGP, которые здесь не применяются. Так что с этим предупреждением проблем нет. В типичных настройках в конечном итоге доверяется собственному ключу пользователя.

      7.5.3.7. Безопасное добавление ключа

      Хорошо быть параноиком в вопросах безопасности, но проверять что-либо отсюда сложнее. В gpg есть концепция цепочки доверия, которая может начинаться с того, в ком вы уверены, кто подписывает чей-то ключ, кто подписывает какой-то другой ключ и т. д., пока не доберетесь до ключа архива. Если вы достаточно параноик, вам нужно убедиться, что ваш архивный ключ подписан ключом, которому вы можете доверять, с цепочкой доверия, которая восходит к тому, кого вы знаете лично. Если вы хотите сделать это, посетите конференцию Debian или местную LUG для подписания ключей [53] .

      Если вы не можете позволить себе такой уровень паранойи, делайте все, что считаете нужным, при добавлении нового подходящего источника и нового ключа. Возможно, вы захотите написать человеку, предоставившем ключ, и проверить его, или, может быть, вы готовы рискнуть, загрузив его и предполагая, что вы получили настоящую вещь. Важно то, что, сводя проблему к тому, каким архивным ключам доверять, secure apt позволяет вам быть настолько осторожным и безопасным, насколько вам удобно.

      7.5.3.8. Проверка целостности ключа

      Обратите внимание, что ключ подписан с помощью предыдущего ключа архива, поэтому теоретически вы можете просто основываться на своем предыдущем доверии.

      7.5.3.9. Ежегодная ротация ключей архива Debian

      Как упоминалось выше, ключ подписи архива Debian меняется каждый год, в январе. Так как secure apt молодой, у нас нет большого опыта смены ключа, и до сих пор есть шероховатости.

      В январе 2006 года был создан новый ключ для 2006 года, и файл Релиза стал подписываться им, но во избежание поломки систем, в которых был старый ключ 2005 года, файл Релиза также был подписан им. Намерение состояло в том, что apt будет принимать ту или иную подпись в зависимости от имеющегося у него ключа, но apt оказался ошибочным и отказался доверять файлу, если у него нет обоих ключей и он не может проверить обе подписи. Это было исправлено в версии 0.6.43.1. Также возникла путаница в отношении того, как ключ распространялся среди пользователей, у которых уже были системы, использующие безопасный apt; изначально он был загружен на веб-сайт без объявления и без реального способа проверить его, и пользователи были вынуждены загружать его вручную.

      В январе 2006 года был создан новый ключ для 2006 года, и файл Релиза стал подписываться им, но во избежание поломки систем, в которых был старый ключ 2005 года, файл Релиза также был подписан им. Во избежание путаницы в отношении наилучшего механизма распространения для пользователей, у которых уже есть системы, использующие безопасный apt, был представлен пакет debian-archive-keyring, который управляет обновлениями набора ключей apt.

      7.5.3.10. Известные проблемы с проверкой выпуска

      Одна не столь очевидная проблема заключается в том, что если ваши часы очень далеко отстают, безопасный apt не будет работать. Если для него задана дата в прошлом, например 1999 год, apt завершится ошибкой с бесполезным сообщением, например следующим:

      Еще одна проблема, с которой вы можете столкнуться при использовании тестовой или нестабильной версии, заключается в том, что если вы давно не запускали apt-get update и apt-get не устанавливали пакет, apt может сообщить, что не может быть аутентифицирован (почему он это делает?). Обновление apt-get исправит это.

      7.5.3.11. Проверка выпуска вручную для каждого дистрибутива

      Если вы хотите добавить дополнительные проверки безопасности и не хотите или не можете запускать последнюю версию apt [54], вы можете использовать приведенный ниже сценарий, предоставленный Энтони Таунсом. Этот сценарий может автоматически выполнять некоторые новые проверки безопасности, чтобы позволить пользователю быть уверенным, что программное обеспечение, которое он/она загружает, соответствует программному обеспечению, распространяемому Debian. Это останавливает разработчиков Debian от взлома чьей-либо системы без ответственности, обеспечиваемой загрузкой в ​​основной архив, или зеркал, отражающих что-то почти, но не совсем как Debian, или зеркал, предоставляющих устаревшие копии нестабильной версии с известными проблемами безопасности.

      удалите все строки /etc/apt/sources.list, которые не используют обычную структуру "dists", или измените скрипт, чтобы он работал с ними.

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

      Возможно, вам потребуется применить следующий патч для sid, так как md5sum добавляет "-" после суммы, когда ввод является стандартным вводом:

      7.5.4. Проверка выпуска исходных кодов, отличных от Debian

      7.5.5. Альтернативная схема подписи для каждого пакета

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

      Эту схему подписи пакетов можно реализовать с помощью debsig-verify и debsigs. Эти два пакета могут подписывать и проверять встроенные подписи в самом .deb. В Debian уже есть возможность сделать это сейчас, но нет плана функций для реализации политики или других инструментов, поскольку предпочтительнее схема подписи архива. Эти инструменты доступны для пользователей и администраторов архивов, которые предпочитают использовать эту схему.

      ПРИМЕЧАНИЕ 2. В настоящее время подписи разработчиков удаляются, когда они выходят из архива пакета, поскольку в настоящее время предпочтительным методом является проверка выпуска, как описано ранее.

      [48] Более старые выпуски, такие как Debian 3.1 sarge, могут использовать эту функцию с помощью портированных версий этого инструмента управления пакетами

      [51] Или отравил ваш DNS, или спуфинг сервера, или заменил файл на зеркале, которое вы используете, и т. д.

      [53] Не все ключи репозитория apt вообще подписаны другим ключом. Возможно, у человека, настраивающего репозиторий, нет другого ключа, или, может быть, ему неудобно подписывать такой ролевой ключ своим основным ключом. Для получения информации о настройке ключа для репозитория см. Раздел 7.5.4, «Проверка выпуска исходных кодов, отличных от Debian».

      [54] Либо потому, что вы используете стабильную, sarge, версию или более раннюю версию, либо потому, что вы не хотите использовать последнюю подходящую версию, хотя мы были бы очень признательны за ее тестирование. .

      Читайте также: