不签署 .NET 程序集有什么问题吗？

Anything wrong with NOT signing a .NET assembly?

提问by oscarkuo

One of my colleagues is very keen on signing assemblies. He literally tries to sign anything. Even when we use assemblies from Microsoft that are not signed, he will take the source code, sign it and then ask other developers to use his copy instead.

我的一位同事非常热衷于签署程序集。他真的试图签署任何东西。即使我们使用 Microsoft 未签名的程序集，他也会获取源代码，对其进行签名，然后要求其他开发人员使用他的副本。

I can understand the basic idea behind signing an assembly: to ensure a particular assembly is not compromised by some dodgy hacker. So if we are a software development company, we should sign our assembly before releasing some .NET library to our customers.

我可以理解签署程序集背后的基本思想：确保特定程序集不会被某些狡猾的黑客破坏。所以如果我们是一家软件开发公司，我们应该在向我们的客户发布一些 .NET 库之前签署我们的程序集。

However, we primarily develop web applications for our own use here, and I just can't see the point of signing every single assembly we use.

但是，我们在这里主要开发供我们自己使用的 Web 应用程序，我看不出对我们使用的每个程序集进行签名的意义。

Am I missing something here?

我在这里错过了什么吗？

采纳答案by Drew Noakes

Signing assemblies that are used within a trusted environment sounds like overkill to me.

对在受信任环境中使用的程序集进行签名对我来说听起来有些矫枉过正。

An interesting point on signed assemblies is that they are slightly slower to load than unsigned assemblies, as they must be cryptographically verified.

签名程序集的一个有趣之处在于它们的加载速度比未签名程序集稍慢，因为它们必须经过加密验证。

In order to sign an assembly, any assemblies it depends upon must also be signed. My guess is that this contributes to your colleague's desire to sign everything -- the compiler is demanding it.

为了对程序集进行签名，它所依赖的任何程序集也必须进行签名。我的猜测是，这会导致您的同事希望签署所有内容——编译器要求这样做。

---

---

EDITSince writing this answer you can see both the pro and against camp have roughly equivalent support. There clearly isn't a right answer here.

编辑自从写了这个答案，你可以看到赞成和反对阵营的支持大致相同。这里显然没有正确答案。

The point that compelled this edit though is that nowadays we take so many open source libraries from NuGet, and many of them are not signed at all. If you wanted to sign your assembly, you'd need to have any dependencies signed too. Many of the open source libraries that are signed have the private keys used for signing publicly available in their source repositories.

不过，迫使进行此编辑的一点是，如今我们从 NuGet 中获取了如此多的开源库，而且其中许多根本没有签名。如果您想对程序集进行签名，则还需要对所有依赖项进行签名。许多已签名的开源库都有用于签名的私钥，这些私钥在其源代码库中公开可用。

As with everything there are trade-offs to be made. In my experience of working in private environments, the benefits of signing are mostly theoretical (or academic, as @user289100mentions), unless you're concerned about government agencies modifying your code in which case you need to be paranoid about so many levels of your infrastructure that signing would seem like a small amount of effort. Otherwise the amount of challenges that cascade out of having to sign everything just don't seem worth it. However your environment may have different requirements, or you may be a masochist!

与所有事情一样，需要进行权衡。根据我在私人环境中工作的经验，签名的好处主要是理论性的（或学术性的，如@user289100 所述），除非您担心政府机构修改您的代码，在这种情况下，您需要对这么多级别的您的基础设施签署似乎是一个小小的努力。否则，由于必须签署所有内容而产生的大量挑战似乎不值得。但是，您的环境可能有不同的要求，或者您可能是受虐狂！

See also Teun D's answerfor information on challenges related to versioning assemblies when using strong names.

有关使用强名称时与版本控制程序集相关的挑战的信息，另请参阅Teun D 的回答。

回答by user289100

