Перейти к содержанию книги Kali Linux Revealed
8.3 Дополнительная настройка и использование APT
Теперь пришло время погрузиться в более сложные темы. Во-первых, мы рассмотрим расширенную конфигурацию APT, которая позволит вам установить более постоянные параметры, которые будут применяться к инструментам APT. Затем мы покажем вам, как управлять приоритетами пакетов, что откроет нам дверь для дополнительной настройки, пользовательских обновлений и модернизаций. Мы также покажем, как обращаться с несколькими дистрибутивами, чтобы вы могли начать экспериментировать с пакетами, поступающими из других дистрибутивов. Затем мы рассмотрим, как отслеживать автоматически установленные пакеты, что позволит вам управлять пакетами, которые устанавливаются через зависимости. Мы также объясним, каким образом поддержка multiarch дает нам возможность запуска пакетов, созданных для различных аппаратных архитектур. И последнее, но не менее важное: мы обсудим криптографические протоколы и утилиты, которые позволят вам проверить подлинность каждого пакета.
8.3.1 Настройка APT
Перед тем как мы углубимся в изучение того, как настроить APT, давайте потратим немного времени и обсудим механизм конфигурации системы Debian. В течение длительного времени настройка проводилась специально заточенными под это файлами. Однако в современных Linux системах, вроде Debian и Kali, директории конфигурации с суффиксом .d используются все чаще и чаще. Каждая директория представляет собой файл конфигурации, который в свою очередь разбит на множество файлов. В этом смысле все файлы в /etc/apt/apt.conf.d/ используются для настройки APT. APT обрабатывает файлы в алфавитном порядке, таким образом, что более поздние файлы могут изменять элементы конфигурации, определенные в более ранних файлах.
Эта структура предоставляет определенную гибкость администратору и тем, кто занимается поддержкой пакетов, позволяя им производить изменения в настройках программного обеспечения с помощью добавления файлов без необходимости изменения уже существующего файла. Это особенно полезно для тех, кто занимается поддержкой пакетов, потому что они могут использовать этот подход для адаптации конфигурации другого программного обеспечения, чтобы гарантировать, что оно без проблем сможет сосуществовать с другим программным обеспечением, не нарушая политики Debian, которая в свою очередь строго запрещает изменение конфигурации файлов других пакетов. Благодаря механизму .d конфигурации вам не нужно вручную следовать множеству инструкций по настройке пакетов, которые обычно находятся в файле пакета /usr/share/doc/package /README.Debian , т.к. установщик может обращаться к файлу конфигурации.
Будьте осторожны с файлами конфигурации, которые были созданы в .d директории
Хотя APT имеет встроенную поддержку своего каталога /etc/apt/apt.conf.d, это не всегда так. Для некоторых приложений (например, для exim), директория .d является особым дополнением Debian, которое используется в качестве входа для динамического создания канонического файла конфигурации, используемого приложением. В таких случаях пакеты предоставляют команду «update-*» (например: update-exim4.conf), которая последовательно соединит файлы из .d директории и перезапишет основной файл конфигурации.
В подобных ситуациях вы ни в коем случае не должны вручную редактировать основной файл конфигурации, т.к. ваши изменения будут потеряны после следующего запуска команды update-*, а также вы никогда не должны забывать запускать предыдущую команду после редактирования файла из .d директории (или ваши изменения не будут использоваться).
Теперь вооружившись пониманием механизма .d конфигурации, давайте поговорим о том, как вы можете использовать это для настройки APT. Как мы уже обсудили, вы можете изменять поведение APT с помощью dpkg аргументов командной строки, как в этом примере, который выполняет принудительную перезапись установки zsh:
# apt -o Dpkg::Options::="--force-overwrite" install zsh
Очевидно, что это довольно громоздко, особенно если вы используете опции часто, но вы также можете использовать структуру конфигурации .d директории для настройки определенных аспектов APT, путем добавления директив в файлы в директории /etc/apt/apt.conf.d/ . Например, эта (и многие другие) директивы могут с легкостью быть добавлены к файлу в /etc/apt/apt.conf.d/ . Имя этого файла несколько произвольно, но общим условным обозначением является использование либо local , либо 991ocal :
$ cat /etc/apt/apt.conf.d/99local
Dpkg::Options { "--force-overwrite"; } Существует довольно много других полезных опций конфигурации и мы, к сожалению, не сможем затронуть их все. Тем не менее, одну из них мы обсудим. Ту, которая относится к связанности узлов в сети. Например, если вы имеете доступ к интернету только через прокси, добавьте строку вроде Acquire::http::proxy »http-Hyourproxy:3128″ . Для прокси FTP используйте Acquire::ftp::proxy »ftp.Hyourproxy» .
Чтобы узнать больше об опциях настройки, мы рекомендуем вам прочитать страницу руководства к apt.conf(5) с помощью команды man apt. conf (для получения больших деталей о странице руководства, смотрите раздел 6.1.1 «Страницы руководства»)
8.3.2 Управление приоритетами пакетов
Одним из самых важных аспектов в конфигурации APT является управление приоритетами, связанными с каждым источником пакетов. Например, вы можете захотеть расширить свою Kali Rolling систему на один или два более новых пакета Debian Unstable или Debian Experimental. Также возможно назначить приоритет для каждого доступного пакета (один и тот же пакет может иметь несколько приоритетов в зависимости от его версии или от дистрибутива, предоставившего его). Эти приоритеты будут влиять на поведение APT: для каждого пакета он всегда будет выбирать версию с наивысшим приоритетом (за исключением случаев, когда эта версия старше установленной, а ее приоритет меньше 1000).
APT определяет несколько приоритетов по умолчанию. Каждый установленная версия пакета обладает приоритетом равным 100. Неустановленная версия имеет приоритет 500 по умолчанию, но она может измениться на 990, если является частью целевого выпуска (определенной с помощью опции командной строки –t или APT::Default-Releas e директивой конфигурации).
Вы можете изменять приоритеты путем добавления записей в файл /etc/apt/preferences с именами поврежденных пакетов, их версией, их производителем и их новым приоритетом.
APT никогда не установит более старую версию пакета (имеется ввиду пакет, чья версия является более старой по отношению к существующей версии установленного пакета) за исключением тех случаев, когда её приоритет выше 1000. APT всегда будет устанавливать пакет с самым высоким приоритетом, который выше указанной цифры. Если у двух пакетов одинаковый приоритет, APT установит самый новый (чей номер версии самый высокий). Если два пакета имеют одинаковую версию и приоритет, но отличаются своим содержанием, APT установит ту версию, которая еще не была установлена (это правило было создано для того, чтобы затрагивать случаи, когда пакет обновился, но не обновился номер его версии).
Более конкретно, пакет, приоритет которого меньше 0, никогда не будет установлен. Пакет с приоритетом в диапазоне от 0 до 100 будет установлен только в том случае, если другая версия пакета еще не была установлена. При приоритете от 100 до 500 пакет будет установлен только в том случае, если в другом дистрибутиве нет другой более новой версии, установленной или доступной. Пакет приоритетов между 501 и 990 будет установлен только в том случае, если новая версия не установлена или недоступна в целевом дистрибутиве. Пакет с приоритетом от 990 до 1000 будет установлен в случае, если существующая версия является более старой. Приоритет, превышающий 1000, всегда приведет к установке пакета, даже если он заставит APT перейти на более раннюю версию.
Когда APT проверяет /etc/apt/preferences , он сначала учитывает наиболее конкретные записи (часто указывающие соответствующий пакет), затем более общие (в том числе, например, все пакеты дистрибутива). Если существует несколько общих записей, используется первое соответствие. Доступный критерий выбора включает в себя имя пакета и источник, который его предоставил. Каждый источник пакета идентифицирован информацией содержащейся в файле Release, который APT загружает вместе с файлами Packages. Эти файлы обычно указывают источник, «Kali» для пакетов с официальных зеркал Kali и «Debian »для пакетов с официальных зеркал Debian, но источником также может быть название организации, имя человека или же название каких-либо других репозиториев. Файл Release также предоставляет название дистрибутива вместе с его версией. Теперь, давайте познакомимся с его синтаксисом на примере реального случая, для более полного понимания механизма.
Приоритет Kali-Bleeding-Edge и Debian Experimental
Если вы указали kali-bleeding-edge или Debian experimental в вашем файле sources.list , то соответствующий пакет практически никогда не будет установлен, потому что их APT приоритет по умолчанию 1. Это, безусловно, особенный случай, который был задан специально для того, чтобы предотвратить пользователей от ошибочной установки bleeding edge пакетов. Пакеты могут быть установлены только путем ввода apt install package/kali-bleeding-edge , предполагая, конечно, что вы полностью осознаете риски и потенциальные проблемы «жизни на краю» (life on the edge). По-прежнему возможно (хотя и не рекомендуется) обрабатывать пакеты kali-bleeding-edge/experimental , аналогично пакетам из других дистрибутивов, предоставляя им приоритет 500. Это делается с помощью конкретной записи в /etc/apt/preferences :
Package: * Pin: release a=kali-bleeding-edge Pin-Priority: 500
Давайте предположим, что вы всего лишь хотите использовать пакеты Kali и желаете, чтобы пакеты Debian устанавливались только при явном запросе. Вы можете написать следующую запись в файле /etc/apt/ preferences (или в любом другом файле в /etc/apt/preferences.d/ ):
Package: * Pin: release o=Kali Pin-Priority: 900 Package: * Pin: release o=Debian Pin-Priority: -10
В последних двух примерах вы встречали a=kali-bleeding-edge , что обозначает имя выбранного дистрибутива, а также вы могли видеть o=Kali и o=Debian , что в свою очередь ограничивает сферу деятельности пакетов, чьим источником являются Kali и Debian, соответственно.
Теперь давайте предположим, что у вас есть сервер с несколькими локальными программами, которые находятся в зависимости от версии Perl 5.22 и вы, соответственно, хотите убедиться в том, что обновление не установит другую версию. Вы можете использовать следующую запись.
Package: perl Pin: version 5.22* Pin-Priority: 1001
Справочная документация для этого файла конфигурации доступна на странице руководства apt_pref erences (5), которую вы можете вывести на экран с помощью команды man apt_preferences.
Добавление комментариев в /etc/apt/preferences
В /etc/apt/preferences не существует официального синтаксиса для комментариев, но некоторые текстовые описания могут быть предоставлены путем добавления одного или нескольких полей Explanation в каждую запись:
Explanation: The package xserver-xorg-video-intel provided Explanation: in experimental can be used safely Package: xserver-xorg-video-intel Pin: release a=experimental Pin-Priority: 500
8.3.3 Работа с несколькими дистрибутивами
Учитывая, что apt является таким замечательным инструментом, вы, скорее всего, захотите погрузиться и начать экспериментировать с пакетами, поступающими из других дистрибутивов. Например, после установки системы Kali Rolling, вы можете попробовать пакет программного обеспечения, доступный в Kali Dev, Debian Unstable или Debian Experimental, не слишком сильно отдаляясь от исходного состояния системы.
Даже если вы время от времени сталкиваетесь с проблемами, когда вы смешиваете пакеты из различных дистрибутивов, apt отлично справляется с такого рода сосуществованием и очень эффективно ограничивает риски (при условии, что зависимости пакетов точны). Сначала перечислите все дистрибутивы, используемые в /etc/apt/sources.list , и затем определите дистрибутив, на который вы ссылаетесь с помощью параметра APT::Default-Release (смотри раздел 8.2.3, «Обновление Kali Linux»)
Давайте предположим, что Kali Rolling является вашим ссылочным дистрибутивом, но Kali Dev и Debian Unstable также указаны в вашем файле sources.list. В этом случае вы можете использовать apt install package/unstable для установки пакета из Debian Unstable. Если установка была прервана ввиду некоторых неудовлетворяемых зависимостей, позвольте ей разрешить эти зависимости в Unstable путем добавления параметра -t unstable.
В данной ситуации, обновления (upgrade и full-upgrade) выполнены в пределах Kali Rolling за исключением пакетов, которые уже были обновлены в другом дистрибутиве: они будут продолжать следовать обновлениям, доступным в других дистрибутивах. Мы объясним это поведение с помощью приоритетов по умолчанию выставленных APT ниже. Не стесняйтесь использовать apt-cache policy (см. вставку «Использование apt-cache policy») для проверки заданных приоритетов.
Все опирается на то, что рассматривает лишь пакеты, которые выше или равны версии установленного пакета (при условии, что /etc/apt/preferences не используется для форсирования приоритетов выше 1000 для некоторых пакетов).
Использование apt-cache policy
Для получения лучшего понимания механизма приоритетности, не стесняйтесь выполнять apt-cache policy для того, чтобы отобразить приоритетность по умолчанию связанную с каждым источником пакета. Вы также можете использовать apt-cache policy package для отображения приоритетов всех доступных версий заданного пакета.
Давайте предположим, что вы установили версию 1 первого пакета из Kali Rolling и что версия 2 и 3 доступны соответственно в Kali Dev и Debian Unstable. Установленная версия обладает приоритетом 100, а версия доступная в Kali Rolling (абсолютно такая же) обладает приоритетом 990 (ввиду того, что она является частью целевого выпуска). Пакеты в Kali Dev и Debian Unstable обладают приоритетом 500 (приоритет по умолчанию не установленной версии). Таким образом, победителем в этой ситуации выйдет версия 1 с приоритетом в 990. Пакет остается в Kali Rolling.
Давайте приведем другой пример с пакетов версии 2, который был установлен из Kali Dev. Версия 1 является доступной в Kali Rolling и версия 3 доступна в Debian Unstable. Версия 1 (с приоритетом 990 – таким образом ниже чем 1000) отбрасывается, потому что она обладает более низким приоритетом, чем установленная версия. Остаются две версии 2 и 3, обе с приоритетом 500. В таких случаях APT выбирает самую новую версию, ту которая доступна в Debian Unstable. Если вы не хотите чтобы пакет установленный с Kali Dev переместился в Debian Unstable, вам нужно назначить приоритет меньше 500 (например, 490) для пакетов, поступающих с Debian Unstable. Вы можете изменить /etc/apt/preferences для этого эффекта:
Package: * Pin: release a=unstable Pin-Priority: 490
8.3.4 Автоматическое отслеживание установленных пакетов
Одной из существенных функций apt является отслеживание пакетов, установленных только через зависимость. Такие пакеты называются автоматическими (automatic) и часто включают в себя библиотеки.
С этой информацией, когда пакеты удалены, менеджеры пакетов могут вычислить список автоматических пакетов, которые больше не нужны (потому что не существует вручную установленных пакетов, которые бы полагались на них). Команда apt autoremove избавится от этих пакетов. Aptitude не имеет подобной команды, т.к. она удаляет эти пакеты автоматически, как только они будут идентифицированы. Во всех случаях инструменты отображают точное сообщение с указанием затронутых пакетов.
Очень полезная привычка отмечать как автоматический любой пакет, который вам не нужен напрямую, чтобы они автоматически удалялись, когда они больше не нужны. Вы можете использовать команду apt-mark auto package для маркировки данного пакета как автоматического, тогда как команда apt-mark manual package делает обратное. aptitude markauto и aptitude unmarkauto работают точно также, хотя они предлагают больше возможностей для маркировки сразу нескольких пакетов (см. раздел 8.2.7.1, «Aptitude»). Консольный интерактивный интерфейс aptitude также упрощает просмотр отметки «автоматический» на многих пакетах.
Возможно, вам захочется узнать, почему в системе присутствуют автоматически установленные пакеты. Чтобы получить эту информацию из командной строки, вы можете использовать aptitude why package (apt и apt-get не имеют подобной функции):
$ aptitude why python-debian i aptitude Recommends apt-xapian-index i A apt-xapian-index Depends python-debian (>= 0.1.15)
8.3.5 Использование поддержки Multi-Arch Support
Все пакеты Debian имеют поле «Архитектура» (Architecture) в их управляющей информации. Это поле может содержать либо «все» («all» (для тех пакетов, которые не зависят от архитектуры систем)), либо имя архитектуры, на которую он нацелен (например, amd64 или armhf). В последнем случае, по умолчанию, dpkg будет устанавливать пакет только в том случае, если его архитектура соответствует архитектуре хоста, что видно на выводе команды dpkg -print-architecture .
Это ограничение гарантирует, что вы не получите исполняемые файлы, скомпилированные для неправильной архитектуры. Все было бы идеально, за исключением того, что (некоторые) компьютеры могут запускать исполняемые файлы для нескольких архитектур, как стандартным способом (система amd64 может запускать исполняемые файлы i386), так и через эмуляторы.
8.3.5.1 Включение Multi-Arch
Multi-arch поддержка dpkg позволяет пользователям определять внешние архитектуры, которые могут быть установлены в текущей системе. Это легко сделать с помощью dpkg —add-architecture , как в примере ниже, где архитектура i386 должна быть добавлена в систему amd64 для запуска приложений Windows с использованием Wine. Существует соответствующая команда dpkg —remove-architecture для отказа от поддержки внешней архитектуры, но ее можно использовать только тогда, когда на вашей системе не осталось установленных пакетов, относящихся к этой архитектуры.
# dpkg --print-architecture
amd64
# wine
it looks like wine32 is missing, you should install it.
multiarch needs to be enabled first. as root, please
execute "dpkg --add-architecture i386 & apt-get update &
apt-get install wine32"
Usage: wine PROGRAM [ARGUMENTS...] Run the specified program
wine --help Display this help and exit
wine --version Output version information and exit
# dpkg --add-architecture i386
# dpkg --print-foreign-architectures
i386
# apt update
[...]
# apt install wine32
[...]
Setting up libwine:i386 (1.8.6-5) ...
Setting up vdpau-driver-all:i386 (1.1.1-6) ...
Setting up wine32:i386 (1.8.6-5) ...
Setting up libasound2-plugins:i386 (1.1.1-1) ...
Processing triggers for libc-bin (2.24-9)
# wine
Usage: wine PROGRAM [ARGUMENTS...] Run the specified program
wine --help Display this help and exit
wine --version Output version information and exit
# dpkg --remove-architecture i386
dpkg: error: cannot remove architecture 'i386' currently in use by the database
# dpkg --print-foreign-architectures
i386 APT автоматически определит, когда dpkg был настроен для поддержки внешних архитектур и начнет скачивание соответствующих файлов пакетов на протяжении процесса обновления.
Затем могут быть установлены внешние пакеты с помощью команды apt install package-.architecture .
Использование патентованных i386 исполняемых файлов на amd64
Существует множество вариантов использования multi-arch, но наиболее популярным из них является возможность выполнения 32-разрядных бинарных файлов (i386) в 64-битных системах (amd64), в частности, благодаря тому, что несколько популярных фирменных приложений (таких как Skype) предоставляются только в 32 разрядных версиях.
8.3.5.2 Изменения, связанные с Multi-Arch
Чтобы сделать multi-arch реально полезным и удобным в использовании, библиотеки должны быть перепакетированы и перемещены в специальную директорию для архитектур таким образом, чтобы несколько экземпляров (ориентированных на разные архитектуры) могли успешно сосуществовать друг с другом. Такие обновленные пакеты содержат Multi-Arch: одно и то же поле заголовка для того, чтобы сообщить системе пакетирования, что различные архитектуры пакета могут безопасно сосуществовать (и что эти пакеты могут удовлетворять только зависимости пакетов такой же архитектуры).
$ dpkg -s libwine dpkg-query: error: --status needs a valid package name but 'libwine' is not: ambiguous package name 'libwine' with more than one installed instance Use --help for help about querying packages. $ dpkg -s libwine:amd64 libwine:i386 | grep ^Multi Multi-Arch: same Multi-Arch: same $ dpkg -L libgcc1:amd64 |grep .so [...] /usr/lib/x86_64-linux-gnu/wine/libwine.so.1 $ dpkg -S /usr/share/doc/libwine/copyright libwine:amd64, libwine:i386: /usr/share/doc/libwine/copyright
Также стоит отметить, что в Multi-Arch одинаковые пакеты должны иметь названия в соответствии с их архитектурой для того, чтобы идентифицироваться без проблем. Эти пакеты также могут совместно использовать файлы с другими экземплярами одного и того же пакета; dpkg гарантирует, что все пакеты обладают одинаковыми поразрядными файлами, когда последние совместно используются. Также, все экземпляры пакета должны иметь одну и ту же версию, поэтому их необходимо обновлять вместе.
Поддержка Multi-Arch приносит некоторые интересные трудности, вызванные способом, которым обрабатываются зависимости. Удовлетворение зависимости требует либо пакета отмеченного как Multi-Arch: foreign или пакета, архитектура которого соответствует одному из пакетов, объявляющих зависимость (в этом процессе восстановления зависимостей предполагается, что независимые от архитектуры пакеты имеют такую же архитектуру что и хост). Зависимость также может быть ослаблена для того, чтобы позволить любой другой архитектуре выполнить её с помощью package:любой синтаксис, но внешние пакеты могут удовлетворить подобную зависимость, если они отмечены как Multi-Arch: allowed.
8.3.6 Проверка подлинности пакета
Обновление системы представляет собой очень уязвимую операцию, так что вы должны полностью убедиться, что вы устанавливаете пакеты лишь из официальных репозиториев Kali. Если зеркало Kali, которое вы использовали, было взломано, то человек, проделавший это, захочет добавить вредоносный код во вполне себе официальный пакет. Подобного рода пакет, в случае его установки, сможет делать абсолютно все, что в него было заложено взломщиком, включая хищение паролей или конфиденциальной информации. Для того чтобы обойти этот риск Kali предоставляет защищенный от злонамеренного вмешательства изолирующий слой – на время установки – который поможет удостовериться в том, что пакет реально происходит из официального источника и не был изменен кем-либо со стороны.
Изолирующий слой работает с цепочкой криптографической хэш-функции и подписью. Подписанный файл является Release файлом, предоставленным зеркалами Kali. Он содержит список файлов файловых пакетов (включая из сжатые формы, Packages.gz and Packages.xz, и инкрементные версии) вместе с их MD5, SHA1, и SHA256 хэшами, что в свою очередь гарантирует, что файлы еще не были подвергнуты вмешательству. Эти файлы пакетов содержат список пакетов Debian, доступных на зеркале, вместе с их хэшами, которые гарантируют в свою очередь, что пакеты сами по себе еще не были изменены.
Доверенные ключи управляются командой apt-key, которая находится в apt пакете. Эта программа поддерживает общественные ключи keyring GnuPG, которые используются для проверки подписей в файле Release.gpg, доступном на зеркалах. Он может использоваться для добавления новых ключей вручную (когда вам необходимы неофициальные зеркала). Однако, как правило, нужны только официальные ключи. Эти ключи автоматически поддерживаются в актуальном состоянии пакетом kali-archive-keyring (который помещает соответствующий keyrings в /etc/apt/trusted.gpg.d ). Однако, первая установка отдельных пакетов, требует особого внимания: даже если пакет подписан как любой другой, подпись не может быть проверена извне. Осторожный администратор должен всегда идентифицировать импортируемые ключи, перед тем как доверять им и начинать установку новых пакетов.
# apt-key fingerprint
/etc/apt/trusted.gpg.d/debian-archive-jessie-automatic.gpg
----------------------------------------------------------
pub 4096R/2B90D010 2014-11-21 [expires: 2022-11-19]
Key fingerprint = 126C 0D24 BD8A 2942 CC7D F8AC 7638 D044 2B90 D010
uid Debian Archive Automatic Signing Key (8/jessie)<ftpmaster@debian.org>
/etc/apt/trusted.gpg.d/debian-archive-jessie-security-automatic.gpg
-------------------------------------------------------------------
pub 4096R/C857C906 2014-11-21 [expires: 2022-11-19]
Key fingerprint = D211 6914 1CEC D440 F2EB 8DDA 9D6D 8F6B C857 C906
uid Debian Security Archive Automatic Signing Key (8/jessie)<ftpmaster@debian.org>
/etc/apt/trusted.gpg.d/debian-archive-jessie-stable.gpg
-------------------------------------------------------
pub 4096R/518E17E1 2013-08-17 [expires: 2021-08-15]
Key fingerprint = 75DD C3C4 A499 F1A1 8CB5 F3C8 CBF8 D6FD 518E 17E1
uid Jessie Stable Release Key<debian-release@lists.debian.org>
/etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg
-----------------------------------------------------------
pub 4096R/473041FA 2010-08-27 [expires: 2018-03-05]
Key fingerprint = 9FED 2BCB DCD2 9CDF 7626 78CB AED4 B06F 4730 41FA
uid Debian Archive Automatic Signing Key (6.0/squeeze)<ftpmaster@debian.org>
/etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg
--------------------------------------------------------
pub 4096R/B98321F9 2010-08-07 [expires: 2017-08-05]
Key fingerprint = 0E4E DE2C 7F3E 1FC0 D033 800E 6448 1591 B983 21F9
uid Squeeze Stable Release Key<debian-release@lists.debian.org>
/etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg
----------------------------------------------------------
pub 4096R/46925553 2012-04-27 [expires: 2020-04-25]
Key fingerprint = A1BD 8E9D 78F7 FE5C 3E65 D8AF 8B48 AD62 4692 5553
uid Debian Archive Automatic Signing Key (7.0/wheezy)<ftpmaster@debian.org>
/etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg
-------------------------------------------------------
pub 4096R/65FFB764 2012-05-08 [expires: 2019-05-07]
Key fingerprint = ED6D 6527 1AAC F0FF 15D1 2303 6FB2 A1C2 65FF B764
uid Wheezy Stable Release Key<debian-release@lists.debian.org>
/etc/apt/trusted.gpg.d/kali-archive-keyring.gpg
-----------------------------------------------
pub 4096R/7D8D0BF6 2012-03-05 [expires: 2018-02-02]
Key fingerprint = 44C6 513A 8E4F B3D3 0875 F758 ED44 4FF0 7D8D 0BF6
uid Kali Linux Repository<devel@kali.org>
sub 4096R/FC0D0DCB 2012-03-05 [expires: 2018-02-02] Когда в sources.list добавляется пакет из неофициального источника, APT должен быть уведомлен о том, что он может доверять соответствующему GPG ключу аутентификации (в противном случае он будет продолжать жаловаться, что он не может гарантировать подлинность пакетов, поступающих из этого репозитория). Первым шагом, безусловно, является получение публичного ключа. Чаще всего ключ будет предоставлен в виде небольшого текстового файла, который мы будем называть key.asc в следующих примерах.
Для того чтобы добавить ключ к доверенному keyring, администратор должен запустить run apt-key add < key.asc . Другим способом является использование графического интерфейса synaptic: его вкладка Authentication в меню Settings — Repositories предоставляет возможность импорта ключей из файла key.asc.
Для людей, которые предпочитают специализированное приложение и более подробную информацию о доверенных ключах, можно использовать gui-apt-key (в пакете с тем же именем), небольшой пользовательский графический интерфейс, который управляет доверенным ключом.
После того, как соответствующие ключи находятся в keyring, APT проверит сигнатуры перед любой рискованной операцией, чтобы интерфейсы отображали предупреждение, если было предложено установить пакет, подлинность которого не может быть установлена.
Перейти к содержанию книги Kali Linux Revealed
Это интересно: