.NET：可执行文件应该是强名称签名吗？私有DLL怎么样？

Question

我的应用程序包含三个程序集：一个引用几个DLL的EXE。这些DLL对我的应用程序是私有的 - 它们仅由此可执行文件使用。

这些集会是否应该有一个强有力的名字？

FxCop建议他们应该 - 对于它目前生成的所有程序集：

  

CA2210：签署＆lt; assembly＆gt;有一个强大的名字键。

但是，this advice说：

  

通常，您应该避免强命名应用程序EXE程序集。

和

  

您可能希望避免使用应用程序专用的强命名组件。

我应该给这些集会一个强有力的名字吗？在这种情况下这样做（或不这样做）有什么好处？

修改

看几个具有相似结构的应用程序，似乎没有就此问题达成共识。 Paint.NET和Crack.NET的二进制文件名称不强，而.NET Reflector和Snoop的二进制文件则不是。

有趣的是，使用Expression套件，Microsoft已采用后一种方法：例如，在Expression Blend中，他们选择对Blend.exe和随附的DLL（例如Microsoft.Expression.Blend.dll）进行强名称签名

似乎我不太可能在第一个问题上得到一个简单的答案：“我应该给这些集会一个强有力的名字吗？”。但是，我的第二个问题仍然存在：

在这种情况下，强名签名二进制文件是否有任何好处？或者，不这样做有什么好处吗？

编辑2：

如果无论如何都没有压倒性的理由，我倾向于给我的集会一个强有力的名字。因此，我对是否有人可以扩展这一点（从第一个链接）感兴趣：

“强命名可能会使管理依赖项变得更加困难，并为私有组件增加不必要的开销。”

Answer 1

正如我所看到的，在这种情况下，这些是强名签名的好处：

• 防止攻击者将DLL替换为使用其他密钥签名（或根本不签名）的DLL，而不替换EXE（因为EXE包含包含公钥的引用）。
• 防止攻击者在保留现有密钥的同时修改程序集（因为这会导致签名验证失败）。但请注意，从.NET 3.5 SP1开始，此情况下的签名验证为disabled by default。
• 可以阻止应用程序与不匹配的程序集版本一起运行 - 如果由于部署错误而错误地替换了DLL，则应用程序将无法加载它而不是尝试使用（可能不兼容的）错误版本。
• 避免FxCop警告。

签名的缺点（我相信这些是链接文章所指的）：

• 使用兼容的新版本替换DLL（例如，为了修复错误）需要替换EXE。
• 在.NET版本中＆lt; 3.5 SP1，强名称程序集由于签名验证而需要更长时间才能加载。
• 强名称DLL也需要更长时间才能加载，因为加载程序在查找本地之前执行（在这种情况下是徒劳的）搜索GAC。

选择是强命名（因此需要引用匹配精确密钥和精确版本），或者不强命名（并且不要求匹配），这似乎是一种耻辱。如果可能需要密钥而不是特定版本，也许可以获得签名的前2个好处，而不会产生第一个缺点。也许这可以通过应用强名称，然后使用app.config来处理版本问题？

Answer 2

强命名程序集仅确保版本兼容性。这与信任装配不是一回事。

换句话说，“强名称”仅指精确汇编二进制文件与编译时使用的版本号相结合。

如果你GAC那些程序集，那么CLR只会验证一次。当组装是gac'd时。这可以带来性能提升。但是，我的经验表明它很少。

强名称程序集可以替换为名称不强的程序集;这提出了关于强命名的部分，而不是任何类型的安全功能。

我个人认为，与他们相关的疼痛程度并不能证明他们的使用是正确的。痛苦是他们如何使用自动化测试工具。

https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5054496.html

Answer 3

签名程序集确保在编译后不会修改程序集。只要您是唯一的私钥所有者，任何人都无法使用您的密钥重新装配程序集。

当然，这不是绝对保护。黑客可以修改程序集并从所有程序集中删除强名称签名（和引用）。这些组件也可以工作。

但在这种情况下，您可以说您不会进行修改。

Answer 4

如果您对程序集进行签名，则任何引用的程序集都是公开公开的，它们也必须签名。否则你会有充分的理由得到编译错误。

我认为强大命名程序集的主要用途是将其纳入GAC。

我认为没有必要强烈命名一个exe。

只是我的2比索....