I've taken advantage of non-signed assemblies to get around issues before and in academic settings shown people why it's important. I replaced a DLL file that was unsigned (again in an academic setting) with one I made with the same name, same signatures, and used .NET Reflectorto copy and paste the original code, but in mine I emailed user names and passwords that were being passed in before calling 'real' code.

我已经利用非签名程序集来解决之前和在学术环境中向人们展示为什么它很重要的问题。我将一个未签名的 DLL 文件（再次在学术环境中）替换为我制作的具有相同名称、相同签名的 DLL 文件，并使用.NET Reflector复制和粘贴原始代码，但在我的文件中，我通过电子邮件发送了用户名和密码在调用“真实”代码之前被传入。

If signed, you can make a signature match, but not replace. Contrary to what Zippy says, there will be a run-time compliation error.

如果签名，您可以进行签名匹配，但不能替换。与 Zippy 所说的相反，会出现运行时编译错误。

Signing assemblies is never overkill. It takes 30 seconds. It's like saying locking your doors is overkill if you live in the country. If you want to gamble with your belongings, go ahead, leave it open. It only takes one security breach to get fired. It only takes 30 seconds to sign an assembly and there's no business case not to. The performance impacts is negligable.

签署程序集永远不会矫枉过正。需要 30 秒。这就像说如果你住在乡下，锁门是多余的。如果你想用你的财物赌博，那就去吧，让它敞开着。只需要一次安全漏洞就可以被解雇。只需 30 秒即可签署程序集，并且没有不这样做的商业案例。性能影响可以忽略不计。

回答by Teun D

One additional point: signing your assemblies breaks backward compatibility over versions. Your references all start to include version numbers and versions with other version numbers are considered non-compatible. This hinders upgrading to newer versions of distributed assemblies.

另外一点：对程序集进行签名会破坏版本之间的向后兼容性。您的参考文献都开始包含版本号，并且与其他版本号的版本被认为是不兼容的。这会阻碍升级到较新版本的分布式程序集。

In my opinion, you should only code-sign assemblies if you see some concrete gain from it:

在我看来，如果您从中看到一些具体的收益，您应该只对程序集进行代码签名：

• if you deploy to environments where untrusted people might touch your assemblies
• in certain plug-in models, where you want to use the certificate as evidence for upgrading the trust
• if your code should be callable from other signed code (a project like, say log4net, justifiably signs their code to be widely usable; they messed up hugely in compatibility by losing their secret key a few years ago, another risk of code-signing).
• if you want to deploy to the GAC

• 如果您部署到不受信任的人可能会接触您的程序集的环境
• 在某些插件模型中，您希望使用证书作为升级信任的证据
• 如果你的代码应该可以从其他签名代码中调用（比如 log4net 之类的项目，有理由对他们的代码进行签名以使其广泛使用；几年前他们丢失了他们的秘密密钥，这在兼容性方面造成了巨大的混乱，这是代码签名的另一个风险） .
• 如果你想部署到 GAC

回答by Dan Davies Brackett

Has your colleague given you any indications as to whyhe likes to sign assemblies? One advantage to signing that hasn't been discussed here yet is that only signed assemblies can be put in the GAC (i.e. be shared across managed processes), but the downsides do seem to outweigh the upsides from my (admittedly inexperienced) perspective.

你的同事有没有告诉你他为什么喜欢签署集会？此处尚未讨论的签名的一个优点是，只能将签名的程序集放入 GAC（即跨托管进程共享），但从我（诚然缺乏经验）的角度来看，缺点似乎确实超过了优点。

Your anecdote about self-signing Microsoft code seems particularly suspect to me. If MS didn't sign the code, there's probably a reason, right? And by signing it, you're taking responsibility for it when you didn't write it - another opportunity for the future to bite you.

你关于自签名微软代码的轶事对我来说似乎特别可疑。如果 MS 没有签署代码，那可能是有原因的，对吧？通过签署它，当你没有写它时，你就要对它负责——这是未来咬你的另一个机会。

