5

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

AFAIK这是完全错误的——一旦 .snk 文件被披露，任何人都可以生成一个程序集，该程序集可用于替换原始代码供应商提供但现在包含恶意代码的程序集。我想运送 .snk 文件的人不会认真对待这种风险，而只是运送文件，否则该项目将无法编译现成的。

除了“方便”之外，是否有任何理由发送 .snk 文件？

4

3 回答 3

3

一个非常有效的问题。就我而言，我 不发送 SNK 文件，但会提供说明如何自己制作并进行所需的更改（例如启用）。InternalsVisibleTo

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

于 2011-01-31T12:11:10.740 回答
2

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

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

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

于 2011-01-31T12:11:52.723 回答
1

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

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

于 2011-01-31T12:11:19.893 回答