我目前正在考虑开源我的项目，并且正在准备向公众发布的源代码和项目结构。现在我有一个问题：如何处理我的程序集的签名密钥？我应该为开源版本创建一个新密钥，并将其与其他文件一起发布到SVN存储库吗？我应该保留密钥，每个想编译代码的人都应该生成自己的密钥吗？
你怎么处理这个？向公众发布签名密钥让我感到有点不舒服。
答案 0 :(得分：22)
对于Protocol Buffers，我释放了密钥。是的，这意味着人们实际上不能相信它是原始的二进制文件 - 但是对于想要稍微修改代码，重建代码并且仍然能够从另一个已签名的程序集中使用它的人来说，它会让生活变得更加容易。
如果有人真的想要一个他们可以信任的协议缓冲版本绝对是使用GitHub代码构建的合法版本，他们可以轻松地从他们信任的源代码构建它。
我当然可以从双方看到它。我想如果我正在编写一个围绕 security 的开源项目，这可能是另一回事。
答案 1 :(得分：18)
不要释放钥匙。
向公众发布签名密钥时，您会感到不舒服。它不是项目的签名。这是您的签名。只有在保密密钥时才能保持二进制文件签名的完整性。释放密钥会破坏已签名程序集的含义和意图以及强大的命名，从而引入新的错误可能性，从而降低每个系统的可靠性。 不要释放密钥。
对于DotNetZip，我不会释放密钥。但这里的关键点是：关键不属于项目;它是我的密钥。很多人都要求密钥，以便他们可以重新构建已签名的二进制文件，但这没有任何意义。我使用密钥来签署多个DotNetZip。根据定义，使用该密钥签名的任何二进制文件都由我签名。使用我的密钥具有相同强名称的任何两个二进制文件都保证是相同的。释放密钥会消除这些保证，并且会破坏强名称的全部目的以及它们周围的安全性。
想象一下开发人员选择他们自己的版本号，并用我的密钥重新签名修改后的二进制文件。现在世界将有2个具有相同强名称但具有不同内容的程序集。
想象一下，如果我能够使用您的密钥签署任何程序集。如果你发布了你的密钥，我可以添加我喜欢的任何代码 - 甚至是恶意代码 - 然后签名，然后秘密地用“坏”代替你的任何“好”签名二进制文件。没有人能说出差异。
这已经破了。自由共享密钥消除了使用签名组件的任何优势。
如果人们想要修改项目中的代码，然后在强名称程序集中重新使用修改后的版本，他们可以使用自己的密钥对修改后的版本进行签名。这并不困难。
答案 2 :(得分：11)
我不会公开发布密钥。签署程序集的重点是人们可以相信你是唯一一个触及二进制文件的人，所以如果添加了任何非法代码，那么签名就会关闭，人们就知道不相信程序集。
签名程序集可以保护您免受其他人向您的二进制文件添加“错误”代码并假装它是合法版本。