回答by Marcin Deptu?a

Another thing about signing an assembly is, that one can't inject incorrect one in place of yours (also - yourself by an accident). In example, if you create a program that refers to an assembly Foo.dll, version 1.0, someone can create the an assembly, with the same version, and replace yours, when you sign your library, it won't be possible (at least I don't think it's easily possible).

关于签署程序集的另一件事是，不能注入不正确的程序集来代替您的程序集（也 - 您自己意外）。例如，如果您创建一个引用程序集 Foo.dll 版本 1.0 的程序，则有人可以创建一个程序集，使用相同版本并替换您的程序集，当您对库进行签名时，这是不可能的（在至少我不认为这很容易）。

回答by ZippyV

Signatures are only necessary if the assemblies are placed in the GAC, nothing else. Signed assemblies do not prevent someone to mess with them. A hacker can still strip of the signature and any other code that checks for the signature.

仅当程序集放置在 GAC 中时才需要签名，没有其他要求。已签名的程序集不会阻止某人与它们混淆。黑客仍然可以剥离签名和任何其他检查签名的代码。

回答by Steve Wortham

I agree it seems like a bit of a waste. It's really needed to ensure the file is what you think it is (and hasn't been tampered with). But if you trust the confines of your own network security and web server, then signing your web assemblies seems like a redundant step.

我同意这似乎有点浪费。确实需要确保文件是您认为的那样（并且没有被篡改）。但是，如果您信任自己的网络安全和 Web 服务器的范围，那么对 Web 程序集进行签名似乎是多余的步骤。

But maybe that's my small-business experience talking. If you're talking about a mission-critical online banking website, then sign away.

但也许这就是我的小企业经验。如果您正在谈论一个关键任务在线银行网站，那么请退出。

回答by Mark Simpson

Think about doing it if you're going to ship something and/or actually have a reason to do it. In every other case, it's just hassle. I'd ask your workmate what he actually gets out of doing this.

如果您要发货和/或实际上有理由这样做，请考虑这样做。在所有其他情况下，这只是麻烦。我会问你的同事他从这样做中得到了什么。

I've encountered signed assembly-itis before and it's a pain in the posterior, especially when you consider the amount of people who have little to no knowledge of signing assemblies, what it's for and how to do it. It's just another thing you shouldn't have to concern yourself with unless absolutely necessary.

我以前遇到过签名程序集炎，这是一种痛苦，尤其是当您考虑到对签名程序集知之甚少或一无所知的人数，它的用途以及如何执行时。除非绝对必要，否则您不必担心这件事。

回答by goodguys_activate

You need to sign your assembly when it's used in a deploy-from-the-web ClickOnceXBAP.

在从网络部署ClickOnce XBAP 中使用程序集时，您需要对程序集进行签名。

In addition, all referenced assemblies will need to be signed as well.

此外，所有引用的程序集也需要签名。

回答by Clay Lenhart

We sign our assemblies because there are times when we get errors like the following (this one is from testing, but can occur when running the application):

我们签署我们的程序集是因为有时我们会遇到如下错误（这个来自测试，但在运行应用程序时可能会发生）：

System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

TearDown : System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

We'd found that Visual Studio gets it wrongsometimes and runs old code.

我们发现Visual Studio有时会出错并运行旧代码。

If you want an error if you are running old code, then sign your assemblies.

如果您在运行旧代码时想要出错，请对您的程序集进行签名。

If you are writing a nugetpackage, please sign your assemblies. Unsigned assemblies is awkward for us who want to make sure we're running the latest version of our code. I can't fix Visual Studio. All I can do is detect that Visual Studio got it wrong. So please, sign your nuget assemblies.

如果您正在编写nuget包，请签署您的程序集。对于想要确保运行最新版本代码的我们来说，未签名的程序集很尴尬。 我无法修复 Visual Studio。我所能做的就是检测到 Visual Studio 出错了。所以请签署您的 nuget 程序集。