本文介绍了Maven工件是否在用户ID中签署了GnuPG注释的合法使用?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

正如我的其他过于宽泛的问题所指出的那样,我是GPG签名的新手,而且错综复杂.因此,让我尝试将我当前的疑问提炼成一个简单的问题.

I'm new to GPG signing and the intricacies are dizzying, as my other, overly-broad question indicates. So let me try to distill my current doubts into a simple question.

比方说,一家Acme公司想要签署一些工件,以便在Maven Central上发布.通过来自各种来源的大量研究,我收集了以下最佳实践:

Let's say that a company Acme wants to sign some artifacts for publishing on Maven Central. From much research from various sources I glean the following best practices:

  • Acme should have one single primary key, e.g. for [email protected].
  • Acme should generate subkeys for general day-to-day use, such as signing Maven artifacts.
  • There are hardly any legitimate uses for the "comment" portion of a GPG user ID, and this field should be left blank.

不幸的是, Maven工具不适用于使用子项进行签名.因此,这意味着Maven迫使Acme改变他们管理其中央身份的方式,[email protected]! Acme无法再遵循最佳实践.最具问题的是,如果Acme允许开发团队访问主键以签署Maven工件,则它有可能损害其中央身份(例如用于签署财务报表).

Unfortunately Maven tools do not work with signing using a subkey. So that means Maven is forcing Acme to change how they manage their central identity, [email protected]! Acme can no longer follow best practices. Most problematic is that Acme risks compromise of its central identity (e.g. for signing financial statements) if it gives the development team access to the primary key in order to sign Maven artifacts.

因此,为了模拟子密钥,Acme可以为其他电子邮件地址(例如[email protected])创建密钥,并将该主密钥提供给开发团队以对Maven工件进行签名.但是,当在公共密钥服务器上列出密钥时,搜索"Acme"将显示如下:

So to simulate subkeys, Acme could create a key for a different email address, such as [email protected], and give that primary key to the development team for signing Maven artifacts. But then when listing keys on a public key server, a search for "Acme" would show up like this:

Acme <[email protected]>
Acme <[email protected]>

对我来说,这似乎令人困惑.因此,我可以使用注释字段软件"来指示这是我们用来签名软件工件的密钥,因为Maven太密集了,以至于我们不能为此目的使用我们主要身份的子密钥."因此,两个Acme密钥将在公共密钥服务器上列出,如下所示:

To me this seems confusing. I could therefore use the comment field "software" to indicate "this is the key we are using to sign software artifacts because Maven is so dense that it won't let us use subkeys of our main identity for this purpose". Thus the two Acme keys would be listed like so on a public key server:

Acme <[email protected]>
Acme (software) <[email protected]>

因为有几位作者非常坚信注释字段的大多数使用是不合法的,所以我问:这种关键目的"指定是否合法地使用了GPG用户ID的注释?还是使用单独的[email protected][email protected]键更合适?还是只使用一个主[email protected]键,然后让开发团队就可以使用它?

Because several writers are very adamant that most uses of the comment field are not legitimate, I ask: Is this sort of "key-purpose" designation a legitimate use of the comment of a GPG user ID? Or would it be more appropriate to use separate [email protected] and [email protected] keys? Or simply use one primary [email protected] key and let the development team have access to it?

推荐答案

OpenPGP用户ID中的注释通常不错.它们用于进一步指定用户ID,而使用名称字符串和邮件地址则无法实现.限制签名密钥可能就是这种用例.

Comments in OpenPGP user IDs are not generally bad. They're meant for further specification of the user ID, which was not possible through using the name string and mail address. A restriction signing key might very well be such a use case.

大多数人反对使用注释来反对 ,这些注释之所以被添加是因为一些OpenPGP实现和用户前端似乎实施了一个(只是由于不良的用户界面设计).这样显然会产生多余的注释,例如noneJohn Doe's keyMy first PGP key等.似乎也不需要重复您的公司名称,如>`这样的用户ID表示.

Most people arguing against using comments is more about useless comments, which are often added because several OpenPGP implementations and user front ends seem to enforce one (just because of bad user interface design). This results in obviously superfluous comments like none, John Doe's key, My first PGP key and so on. Repeating your company name also seems unneeded, as user IDs like John Doe (ACME inc.) <[email protected]>` indicate.

类似于ACME Inc. (software signing key) <[email protected]> 的用户ID添加有关该用户ID/密钥的相关信息.可能是从关键使用标志中得出的,但是并不是所有人都知道它们,而且它们在大多数OpenPGP前端中都很好地隐藏了.如果您另外将密钥使用标志限制为同时对主密钥进行签名(和认证,不能禁用),则可以得到加分.

A user ID like ACME Inc. (software signing key) <[email protected]> adds relevant information about the user ID/key. One might well derive this from key usage flags, but not everybody knows about them and they're well hidden in most OpenPGP frontends. Bonus points if you additionally restrict the key usage flags to signing (and certification, which cannot be disabled) for the primary key at the same time.

这篇关于Maven工件是否在用户ID中签署了GnuPG注释的合法使用?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

07-22 17:21