为什么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
Paul

@Paul,是的,该链接有所帮助。我将密钥的“信任”级别设置为最终级别,这似乎已经解决了该问题。但是,什么问题呢?为什么会发生这种情况,我是否已解决或只是缓解了症状?
Fouric

对不起,InkBlend,在这种情况下,我筛选和比较搜索结果的能力超出了我对pgp的了解,因此,我无意将其声明为“答案”。看起来Garrett知道发生了什么。
2013年

Answers:


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 2013年

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已经做到了这一点(在注释中指出),但是很高兴将其声明为答案。
muru

7

您可以使用该--always-trust标志跳过此消息。


1
这是绝对正确的,但这只是消除症状而不是疾病。您的解决方案就像服用阿司匹林,因为您患有癌症...
Fabby 2015年

2
--always-trust在某些情况下是一个很好的解决方案,但是如果有问题的密钥确实是用户自己的密钥,则应该给予最终的信任。
Blacklight Shining

4
我的病是GPG顽固地坚持使用密钥环来破坏我的程序文件加密,并且在我安装该软件的每个VM上以不同的方式这样做。
bbozo

@BlacklightShining,如果我还不能验证这一点,则Evolution不允许对到该地址的邮件进行加密。不知道为什么对某人加密文本需要绝对信任- 仅靠边际信任是不可能的。
伊兹(Izzy)
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.