管理开源项目的强名称密钥对的推荐方法是什么？
我管理一个开源项目，并希望对项目二进制包中发布的二进制文件进行签名。我使用 Visual Studio csproj 和 sln 文件来管理和构建我的项目，并将这些文件作为项目源包的一部分进行分发。
如何对我的构建生成的二进制文件进行签名，而不必分发 snk 密钥对文件？如果我使用 Visual Studio 对程序集进行签名，则每个项目文件现在都需要密钥对的副本才能进行构建。即使密钥对受密码保护，我也不愿意分发密钥对。
编辑：
另一个需要注意的是，项目中的某些程序集通过 InternalsVisibleToAttribute 授予友元访问权限，并通过项目引用构建这些友元。因此，此类程序集在引用签名程序集时需要使用强名称。但是，如果密钥对没有分发，那么最终用户如何构建源代码并维护项目关系？如果使用临时密钥对文件，签名程序集的公钥令牌是否会更改，从而破坏 InternalsVisibleToAttribute 引用？
I manage an open-source project and would like to sign the binaries that are released in the project's binary package. I use Visual Studio csproj and sln files to manage and build my project, and also distribute these files as part of the project's source packages.
How can I sign the produced binaries of my build and not have to distribute the snk key-pair file? If I use Visual Studio to sign the assemblies, each project file now needs a copy of the key-pair in order to build. I'm not comfortable with distributing the key-pair, even if it is password protected.
Edit:
Another caveat is that some assemblies in the project grant friend access via InternalsVisibleToAttribute, and build those friends via a project reference. Consequently, such assemblies need to use a strong name when referring to a signed assembly. However, if the key-pair is not distributed then how can end-users build the sources and maintain the project relationships? If a temporary key-pair file is used, won't the public key token of the signed assemblies change, breaking the InternalsVisibleToAttribute references?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是一个老问题，但目前得票最高的答案并不准确，所以我认为值得发布一个新答案。
对于开源项目，Microsoft 建议将您的私钥签入您的存储库。这是安全的，因为强名称密钥用于身份识别，而不是安全性。
请参阅此处以供参考：https://learn。 microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies
他们还专门针对开源项目：
如果您希望程序集安全，那么您应该考虑Authenticode签名：https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/
This is an old question, but the currently highest-voted answer is not accurate, so I figured it's worth posting a new answer.
For open source projects, Microsoft recommends checking in your private key into your repository. This is safe because strong name keys are used for identity, not security.
See here for reference: https://learn.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies
They also specifically address open source projects:
If you want security for your assemblies, then you should look into Authenticode signing: https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/
您不应该分发密钥对。强名称用于验证新版本的程序集是否来自同一发布者。
如果另一个开发人员想要分支您的项目，他们将生成自己的密钥对，这将有效地表明他们的版本不是来自您，这样依赖于您的其他程序集将不会再加载，除非重新编译它们。这并不总是很方便，但它可以保护您免受有人发布恶意版本的程序集并悄悄分发它的影响。
You should not distribute the keypair. The strongname is for verifying that the new version of assembly comes from the same publisher.
If another developer wants to branch your project they will generate their own keypair and that will effectively show that their version is not from you so that other assemblies that depend on yours will not load anymore unless they are recompiled. That's not always convenient but it protects you from someone issuing a malicious version of assembly and silently distributing it.
如果代码中唯一的程序集引用是项目文件中编码的程序集引用，Sharptooth 的解决方案 效果很好。如果您的项目通过 InternalsVisibleToAttribute 或其他需要强名称字符串的方式引用其他程序集，则使用临时密钥构建存储库源是不可行的。这样做将更改强名称字符串中存在的公钥引用并破坏代码。
我的应用程序就是这种情况，因此我需要采用不同的方法。
我基本上在单独的文件夹层次结构中创建了 sln 和 csproj 文件的副本，并按如下方式修改了 csproj 文件。
InternalsVisibleToAttribute的使用。csproj文件，使snk文件引用是相对路径（无需将snk文件复制到每个项目）我首先所有这些都是手动完成的，但后来意识到这可以以一种简单的方式自动化。第一个和第三个步骤可以用XSLT来实现，而第二个步骤可以用正则表达式搜索/替换功能来实现。
由于我现在需要维护两个解决方案，因此自动化此任务以避免将来出现问题是有意义的。
存储库中的源代码不会构建具有强名称的程序集，这很好，因为我不想对最终用户施加任何构建限制或过程。
Sharptooth's solution works well if the only assembly references in the code are those encoded in the project files. If your project refers to other assemblies via
InternalsVisibleToAttributeor other means where a strong-name string is required, then it is not feasible to build the repository-sources with a temporary key. Doing so will change the public key references that are present in the strong-name strings and break the code.This is the case in my application so I needed to adopt a different approach.
I basically created a copy of the
slnandcsprojfiles in a separate folder heirarchy and modified thecsprojfiles as follows.InternalsVisibleToAttributewith a strong name.csprojfile so that thesnkfile reference is a relative path (removes the need to copy thesnkfile to each project)I first did all of this manually, but then realized that this can be automated in a straightforward manner. The first and third steps may be implemented with an XSLT, where as the second step can be implemented with a regex search/replace function.
Since I need to maintain two solutions now, it makes sense to automate this task to avoid future headaches.
The sources in the repository do not build assemblies with strong-names, which is fine, since I wouldn't want to impose any build restrictions or processes on end-users.