当项目是开源的时，谁应该拥有用于签署.NET程序集的私钥？
更具体地说，是一个类库程序集。 我最初的想法：
- 让一些指定的管理员进行所有程序集签名。 但是当bug修复和编写新版本时，二进制文件最终将取决于它们的存在（即使由于私人原因它只是一个小的变化）。
- 关键可以公开。 但这违背了公钥加密实践，您失去了信任和身份的优势。
- 允许最终开发人员和分销商使用自己的密钥对其进行签名。 但是，由于每次新签名都会使其与其他一些版本不兼容，因此您将失去模块化。
当然，你可以不签署assembly。 但是，如果需要对其程序集进行签名的另一个项目引用了您的库，则会出现编译错误。
我最近在我维护的开源项目中遇到了同样的问题。 以下是我解决此问题的方法：
- 源始终可通过存储库进行下载，但是发行版将包含源的快照以及已编译的版本。
- 在使编译版本可用之前，我使用我的私钥对程序集进行签名。
因此，在您的情况下，准备发布的任何人都应该拥有密钥。 图书馆开发人员根本不需要了解它。
如果最终用户想要重新编译并使用自己的密钥签名，那很好。 您可以通过比较签名程序集中存在的公钥来区分您的二进制文件和其他二进制文件。 使公钥可用，其他人也可以这样做。
当InternalsVisibleToAttribute用于引用强名称程序集时，管理此过程会有点麻烦。 你可以在这里阅读我如何解决这个问题。
我不会介意，如果你可能只是用作参考而不是编辑和重新编译的更多项目将提供dll的“签名”版本。 这比检查代码和编译自己的代码更有助于信任现有.dll的参考。
在许多开源项目中，有一种“父母”的努力，想想Linus甚至John Gruber的例子。 这些人可以持有密钥或将其分发给受信任的管理员以签署主要版本。
强命名不是为了提供真实性，validation，保护或其他类似的东西。 其唯一目的是为组件或一系列组件提供唯一的ID。 这样您就可以在GAC中拥有许多名为“Library”的程序集，当您的应用程序要求运行时加载“Library”时，系统知道这意味着您的“Library”程序集而不是其他人的程序集。
鉴于此，我只需在源代码树中包含强名称密钥。 如果出于某种原因，您的项目想要提供真实性或任何其他东西，那么您可能需要Authenticode签名，这不是免费的，对于开源项目来说可能实际上是不必要的。 如果您决定走这条路并且想知道谁应该拥有代码签名密钥，那就变成了一个政治问题。
在开源中，“源”是开放的。 二进制文件通常仅用于商品。
源不需要签名，如果二进制文件已签名，则二进制文件的生成器也是密钥的所有者（应保密）。
问题实际上围绕着谁决定什么是发布，不是吗？ 如果是这样的话，我认为应该使用实际负责发布的个人密钥签署版本。 如果有多个人负责创建版本，那么他们共享密钥没有任何问题，除非如果该组的一个成员离开则必须撤销/重新发布密钥的风险更高。
在更广泛的范围内，人们必须承认，.net并不真正适合在多个已安装的应用程序之间重用程序集。 查看您的SxS文件夹！ 因此，另一种方式是组件的分销商用他自己的密钥签名。 例如，如果项目使用log4net，它应该使用自己的密钥对log4net程序集进行签名，以对其内容负责。
据我所知，我从未遇到过签名的开源项目。 如果我出于某种原因需要签名，我自己签了名。 我无法真正看到签署assembly的优势。 如果你担心预编译的二进制版本被签名，那么我会说项目管理应该有那个密钥。 创建签名项目的人应该完全能够将源代码添加到他们的项目中，或者创建项目的必要签名并为自己编译。
将私钥存储在源控件根目录之外，但使用相对路径引用。 其他人可以使用自己的密钥进行构建。 他们将签署强烈签名但不是官方版本。
设置具有完整源树和私钥的自动构建。 自动构建可以制作官方签名版本，可以在夜间或其他任何时候发布。 这样制作官方版本是自动的，因此持有私钥的授权人员不一定必须参与（尽管您应该有一些机制来validation社区贡献的补丁，然后再包含在官方版本中，但这是一个单独的问题真）。