.NET开源项目和强命名程序集？

我目前正在考虑开源我的一个项目，并且正在准备向公众发布的源代码和项目结构。现在我有一个问题：我应该如何处理程序集的签名密钥？我是否应该为开源版本创建一个新密钥，并将其与其他文件一起发布到SVN存储库？我应该不使用密钥，每个想要编译代码的人都应该生成自己的密钥吗

---

你是怎么处理的？我对公开发布签名密钥感到有点不舒服。

我不会公开发布密钥。拥有签名程序集的全部意义在于，人们可以相信您是唯一一个接触二进制文件的人，因此，如果添加了任何非法代码，那么签名将被取消，人们知道不信任该程序集

对程序集进行签名可以防止其他人向二进制文件中添加“坏”代码并假装它是合法版本。

对于，我释放了密钥。是的，这意味着人们不能真正相信它是原始二进制文件，但对于那些想稍微修改代码、重建代码并仍然能够从另一个已签名程序集中使用代码的人来说，这会大大简化他们的工作

如果任何人真的想要一个他们可以信任的协议缓冲区版本，它肯定是用GitHub的代码构建的合法版本，那么他们可以轻松地从他们信任的源代码构建它

---

我当然可以从两个方面看到这一点。我想如果我写的是一个围绕安全性的开源项目，那可能是另一回事。

不要释放密钥

---

向公众发布签名密钥时，您应该感到不舒服。这不是项目的签名。这是你的签名。只有在密钥保密的情况下，才能保持二进制文件上签名的完整性。释放密钥会破坏已签名程序集和强命名的含义和意图，从而引入新的错误可能性，从而降低每个系统的可靠性。不要松开钥匙

因为，我不会释放钥匙。但关键是：关键不属于项目；这是我的钥匙。许多人要求提供密钥，以便重新构建签名二进制文件，但这毫无意义。我使用密钥来签署DotNetZip以上的内容。根据定义，任何使用该密钥签名的二进制文件都是由我签名的。使用“我的密钥”具有相同强名称的任何两个二进制文件都保证是相同的。释放密钥会移除这些保证，并破坏强名称的全部用途以及围绕它们的安全性

想象一下，开发人员选择自己的版本号，然后用我的密钥对修改后的二进制文件重新签名。现在，世界上将有两个具有相同强名称但内容不同的程序集

想象一下如果我能用你的钥匙在任何集会上签名。如果你释放了你的密钥，我可以添加我喜欢的任何代码——甚至是恶意代码——然后对其进行签名，然后偷偷地将你的任何“好的”签名二进制文件替换为“坏的”。没有人能分辨出两者的区别

这个坏了。自由共享密钥消除了使用签名程序集的任何优势

---

如果用户希望修改项目中的代码，然后在强名称程序集中重新使用修改后的版本，则可以使用自己的密钥对修改后的版本进行签名。这并不难

虽然我同意你的观点，但我不知道如何在开源环境中处理这个问题。项目的每个二进制分发者都应该使用自己的代码？由于它可以用作库，这也意味着其他人不能创建组件的插入式替换。重新分发项目的各方应该（a）重新分发您生成的二进制文件的未修改、签名版本，或者（b）重新分发二进制文件的修改版本，使用不同的密钥（他们自己的密钥）签名，或者（c）重新查找源代码。这些选项并不是相互排斥的。但重要的是，关键必须属于签约方，而不是项目。否则，正如Cameron指出的那样，签名的意义和价值将被破坏。我完全同意，但如果我对许可证的解释是正确的，那么它将违反/使LGPL库的使用变得不可能。但你为什么要签名呢？当密钥是私有的，但不是在“协议缓冲区”的情况下，我理解强命名程序集背后的原因。释放密钥似乎是一个非常糟糕的主意。谁代理版本号？如果BigCorp X部门的Joe下载ProtocolBuffers.sln，对其进行修改，并指定版本2.1.0.0，该怎么办。然后BigCorp部门的雪莉也做了同样的事情。两者都是有符号的、强名称的程序集，但它们是不同的？？这些人用自己的钥匙在修改过的程序集上签名有多难？如果BigCorp决定把事情搞砸，那么他们确实可以让自己的生活更艰难。如果不释放钥匙，每个人的生活都会变得更加艰难。我宁愿让大多数人的生活更轻松，允许人们偶尔射中自己的脚，也不愿意让其他人的生活更艰难。他们创造一个钥匙对来签署组装协议有多难？这是命令行上的一个额外步骤！而且只做过一次。曾经这对于ProtoBufs可能并不重要，但对于更普遍的东西（比如XML库），它会导致崩溃。围绕Java的Xerces库的Jar-H3LL是一个很好的教训。到处都有版本。你会有依赖于多个OSS项目的应用程序，每个应用程序都依赖于不同版本的Xerces。强命名（Java缺少）解决了这个问题。但是只有完整的强命名。@Cheeso：对于野田佳彦来说，我认为我们将拥有一个任何人都可以使用的密钥，然后是一个只有少数提交人可以访问的私钥。这样，默认情况下每个人都会得到一个签名程序集，