强名称验证仅使用 public 密钥令牌？

Question

我做了以下经历：

现在，在 (1) 中，我假设这是正确的行为，因为两个文件的签名应该相同，为空，但在情况 (2) 中，public 令牌应该相同，但是签名应该不同，在控制台应用程序中签名应该被填充，而在dll中签名应该是空的，所以控制台应用程序应该不能调用dll。

这让我相信强名称验证只使用 public 密钥令牌，这是真的吗？

Answer 1

如果使用相同的 public 密钥，延迟的和完全签名的程序集的强名称是相同的。

这就是为什么在完全签署 dll 后不需要修改（通过重建）exe 中的引用的原因。

然而，延迟签名的程序集将不包含证明它是用私钥签名的签名（有充分的理由：它不是用私钥签名的）。

此签名不是全名的一部分，因此该程序集仍将与完全签名的程序集的全名相匹配。

默认行为是拒绝加载延迟签名的程序集。不是因为它的全名不匹配，而是因为程序集未通过签名验证。

如果您使用 sn.exe 关闭签名验证，将接受 dll 强名称而不检查匹配的签名。无论调用 dll 的 exe 是否完全签名，都会出现这种情况。

如果您没有使用 sn.exe 关闭验证，我希望 exe 根本不会运行。

如果您使用 sn.exe 关闭所有使用 public 键的程序集的验证，我希望 exe 到运行并毫无问题地调用 dll。这是通过使用：

sn.exe -Vr *,<publicKeyToken>

如果您仅使用 sn.exe 关闭了对 exe 的验证，同时让 dll 的验证处于活动状态，我希望 exe 可以运行但在尝试调用 dll 时失败。这是使用以下方法完成的：

sn.exe -Vr <dllAssemblyName>,<publicKeyToken>

为确保不跳过程序集验证，请使用：

sn.exe -Vx

或使用

sn.exe -Vu <dllAssemblyName>,<publicKeyToken>

使用与 -Vr 相同的语法有选择地打开验证。

同时有 32 位和 64 位 sn.exe。它们分别影响 32 位和 64 位进程。我建议始终运行在两者中使用 sn.exe 命令以避免意外。

Validation of strong names only uses public key token?