【发布时间】：2020-06-10 10:06:30
【问题描述】：
我为什么要签署我的 JAR 文件？
我知道我需要对我的客户端 JAR 文件（包含 Applet）进行签名，以便可以完成文件系统访问等特殊操作，并且不会显示窗口底部令人讨厌的部分，但为什么会这样?我是否需要对包含 Servlet 等的服务器端 JAR 文件进行签名？
一些关于何时和何时不签署 JAR 的基本规则将不胜感激 - 谢谢！
【问题讨论】：
标签： java jar signed-applet
【发布时间】：2020-06-10 10:06:30
【问题描述】：
简短的回答 - 不要，除非您的公司政策强迫您这样做。
长答案
签署 jars 有效地告诉您的客户“我做了这个，我保证它不会弄乱你的系统。如果是这样，来找我报仇”。这就是为什么从远程服务器（applet / webstart）部署的客户端解决方案中签名的 jar 比未签名的解决方案享有更高的特权。
在服务器端解决方案上，您无需安抚 JVM 安全需求，此保证只是为了让您的客户高枕无忧。
签名 jar 的坏处是它们的加载速度比未签名的 jar 慢。慢多少？它受 CPU 限制，但我注意到加载时间增加了 100% 以上。此外，补丁更难（您必须重新签名 jar），类补丁是不可能的（单个包中的所有类必须具有相同的签名源），并且拆分 jar 成为一件苦差事。更不用说您的构建过程更长，而且正确的证书需要花钱（自签名几乎没用）。
因此，除非您的公司政策强制您这样做，否则不要在服务器端对 jar 进行签名，并将常用 jar 保存在已签名和未签名版本中（已签名转到客户端部署，未签名转到服务器-side 代码库）。
【讨论】：
-
为什么它受 CPU 限制？我认为检查 CRL 是一项在线操作，很大程度上取决于 Internet 连接速度，可能主要关注那里的延迟。
-
当您加载一个签名的 jar 文件时，会发生一个称为“验证”的过程。签名和验证都是昂贵的，因为必须执行加密算法才能执行操作，无论它是什么。但是：与不签名/不验证相关的成本很高。我的意思是：根据具体情况，经过的时间可能是问题，也可能不是问题。
-
这是非常糟糕的建议。
-
@PopKernel 哇。使死人复活的方法。我原来的答案是几乎 10 岁。但是......为什么这是一个“可怕的，可怕的建议”？老实说，在过去的 7 年里，我一直远离 jar 签名的世界，所以我不知道可能发生的任何进展或问题。但是，我的回答所依据的基本前提似乎仍然有效。
-
@RanBiron 这些天几乎零签署了 jar 文件。如果你至少在 Mac 上，你必须通过多个对话框来解除 Gatekeeper 的武装，才能打开一个罐子。此外，未签名的 jars 更有可能是 phishbait，甚至可能在下载过程中被恶意攻击者重写。它还破坏了 Java Web Start，这可能会让某处的甲骨文高管非常难过。
如果您不希望任何人能够潜入修改后的类以由您的代码调用，这可能是一个很好的理由。
不幸的是，包括你自己 :-D 所以只有在你真的需要时才这样做。检查“密封罐”的概念。
【讨论】：
签署一个 jar 文件，就像在其他上下文中使用证书一样，这样做是为了让使用它的人知道它来自哪里。人们可能相信 Chris Carruthers 不会编写恶意代码，因此他们愿意允许您的小程序访问他们的文件系统。签名让他们可以保证罐子确实是由您创建的，而不是由冒名顶替者或他们不信任的人创建的。
对于服务器端或库 jar，通常不需要向任何人提供这种保证。如果它是您的服务器，那么您就知道您正在使用什么 jar 以及它们来自哪里，并且您可能相信自己的代码不是恶意的。
【讨论】：
在小程序方面：从 6u10 开始，Sun JRE 将警告横幅替换为不那么显眼的（从 6u12 开始，IIRC）警告三角形（支持成形和透明窗口所必需的）。 6u10 还允许通过 JNLP 服务 API 访问受控文件。
最小权限原则说你不应该签署你的 jar 文件的类。安全不一定容易。
不应将仅显示证书对话框解释为意味着网页的全部内容都是可信的。
【讨论】：