2

假设我想发布一个开源类库。我想知道我是否应该用它发布 snk。例如，我确实想要一个 snk 来使 dll GAC 友好。我见过有公开 snk (NHibernate) 和未公开的项目 (DevExpress) 的大项目，以及双方的小项目，所以没有普遍的协议，这是肯定的。

假设我不发布私钥。这个库的用户本身就是开发人员，如果他们想要进行任何更改，要么需要重新编译我的源代码，要么对强名称验证进行例外处理。既是脖子痛，我也去过。

假设我发布它。我看不到如何利用它。CAS 和其他东西不再广泛使用，更重要的是，它甚至在 .NET 4.5 中已被弃用。所以这不像是可怜的用户根据它的公钥令牌授予我的程序集一些权利，而坏人用相同的令牌产生一个错误的程序集。如果一个坏人可以将他自己的 dll 放在某人的计算机上，那么阻止他们的并不是强大的名称。

我认为没有人会检查程序集的公钥令牌。当然，运行时会检查它自引用程序集编译后是否未更改，但仅此而已。发布者不发布他们的代币，所以据我所知，我可能会在编译我的代币时首先引用一个错误的程序集。

所以我倾向于发布snk。在我看来，它在理论上提供的安全性很小，在实践中没有安全性，所以为什么要让我的用户的生活更加艰难。也许我应该进行 X.509 代码签名（使用真正私钥的代码签名），但我认为大多数人也不会检查。

发表还是不发表？最好的论点获胜。理论方面，实践方面，MS™ 指南，都欢迎。

4

2 回答 2

4

我不会发布它。

它将允许攻击者重新编译程序集，向其中添加恶意代码。更改后的程序集将与您的程序集具有相同的强名称。

如果您不发布密钥，则可以分发库的“受信任”二进制文件和没有密钥的源代码。如果第 3 方开发人员需要自定义库，他们只需为其生成一个新密钥（但生成的程序集将具有与官方版本不同的强名称，允许运行时区分两者）。

于 2012-05-28T16:01:50.470 回答
1

您不应该分发强命名密钥，但这与安全性几乎没有关系。

强命名是一种识别技术，而不是一种安全措施。它仅用于防止意外的装配身份冲突。（为了使其足够强大以供“严肃”的安全使用，它需要可撤销的密钥而不是自行生成的密钥。）

但是，防止意外碰撞是不在开源项目上分发签名密钥的充分理由。这是防止您的版本 1.2.3.4 看起来与其他人从修改的源代码编译的版本 1.2.3.4 相同的主要因素。鉴于为项目开放源代码的主要目标之一通常是允许人们分发从更改的代码编译的程序集，有人甚至可能会争辩说，适当的个性化强命名对于开源项目比对于一个开源项目更重要。闭源分发。

于 2012-06-04T13:39:22.010 回答