Maven Central工件的预期GPG用户ID? [英] Expected GPG user ID for Maven Central artifacts?

问题描述

我正在执行(看似复杂的)过程，以便在Maven Central上获取公司的工件.然后，我进入了GPG签名部分，进入了一个充满困惑和难题的新世界. GPG有这么多种选择，而且尚不清楚在签署公司产品时应该采取什么合理的做法.

I was going through the (seemingly intricate) procedures for getting a company's artifact on Maven Central. Then I got to the GPG signing part and entered a new world of confusion and conundrums. GPG has so many options, and it's not evident what a reasonable practice should be for signing company artifacts.

假设Acme希望将工件org.example.acme:foobar:1.0.0发布到Maven Central.他们应该使用哪个用户ID进行签名?什么子项?该密钥如何与用户的个人密钥分开?

Let's say that Acme wants to publish an artifact org.example.acme:foobar:1.0.0 to Maven Central. What user ID should they use to sign it? What subkeys? How would that key be kept separate from the user's personal key?

让我经历所有的疑问，以使您了解为什么会造成混淆.

Let me go through all the doubts to give you an idea of why it is confusing.

• 我应该为Acme使用什么电子邮件?我应该使用[e-mail]吗?身份应该是Acme还是Acme的一个部门?还是只有个人签署文物才能在Maven上发布?
• 那评论呢?一位来源表示，我们应该完全省略评论.我应该使用"Acme (software) [e-mail]"吗?或者只是"Acme [e-mail]".
• 好的，所以也许您说这没关系，而且所有这些都是基于观点的，我可以使用对我公司有用的任何东西-很好.但是，如何将我的公司和个人ID分开?我可以在同一台计算机的同一钥匙圈上拥有Acme的密钥和John Doe的单独的密钥吗?发布工件时，我该如何区分它们?所有这些示例似乎都假设您使用的是单一身份.
• 我应该使用子项吗?我应该为不同部门创建不同的子项吗?还是相同的子项具有不同的身份?还是什么?
• 我应该让我的钥匙失效吗?还是只是主键?还是只是子项?

• What email should I use for Acme? Should I use [e-mail]? Should the identity be for Acme, or a division of Acme? Or should only individuals sign artifacts for publication on Maven?
• What about the comment? One source said we should leave comments out altogether. Should I use "Acme (software) [e-mail]"? Or just "Acme [e-mail]".
• OK, so maybe you say it doesn't matter, and that all this is opinion based, and I can use whatever works for my company---fine. But then how do I keep my company and personal ID separate? Can I have a key for Acme and a separate key for John Doe on the same keyring on the same computer? How would I then distinguish them when publishing artifacts? All of the examples seem to assume you are using a single identity.
• Should I be using subkeys? Should I create different subkeys for different departments? Or different identities for the same subkeys? Or what?
• Should I make my keys expire? Or just the main key? Or just the subkey?

我可以不停地继续下去...试图总结一下，所有示例似乎都假设1)用户在密钥环上仅安装了一个用户ID，并且2)每个签署其工件的人都是个人，而不是公司

I could go on and on and on... Trying to summarize, all the examples seem to assume 1) the user only has one user ID installed on their keyring, and 2) everyone signing their artifacts are individuals, not companies.

对组织的Maven工件进行签名的预期方法是什么?以及用户如何与用户的个人密钥分开管理组织的密钥?

推荐答案

我应该为Acme使用什么电子邮件?我应该使用[e-mail]吗?身份应该是Acme还是Acme的一个部门?还是只有个人签署文物才能在Maven上发布?

What email should I use for Acme? Should I use [e-mail]? Should the identity be for Acme, or a division of Acme? Or should only individuals sign artifacts for publication on Maven?

使用该键，用于组/部门的公共通信.对于较小的公司，我可能会选择一些通用地址，例如[e-mail].

Use the one that is used for public communication of the group/department using the key. For a smaller company, I'd probably go for some generic address like [e-mail].

不要混在一起.这是一个公司密钥，用于标识公司(或公司内部的特定职能)而不是个人.

