说我想发布一个开源类库。我想知道是否应该用它发布snk。我确实想要一个snk来使dll GAC友好。例如。我见过大型项目有公共snk（NHibernate）和未公开的（DevExpress），以及双方的小项目，所以没有普遍的协议，这是肯定的。
假设我没有发布私钥。此库的用户（他们自己是开发人员）要么需要重新编译我的源，如果他们想要进行任何更改，要么对强名称验证进行例外处理。颈部疼痛，我一直在那里。
假设我发布了它。我没有看到如何利用它。 CAS和东西不再广泛使用，而且甚至在.NET 4.5中也被弃用了。因此，不像穷人用户基于其公钥令牌授予我的程序集一些权限，而坏人用相同的令牌产生犯规程序集。如果一个坏人可以将自己的dll放在某人的计算机上，那么它真的不是强大的名字会阻止他们。
我认为没有人会检查程序集的公钥令牌。当然，运行时检查自引用程序集编译后它没有更改，但这就是全部。出版商不会发布他们的令牌，所以据我所知，我可能会在编译我的时候首先引用一个犯规集。
所以我倾向于发布snk。在我看来它在理论上提供的安全性很小，在实践中没有安全性，所以为什么让我的用户的生活更难。也许我应该进行X.509代码签名（一个真正的私有私钥），但我认为大多数人都不会检查它。
要发布还是不发布？最好的争论胜利。理论方面，实践方面，MS™指南，都欢迎。
答案 0 :(得分：4)
我不会发布它。
它将允许攻击者重新编译程序集，向其中添加恶意代码。更改的程序集将具有与您相同的强名称。
如果您不发布密钥，则可以在不使用密钥的情况下分发库的“可信”二进制文件和源代码。如果第三方开发人员需要自定义库，他们只需要为它生成一个新密钥（但是生成的程序集将具有与正式版本不同的强名称，允许运行时区分这两者）。
答案 1 :(得分：1)
您不应该分发强有力的命名密钥，但这与安全性几乎没有关系。
强命名是一种识别技术，而不是安全措施。它旨在防止意外的装配身份碰撞。 （因为它足够强大，可以“严肃”使用安全性，它需要可以使用可重新启动的密钥而不是自生密钥。）
但是，防止意外冲突是不在开源项目上分发签名密钥的充分理由。这是阻止您的1.2.3.4版本与其他人修改后的源代码编译的1.2.3.4相同的主要内容。鉴于为项目打开源代码的主要目标之一通常是允许人们分发从改变的代码编译的程序集，人们甚至可能会争辩说，正确的个性化强命名对于一个人而言是非常重要的。开源项目比闭源分发。