Данные формата Openpgp debian не найдены

Обновлено: 05.07.2024

-я загрузил свой offline-rtc2/trippleThrillPack с gog.
-затем я получил innoextract
-извлечение прошло успешно

следующего шага не было. :

не удалось установить игру после обновления.

Очень благодарен за помощь

Последний раз редактировалось ab90 (2019-01-03 19:56:29)

"Будь скромным, будь крутым, танцуй в стиле техно под хэви-метал".

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

Здесь есть действительно хороший пост о том, как установить / преобразовать материал из ppas в правильные пакеты Debian и избежать поломки. для установки вещей.

Блажен, кто ничего не ожидает, ибо он не будет разочарован.
Если есть непонятный или глупый способ сломать его, но вы не знаете какой... Просто спросите меня

Приложения на основе Ubuntu несовместимы напрямую с Debian, поэтому в конечном итоге вы сломаете свою систему или, по крайней мере, пакет НЕ будет установлен.

Настоящие мужчины используют Linux

Проблема возникает из-за того, что gpg не находит того, что ожидает. Запустите команду с параметром --massive-debug, чтобы распечатать полезную трассировку того, что именно не работает, поскольку невозможно сказать только по этой одной строке. Я ожидаю, что это будет импорт ключа PPA в каталог /etc/apt/trusted.gpg.d или аналогичный.

Еще одна причина может заключаться в том, что вам необходимо удалить bunsen-os-release, поскольку библиотека python-apt зависит от информации, идентифицирующей ОС, которая является общеизвестной базовой ОС, такой как Debian/Ubuntu, что также может быть причиной сбоя. .

Кроме того, запуск apt-get update должен извлекать источники PPA, сначала проверьте, не происходит ли сбой.

Как правильно указывает BB, PPA — это функция Ubuntu, однако: также верно, что в документации OpenRTC говорится о включении PPA в Debian (что может сработать!), поэтому мы можем предположить/надеяться, что разработчики OpenRTC сделали это. свою домашнюю работу и проверить свои вещи. В принципе, нет причин, по которым Launchpad не должен предоставлять пакеты Debian. Если их пакет представляет собой просто статический двоичный файл или дамп двоичных файлов и зависимостей, проблем быть не должно (хотя я не могу сказать, не изучив детали).

Нашел: внимательно посмотрите на первое сообщение в этой теме

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

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

Последний раз редактировалось Bearded_Blunder (2019-01-02 21:41:48)

Другим хорошим примером являются пакеты от Oracle для Virtualbox. У них есть один пакет, написанный для Ubuntu Bionic/Debian 10 (Buster), и он протестирован, и он устанавливается и работает на моей установке Helium. Я бы подумал, что пакет был создан так, чтобы быть максимально совместимым как с Buster, так и с Ubuntu Bionic, без поломок. Так что да, лучше получить пакет напрямую, а не пытаться добавить Ubuntu PPA в вашу систему Helium, иначе вы можете столкнуться с возможными несовместимыми библиотеками и попытками установить их при обновлении.

На самом деле не все пакеты PPA совместимы с Debian, поэтому будьте очень осторожны с такими пакетами из PPA и знайте, что делаете.

Последний раз редактировалось DeepDayze (2019-01-03 14:42:04)

Настоящие мужчины используют Linux

Нашел: внимательно изучите первое сообщение в этой теме

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

Я не хочу показаться бесполезным или недружественным, но вы начали здесь, спросив, как сортировать что-то с большим количеством источников и несколькими выпусками Debian в вашем sources.list, вот почему у вас были проблемы с самого начала, я вижу в другом месте, что вы говорите, что переустанавливали. Хорошо, это хорошо, но добавление всех этих источников обратно, чтобы установить вещи, просто снова нарушит вашу установку.

Linux Mint приходит на ум как надежный дистрибутив на основе Ubuntu, который вы можете установить вместе с BL в запасной раздел, если хотите поиграть с программным обеспечением на основе Ubuntu.

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

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

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

Все о безопасном подключении
Основные понятия
Надежная основа: контрольные суммы
Подписанные файлы выпуска
Как apt использует Release.gpg
Как определить, чему доверять
Как найти и добавить ключ
Как узнать, безопасен ли ключ
Срок действия ключа архива Debian
Как вручную проверить целостность пакета
Другие проблемы
Настройка безопасного репозитория apt
Неудачные обновления и отсутствующие ключи
История
Комментарии и вопросы

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

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

Защищенная хэш-функция (разновидность контрольной суммы) – это метод, позволяющий взять файл и свести его к достаточно короткому числу, которое однозначно идентифицирует содержимое файла, даже если люди намеренно пытаются создать пару разные файлы с одинаковой контрольной суммой или создать новый файл, соответствующий предыдущей контрольной сумме. Первоначально 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 .

