java 为什么要签署我的 JAR 文件？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/968565/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why should I sign my JAR files?
提问by Chris Carruthers
Why should I sign my JAR files?
为什么要签署我的 JAR 文件？
I know that I need to sign my client-side JAR files (containing Applets) so that special things like filesystem access can be done, and so that the annoying bit at the bottom of windows doesn't show, but why else? And do I need to sign my server-side JAR files containing Servlets, etc.?
我知道我需要对我的客户端 JAR 文件（包含小程序）进行签名，以便可以完成诸如文件系统访问之类的特殊操作，并且不会显示 Windows 底部令人讨厌的部分，但为什么呢？我是否需要对包含 Servlet 等的服务器端 JAR 文件进行签名？
Some basic rules for when and when not to sign JARs would be appreciated - thanks!
何时以及何时不签署 JAR 的一些基本规则将不胜感激 - 谢谢！
采纳答案by Ran Biron
The short answer - don't, unless your company policy forces you to.
简短的回答 - 不要，除非您的公司政策强迫您这样做。
The long answer
Signing jars is effectively telling your customer "I made this, and I guarantee it won't mess up your system. If it does, come to me for retribution". This is why signed jars in client-side solution deployed from remote servers (applets / webstart) enjoy higher privileges than non-signed solutions do.
长答案
Signing jars 有效地告诉您的客户“这是我做的，我保证它不会弄乱您的系统。如果是这样，请找我报复”。这就是为什么从远程服务器（applet/webstart）部署的客户端解决方案中的签名 jar 比非签名解决方案享有更高的特权。
On server-side solutions, where you don't have to to placate the JVM security demands, this guarantee is only for your customer peace of mind.
The bad thing about signed jars is that they load slower than unsigned jars. How much slower? it's CPU-bound, but I've noticed more than a 100% increase in loading time. Also, patches are harder (you have to re-sign the jar), class-patches are impossible (all classes in a single package must have the same signature source) and splitting jars becomes a chore. Not to mention your build process is longer, and that proper certificates cost money (self-signed is next to useless).
在服务器端解决方案上，您不必满足 JVM 安全需求，这种保证只是为了让您的客户安心。
签名 jar 的坏处是它们的加载速度比未签名 jar 慢。慢多少？它受 CPU 限制，但我注意到加载时间增加了 100% 以上。此外，补丁更难（您必须对 jar 重新签名），类补丁是不可能的（单个包中的所有类必须具有相同的签名源）并且拆分 jar 成为一件苦差事。更不用说您的构建过程更长，并且适当的证书需要花钱（自签名几乎没用）。
So, unless your company policy forces you to, don't sign jars on the server side, and keep common jars in signed and non-signed versions (signed go to the client-side deployment, non-signed go to server-side codebase).
因此，除非您的公司政策强制您这样做，否则不要在服务器端对 jar 进行签名，并将常见的 jar 保持在签名和非签名版本中（签名转到客户端部署，未签名转到服务器端代码库）。
回答by Thorbj?rn Ravn Andersen
A good reason could be if you never wanted anybody to be able to sneak in modfied classes to be called by your code.
一个很好的理由可能是，如果您从不希望任何人能够潜入修改后的类以供您的代码调用。
Unfortunately that includes yourself :-D So this is only to be done if you really need it. Check the "sealed jar" concept.
不幸的是，这包括你自己 :-D 所以这只有在你真的需要的时候才做。检查“密封罐”概念。
回答by Tom Hawtin - tackline
In terms of applets: From 6u10, the Sun JRE replace the warning banner with less obtrusive (from 6u12, IIRC) warning triangle (necessary to support shaped and transparent windows). 6u10 also allows controlled file access through the JNLP services API.
在小程序方面：从 6u10 开始，Sun JRE 将警告横幅替换为不那么突兀（来自 6u12，IIRC）警告三角形（必须支持异形和透明窗口）。6u10 还允许通过 JNLP 服务 API 进行受控文件访问。
The principle of least privilege says that you should not sign the classes of your jar files. Security is not necessarily easy.
最小权限原则说你不应该对你的 jar 文件的类进行签名。安全并不一定容易。
Simply showing a certificate dialog box should not be construed to mean that the entire contents of a web page is to be trusted.
仅显示证书对话框不应被解释为意味着可以信任网页的全部内容。
回答by super_aardvark
Signing a jar file, just like using certificates in other contexts, is done so that people using it know where it came from. People may trust that Chris Carruthers isn't going to write malicious code, and so they're willing to allow your applet access to their file system. The signature gives them some guarantee that the jar really was created by you, and not by an impostor or someone they don't trust.
签署一个 jar 文件，就像在其他上下文中使用证书一样，这样做是为了让使用它的人知道它来自哪里。人们可能相信 Chris Carruthers 不会编写恶意代码，因此他们愿意允许您的小程序访问他们的文件系统。签名为他们提供了一些保证，即罐子确实是由您创建的，而不是由冒名顶替者或他们不信任的人创建的。
In the case of server-side or library jars, there's usually no need to provide that kind of guarantee to anybody. If it's your server, then you know what jars you're using and where they came from, and you probably trust your own code not to be malicious.
在服务器端或库 jar 的情况下，通常不需要向任何人提供这种保证。如果它是您的服务器，那么您就知道您使用的是什么 jar 以及它们来自哪里，并且您可能相信自己的代码不是恶意的。
