有什么理由将 .snk 文件与项目源一起发送?

发布于 2024-10-14 20:26:07 字数 360 浏览 1 评论 0 原文

我时不时地在网络上看到一个示例项目,其中包含一个 .snk 文件,用于使用强名称对编译结果进行签名。

据我所知 这是完全错误的< /a> - 一旦 .snk 文件被公开,任何人都可以生成一个程序集,该程序集可用于替换由原始代码供应商提供但现在包含恶意代码的程序集。我认为发送 .snk 文件的人不会认真对待这种风险,只是发送该文件,因为否则该项目将无法编译现成的。

除了“方便”之外,还有什么理由传送 .snk 文件吗?

Every now and then I see a sample project on the network which contains a .snk file used for signing the compilation results with a strong name.

AFAIK this is plain wrong - once a .snk file is disclosed anyone can produce an assembly that can be used to replace an assembly shipped by the original code supplier but now containing malicious code. I suppose that people shipping .snk files don't treat that risk seriously and just ship the file because otherwise the project wouldn't compile off-the-shelf.

Is there any reason for shipping the .snk file except that "convenience"?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

一身软味 2024-10-21 20:26:07

这是一个非常有效的问题。我代表我的 部分 不提供 SNK 文件,但提供说明如何自行生成并进行所需的更改(例如启用 InternalsVisibleTo)。

我认为目前的做法已经推动了我的微软从VS2005开始对SNK处理的改变。使用密钥容器需要使用未记录的 MSBUILD 项 KeyContainerName 手动编辑 CSPROJ 文件...VS 的默认设置是将 SNK 复制到项目目录中,这很方便,但恕我直言是错误的。

A very valid question. I for my part do not ship the SNK file but do provide instructions how to produce one yourself and make the required changes (to enable InternalsVisibleTo for instance).

I think that the current practice has been pushed my Microsoft with the changes in the SNK handling starting with VS2005. Using a key container requires a manual edit of the CSPROJ file with an undocumented MSBUILD item KeyContainerName... the default of VS is to copy the SNK into the project directory, which is convenient but wrong IMHO.

三岁铭 2024-10-21 20:26:07

我能想到的唯一原因是允许对您的 dll 进行直接替换...

当然,通常我会说“如果您想要直接替换,请不要签署您的 dll”。但如果它安装在 GAC 中,签名是先决条件。 (或者是,我上次知道)。

因此允许替换安装在GAC 中的dll。这是我能想到的唯一合理的理由...

The only reason I can think of, is to allow a drop-in replacement for your dll...

Of course, normally I'd say "don't sign your dll if you want drop-in replacements." but if it's installed in the GAC signing is a pre-requisite. (or was, last time I knew).

So allowing replacements for your dll that is installed in the GAC. Is the only rational reason I can think of...

才能让你更想念 2024-10-21 20:26:07

至少,我看不出有什么理由将私钥和公钥对一起发送。如果您需要发送源代码,您也可以使用 .pfx,它通过您需要签署程序集的密码提高了安全性。

无论如何,将 .snk 文件添加到源代码管理似乎是许多开源项目中的常见做法(不好的做法)。这是一个非常好的问题!

At least, I can't see a reason to ship both, the private and the public keypair together. If you need to ship source code you could alternatively use a .pfx which has improved security through the password you'll need to sign the assembly.

Anyhow, it seems to be common practice (bad practice) in a lot of open source projects to add the .snk file to the source control. So a very good question!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文