Don't mix in persons. This is a company key, which identifies the company (or a specific function inside the company) and not an individual.

评论如何?一位消息人士说，我们应该完全不加评论.我应该使用"Acme(软件)[e-mail]"吗?或只是"Acme [e-mail]".

What about the comment? One source said we should leave comments out altogether. Should I use "Acme (software) [e-mail]"? Or just "Acme [e-mail]".

软件"注释是否添加了任何相关信息?我不这么认为，因此请放开它，因为它只会增加噪音.

Does the "software" comment add any relevant information? I don't think so, so leave it away as it just adds noise.

通常，将诸如签名密钥"之类的内容添加为此类密钥的注释.我认为这不是必需的，因为用法很明显.如果要防止其他人使用该密钥发送加密的邮件，则最好将密钥用法限制为仅签名，从而强制执行此限制(并且不只是要求其他用户不要使用该密钥进行加密)./p>

Often, something like "signing key" is added as a comment for such keys. I don't consider this necessary, as the usage is obvious. If you want to prevent others sending encrypted mail using that key, better limit key usage to signing only, which enforces this limitation (and does not just ask other users not to use the key for encryption).

好的，所以也许您说这没关系，而且所有这些都是基于观点的，我可以使用对我公司有用的任何东西-很好.但是，如何使我的公司和个人ID保持私密?我可以在同一台计算机的同一钥匙圈上拥有Acme的密钥和John Doe的单独的密钥吗?发布工件时，我该如何区分它们?所有这些示例似乎都假设您使用的是单一身份.

OK, so maybe you say it doesn't matter, and that all this is opinion based, and I can use whatever works for my company---fine. But then how do I keep my company and personal ID private? Can I have a key for Acme and a separate key for John Doe on the same keyring on the same computer? How would I then distinguish them when publishing artifacts? All of the examples seem to assume you are using a single identity.

您可以在计算机上拥有任意数量的键，这不是问题. Maven(和其他依赖GnuPG的软件)可以配置为使用特定密钥.通常，您可以放置​​一个用户其中的ID，邮件地址，密钥ID或指纹-由于这是一次性配置，因此最好使用最具体的方式，即指纹.

You can have an arbitrary number of keys on your computer, that's not an issue. Maven (and other software relying on GnuPG) can be configured to use a specific key. Usually, you can either put a user ID, mail address, key ID or fingerprint in there -- as this is a one-time-configuration, better use the most specific way, the fingerprint.

我应该使用子键吗?我应该为不同部门创建不同的子项吗?还是相同的子项具有不同的身份?或者...

Should I be using subkeys? Should I create different subkeys for different departments? Or different identities for the same subkeys? Or...

是的，你应该.这是一个重要的关键.使主键保持脱机状态(安全，...；对组织中最重要的人员/经理以外的其他人来说，访问权限非常狭窄).仅分发仅限于签名的子密钥:您可以将这样的密钥放在构建服务器上，或者将其交给推送构建的员工.如果您需要交换密钥，则不必更改主密钥，而只需更改子密钥(这不花很多功夫，尤其是无需告知客户有关新密钥的信息.)

Yes, you should. This is an important key. Keep the primary key offline (in a safe, ...; with very narrow access for others but the most important people/managers in the organization). Only hand out subkeys limited to signing: you either put such a key on a build server, or hand it to the employee who is pushing the builds. If you need to exchange a key, you don't have to change the primary key, but only the subkey (which is not a lot of effort, and especially does not involve telling your customers about the new key).

为减轻员工离开公司获取密钥副本的麻烦，请使用OpenPGP智能卡(也可以是YubiKey).无法从卡中取出密钥，因此密钥的盗窃等同于卡片的盗窃(而且几乎不会被人察觉).

To mitigate employees leaving the company taking copies of the key, take advantage of OpenPGP smart cards (which might also be a YubiKey). The key cannot be fetched from the card, so theft of the key is equal to theft of the card (and can hardly go unnoticed).

这篇关于Maven Central工件的预期GPG用户ID?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！