OpenPGP.js — это реализация протокола OpenPGP на языке JavaScript.Он реализует RFC4880 и части RFC4880bis.

Оглавление

Комплект dist/openpgp.min.js хорошо работает с последними версиями Chrome, Firefox, Safari и Edge.

Комплект dist/node/openpgp.min.js хорошо работает в Node.js. Он используется по умолчанию, когда вы требуете ('openpgp') в Node.js.

В настоящее время Chrome, Safari и Edge имеют частичную реализацию спецификации Streams, а Firefox имеет частичную реализацию за флагами функций. Chrome — единственный браузер, который реализует необходимые нам TransformStream s, поэтому мы включаем полифилл для всех остальных браузеров. Обратите внимание, что в этих браузерах глобальное свойство ReadableStream перезаписывается версией полифилла, если она существует. В некоторых крайних случаях вам может понадобиться использовать собственный ReadableStream (например, при его использовании для создания объекта Response), и в этом случае вы должны сохранить ссылку на него перед загрузкой OpenPGP.js. Существует также библиотека веб-потоков-адаптеров для преобразования между ними туда и обратно.

В версии 3.0.0 библиотеки появилась поддержка криптографии с открытым ключом с использованием эллиптических кривых. Мы используем собственные реализации в браузерах и Node.js, когда они доступны. Криптография на основе эллиптических кривых обеспечивает более надежную защиту каждого бита ключа, что позволяет выполнять операции намного быстрее. В настоящее время поддерживаются следующие кривые:

Кривая	Шифрование	Подпись	NodeCrypto	WebCrypto	Постоянное время
curve25519	ECDH	Н/Д	Нет	Нет	Алгоритмически**
ed25519	Н/Д	EdDSA	Нет	Нет	Алгоритмически**
p256	ECDH	ECDSA	Да*	Да*	Если родной***
p384	ECDH	ECDSA	Да*	Да*	Я f native***
p521	ECDH	ECDSA	Да*	Да*	Если родной***
brainpoolP256r1	ECDH	ECDSA	Да*	Нет	Если родной***
brainpoolP384r1	ECDH	ECDSA	Да*	Нет	Если родной***
brainpoolP512r1	ECDH	ECDSA	Да*	Нет< /td>	Если родной***
secp256k1	ECDH< /td>	ECDSA	Да*	Нет	Если нац. ive***

* когда доступно
** реализации curve25519 и ed25519 являются алгоритмически постоянными, но могут не быть постоянными после оптимизации компилятора JavaScript
*** эти кривые являются только постоянными если базовая нативная реализация доступна и работает с постоянным временем

Версия 2.x библиотеки была создана с нуля с использованием Uint8Arrays. Это обеспечивает гораздо лучшую производительность и использование памяти, чем строки.

Если браузер пользователя поддерживает нативную WebCrypto через API window.crypto.subtle, будет использоваться это. В Node.js используется собственный модуль шифрования.

Библиотека реализует предложение IETF для шифрования с проверкой подлинности с использованием собственных AES-EAX, OCB или GCM. Это делает симметричное шифрование до 30 раз быстрее на поддерживаемых платформах. Поскольку спецификация еще не завершена, а другие реализации OpenPGP еще не приняли ее, эта функция в настоящее время не используется. Примечание. Активация этого параметра может нарушить совместимость с другими реализациями OpenPGP, а также с будущими версиями OpenPGP.js. Не используйте его с сообщениями, которые вы хотите сохранить на диске или в базе данных. Вы можете включить его, установив openpgp.config.aeadProtect = true .

Вы можете изменить режим AEAD, установив один из следующих параметров:

Для сред, не поддерживающих собственное шифрование, библиотека использует реализации AES, SHA-1 и SHA-256 asm.js.

Установите OpenPGP.js с помощью npm и сохраните его в своих зависимостях:

И импортируйте его как модуль CommonJS:

Или как модуль ES6 из файла .mjs:

Импортировать как модуль ES6, используя /dist/openpgp.mjs.

Установите OpenPGP.js с помощью npm и сохраните его в своих devDependencies:

И импортируйте его как модуль ES6:

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

Или, если вы хотите использовать упрощенную сборку (которая меньше по размеру и лениво загружает кривые не по умолчанию по требованию):

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

Дополнительные примеры создания ключа см. в разделе Создание новой пары ключей. По умолчанию рекомендуется использовать curve25519 вместо brainpoolP512r1.

Браузер (обычные файлы)

Чтобы выгрузить криптографические операции из основного потока, вы можете внедрить Web Worker в свое приложение и оттуда загрузить OpenPGP.js. Пример реализации Worker см. в test/worker/worker_example.js .

Вот несколько примеров использования OpenPGP.js v5. Более подробные примеры и рабочий код можно найти в общедоступных модульных тестах API. Если вы выполняете обновление с версии 4, возможно, вам будет полезно ознакомиться с журналом изменений и документацией.

