当.NET程序集的项目是开源的时候，谁应该拥有用于签名的私钥？

Question

更具体地说，类库程序集。我最初的想法是：

• 让一些指定的管理员执行所有程序集签名。但是，当编写bug修复和新版本时，二进制文件最终将取决于它们的存在(即使这只是出于私人原因的小改动)。
• 钥匙可以公开使用。但这违背了公钥密码学的做法，你就失去了信任和身份的优势。
• 允许终端开发者和分销商用他们自己的钥匙签名。但是这样就失去了模块化，因为每次新签名都会使它与其他版本不兼容。

当然，你不能在大会上签字。但是，如果另一个需要对其程序集进行签名的项目引用了您的库，则会出现编译错误。

Answer 1

最近，在我维护的开源项目中，我遇到了同样的问题。以下是我如何处理这个问题的方法：

• 源总是可以通过存储库进行下载，但是发行版将包含源代码的快照，以及编译的版本。
• 在使编译后的版本可用之前，我使用私钥对程序集进行签名。

所以在你的情况下，不管是谁在准备发行版，都应该拥有钥匙。库开发人员根本不需要知道这一点。

如果最终用户想要重新编译并用自己的密钥签名，那很好。您可以通过比较签名程序集中存在的公钥来区分您的二进制文件和其他二进制文件。使公钥可用，其他人也可以这样做。

当InternalsVisibleToAttribute用于引用强名称的程序集时，管理此过程会变得有些麻烦。你可以读到我是如何解决这个问题的，这里。

Answer 2

我不介意更多的项目，你可能只是作为参考，而不是编辑和重新编译会提供一个“签名”的dll版本。这将有助于比检查代码和编译自己的代码更快地信任现有.dll的参考。

在许多开源项目中，都有一种“父级”的努力，比如Linus，甚至约翰·格鲁伯。这些人可以持有密钥，也可以将一个密钥分发给可信的管理员，用于签署主要版本。

Answer 3

强命名并不是为了提供真实性、验证、保护或其他类似的内容。它的唯一目的是为程序集或一系列程序集提供唯一的ID。这样您就可以在GAC中拥有许多名为"Library“的程序集，当应用程序要求运行时加载"Library”时，系统知道这意味着您的"Library“程序集而不是其他人的程序集。

有鉴于此，我将简单地将强名称键包含在源树中。如果出于某种原因，您的项目希望提供真实性或其他任何东西，那么您可能需要Authenticode签名，这不是免费的，而且对于开源项目来说可能是不必要的。如果您决定走这条路，并且想知道谁应该拥有代码签名密钥，那么这就更像是一个政治问题。