Почему gpg расстраивается и как мне это остановить?


24

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

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

После этого он спрашивает меня, действительно ли я хочу использовать ключ (я всегда отвечаю «да», потому что на самом деле это единственный ключ в моей связке ключей, и я знаю, откуда он взялся). Я могу прекрасно расшифровать материал, так почему же gpg бросает шипение, когда я пытаюсь что-то зашифровать? И как я могу предотвратить появление этого сообщения снова?


Помогает ли какой-нибудь из ответов на этот старый вопрос в stackoverflow ?: stackoverflow.com/q/9460140/2422988
Пол

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

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

Ответы:


16

Мне удалось воспроизвести проблему, с которой вы столкнулись. Я сделал так, сделав следующее:

$ gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --gen-key

<specified parameters and let it do its thing>

gpg: key 58018BFE marked as ultimately trusted
public and secret key created and signed.

<snip>

$

Обратите внимание, что процесс помечал ключ как «окончательно доверенный».

Теперь я экспортирую ключи:

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export-secret-keys -a >private.key

$gpg --no-default-keyring --keyring ./test-keyring  --secret-keyring ./test-secring --trustdb-name ./test-trustdb --no-random-seed-file --export -a > public.key

Теперь я импортирую в новую базу данных gpg:

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import public.key

$gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file --import private.key

Теперь, если я пытаюсь зашифровать с использованием новых ключей, я получаю:

$ gpg --no-default-keyring --keyring ./test2-keyring  --secret-keyring ./test2-secring --trustdb-name ./test2-trustdb --no-random-seed-file -r Fake -e
gpg: AE3034E1: There is no assurance this key belongs to the named user

pub  1024R/AE3034E1 2013-06-13 Fake User <fake@example.com>
 Primary key fingerprint: AD4D BAFB 3960 6F9D 47C1  23BE B2E1 67A6 5801 8BFE
      Subkey fingerprint: 58F2 3669 B8BD 1DFC 8B12  096F 5D19 AB91 AE30 34E1

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Причиной этого является модель «паутины доверия». По умолчанию для того, чтобы открытый ключ был доверенным, требуется либо 1 «окончательный» сертификат доверия (как правило, когда вы лично проверили личность вовлеченных людей), либо 3 «предельных» сертификата доверия (где кто-то, кого вы знаете, кто знает кого-то, кого вы знаете ... подписал сертификат).

Поскольку gpg является приложением безопасности, оно предупреждает вас, если вы пытаетесь зашифровать ключ, который не указан как доверенный. Причина, по которой вашему ключу не доверяют в этом случае, проста. Это потому, что вы не экспортировали доверительные отношения из предыдущего экземпляра gpg. Для этого используйте команды --export-ownertrust и --import-ownertrust.

Как всегда, обратитесь к справочной странице .


1
Ключевым моментом является то, что все данные о доверительном ключе хранятся отдельно от набора ключей (как секретного, так и открытого)! ~/.gnupg/trustdb.gpgсодержит базу данных доверия, pubring.gpgоткрытые ключи и secring.gpgсекретные ключи. Пожалуйста, обратитесь к документации GnuPG по этому вопросу .
gertvdijk

28

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

gpg --edit-key YOUR@KEY.ID
gpg> trust
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y

OP сделал это (отмечено в комментариях), но хорошо, что это было указано в качестве ответа.
Муру

7

Вы можете использовать --always-trustфлаг, чтобы пропустить это сообщение.


1
Это абсолютно верно, но это просто устраняет симптомы, а не болезнь. Ваше решение похоже на прием аспирина, потому что у вас рак ...
Fabby

2
--always-trustВ некоторых случаях это хорошее решение , но если рассматриваемый ключ действительно является собственным ключом пользователя, то ему просто следует дать окончательное доверие.
Blacklight Shining

4
Моя болезнь упрямой настойчивость GPG на брелок трах до моего programatic шифрования файлов, и делать это по - разному на каждой VM установить программное обеспечение на.
bbozo

@ BlacklightShining, и если я еще не смог это проверить, Evolution не разрешает шифровать почту на этот адрес. Понятия не имею, почему шифрование текста кому-либо требует абсолютного доверия - и только с минимальным доверием не должно быть возможности.
Иззи
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.