Зашифровать и расшифровать данные Uint8Array с помощью пароля

Шифрование будет использовать алгоритм, указанный в config.preferredSymmetricAlgorithm (по умолчанию aes256), а дешифрование будет использовать алгоритм, используемый для шифрования.

Шифровать и расшифровывать данные String с помощью ключей PGP

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

Шифровать несколькими открытыми ключами:

Если вы ожидаете, что зашифрованное сообщение будет подписано одним из открытых ключей, которые у вас есть, и не хотите доверять расшифрованным данным в противном случае, вы можете указать параметр расшифровки expectSigned = true , чтобы операция расшифровки завершилась неудачно, если действительная подпись не найдена:

Симметричное шифрование со сжатием

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

или изменив глобальную конфигурацию по умолчанию:

Где значение может быть любым из:

Потоковое шифрование данных Uint8Array с помощью пароля

Дополнительную информацию об использовании ReadableStreams см. в документации MDN по Streams API.

Вы также можете передать поток чтения Node.js, и в этом случае OpenPGP.js также вернет поток чтения Node.js, который вы можете, например, .pipe() в поток записи.

Потоковое шифрование и дешифрование строковых данных с помощью ключей PGP

Создать новую пару ключей

Ключи ECC (меньше и быстрее генерируются):

Ключи RSA (повышенная совместимость):

Использование сертификата отзыва:

Использование закрытого ключа:

Подписывать и проверять текстовые сообщения

Создание и проверка отдельных подписей

Потоковая подпись и проверка данных Uint8Array

На сегодняшний день кодовая база OpenPGP.js прошла два полных аудита безопасности от Cure53. Первый аудиторский отчет опубликован здесь.

Следует отметить, что криптографические приложения js, развернутые через обычный веб-хостинг (то есть безопасность на основе хоста), обеспечивают пользователям меньшую безопасность, чем устанавливаемые приложения со статическими версиями, подлежащими аудиту. Устанавливаемые приложения можно развернуть как упакованное приложение Firefox или Chrome. Эти приложения в основном представляют собой подписанные zip-файлы, и их среды выполнения обычно применяют строгую политику безопасности содержимого (CSP) для защиты пользователей от XSS. В этой записи блога достаточно хорошо объясняется модель доверия в Интернете.

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

Чтобы создать собственную сборку библиотеки, просто выполните следующую команду после клонирования репозитория git. Это загрузит все зависимости, запустит тесты и создаст мини-пакет в dist/openpgp.min.js для использования в вашем проекте:

Как принять участие?

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

GNU Lesser General Public License (версия 3.0 или более поздняя). Дополнительную информацию см. в файле LICENSE.

Вы уверены, что ваш пакет защищен от повреждения или вредоносной активности? Вот как может помочь проверка подписи.

Опубликовано: 16 июня 2020 г. | Сьюзен Лаубер

Дополнительные ресурсы по Linux

Большие и популярные репозитории RPM обычно дублируются по всему миру. Проекты и компании, предоставляющие пакеты, используют сети распространения контента (CDN) и зеркальные сайты, чтобы сделать свои пакеты доступными для потребителей. Для многих проектов с открытым исходным кодом это включает размещение волонтерами. Чтобы обнаруживать вредоносные заменяющие пакеты и избегать их, владельцы пакетов могут подписывать файлы пакетов, а потребители могут проверять эти подписи.

Хотя GPG может подписать любой файл, ручная проверка подписей пакетов недоступна для системных администраторов. Формат RPM имеет область, специально зарезервированную для хранения подписи заголовка и полезной нагрузки. Утилита rpm использует ключи GPG для подписи пакетов и собственный набор импортированных открытых ключей для проверки пакетов. YUM и DNF используют файлы конфигурации репозитория для предоставления указателей на расположение открытых ключей GPG и помогают импортировать ключи, чтобы RPM мог проверять пакеты.

В этой статье я буду использовать ключи и пакеты от EPEL. Открытый ключ включен в пакет RPM, который также настраивает репозиторий yum. Для некоторых проектов ключ также может быть доступен непосредственно с исходного веб-сайта.

У утилиты rpm есть собственное управление ключами

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

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

В этом случае появляется сообщение "ПОДПИСЬ НЕ ОК", потому что ключ еще не был импортирован для RPM. По умолчанию команды rpm проверяют подпись пакетов во время любой установки или проверки. Если это невозможно из-за того, что пакет не подписан или открытый ключ недоступен, вам может потребоваться указать параметр --nogpgcheck, чтобы пропустить этот шаг.

Если у вас есть доступ к открытому ключу GPG, вы можете использовать следующую команду для импорта ключа вручную:

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

Используйте следующую команду, чтобы получить список ключей:

Используйте эту команду для получения информации о ключе:

Для удаления ключа используется следующая команда:

Дополнительные параметры управления ключами описаны на справочной странице, включенной в пакет rpmkey.

YUM и DNF могут добавлять ключи в базу данных RPM

Другие менеджеры пакетов еще больше упрощают управление ключами. YUM и DNF используют файлы конфигурации в /etc/yum.repos.d для указания URL-адреса ключа GPG, используемого для проверки пакетов в этом репозитории. Затем утилиты могут импортировать ключ, если он еще не доступен для проверки.

В файле конфигурации репозитория yum строка gpgcheck=1 указывает, что проверка GPG должна выполняться для всех пакетов в этом репозитории. Это логическое значение, которое можно изменить в конфигурации или временно переопределить в командной строке с помощью параметра --nogpgcheck.

Если открытый ключ GPG еще не был импортирован в RPM, когда начинается установка пакета, утилита yum (или dnf) может инициировать импорт ключа. Строка gpgkey=URI указывает источник импортируемого ключа. Этот источник может быть любым URI, включая локальный файл или удаленную веб-ссылку. Утилита yum или dnf сделает паузу и запросит подтверждение импорта ключа после отображения идентификатора ключа и отпечатка пальца.

Ключ добавляется в RPM, после чего продолжается проверка и установка пакета.

Подготовьтесь к подписанию пакета

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

Первый шаг — создать пару ключей GPG для подписи. Не забудьте также экспортировать и поделиться открытым ключом. Для пакетов, которые будут распространяться публично, рекомендуется использовать новую пару ключей и связку ключей в общем расположении. Кроме того, используйте параметр --full-gen-key, а затем выберите создание ключа только для подписи вместо ключа по умолчанию, который создает как ключ подписи, так и ключ шифрования.

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

Далее нам нужно установить пакет rpm-sign и настроить файл rpmmacros, указав используемый ключ. Пакет rpm-sign включает справочную страницу для rpmsign, которая описывает процесс. Обратите внимание, что в имени пакета есть тире, которое не является частью имени команды.

Команды RPM получают свою конфигурацию из нескольких файлов rpmmacros. Существует файл по умолчанию с множеством примеров, расположенный в /usr/lib/rpm/macros. Если за подписание пакетов с использованием одного и того же ключа отвечают несколько человек, поместите центральный файл конфигурации в папку /etc/rpm/macros. Наконец, для конкретного лица, подписывающего пакеты, пользовательский файл ~/.rpmacros может быть настроен так, чтобы он указывал на правильный ключ GPG.

Минимальная запись для файла rpmmacros — это указание имени ключа. Вы можете использовать имя или идентификатор ключа. Получите идентификатор ключа с помощью команды gpg --list-keys.

Совет. Запустите команду rpmsign перед установкой переменной gpg_name, и в сообщении будет показан формат.

Помимо имени ключа, если связка ключей находится не в каталоге пользователя по умолчанию ~/.gnupg, используйте переменную gpg_path, чтобы указать местоположение. Это значение будет таким же, какое использовалось с параметром --keyring при создании ключа.

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

Подписать и опубликовать пакеты

Теперь вы готовы подписать пакет или пакеты. Согласно справочной странице rpmsign, команды --addsign и --resign взаимозаменяемы. В обоих случаях часть подписи файла пакета RPM заменяется текущей информацией.

Следующая команда является примером использования флага --addsign:

Старые версии rpmbuild включали параметр --sign, который мог подписывать пакет в процессе сборки, если ключи GPG и файлы rpmmacro были настроены правильно. Параметр --sign теперь устарел в пользу отдельного шага использования rpmsign . Этот подход поощряет рабочий процесс создание, тестирование, подпись, публикация.

Наконец, сделайте пакеты и открытый ключ GPG доступными для клиентов. Один из вариантов — имитировать проект EPEL и создать файл RPM, который включает открытый ключ GPG и один или несколько файлов репозитория yum, указывающих на расположение подписанных пакетов. Для организаций, размещающих пакеты на сервере Red Hat Satellite, начните с загрузки открытого ключа GPG, а затем назначьте этот ключ продукту или репозиторию, в котором хранятся подписанные пакеты. Все пакеты в репозитории должны быть подписаны одним и тем же ключом. Это частая причина, по которой администраторы Satellite удаляют пакеты перед загрузкой.

Теперь, когда вы знаете больше об управлении RPM-пакетами с помощью GPG, вы можете лучше понять, как работать с rpm , yum и dnf .

Дополнительную информацию см. в разделе Защита ключей подписи RPM, а также в руководствах по администрированию и управлению контентом в документации Red Hat Satellite.

[ Хотите узнать больше о безопасности? Ознакомьтесь с контрольным списком ИТ-безопасности и соответствия требованиям. ]

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