为什么我应该签署我的JAR文件？

我知道我需要签署我的客户端JAR文件（包含Applets），以便像文件系统访问这样的特殊事情可以完成，并且让窗口底部的恼人的位不显示，但为什么呢？我是否需要签署包含Servlets等的服务器端JAR文件？

一些关于何时何时不签名JAR的基本规则将不胜感激 – 谢谢！

简短的回答 – 不要，除非你的公司政策迫使你。

长的答案
签名jar子是有效地告诉你的客户：“我做到了这一点，我保证它不会搞乱你的系统，如果有的话，来找我报答。这就是为什么从远程服务器（applets / webstart）部署的客户端解决scheme中签名的jar比非签名解决scheme享有更高的权限。

在服务器端解决scheme中，您无需安抚JVM安全需求，这一保证仅仅是为了客户的安心。
关于签名jar子的坏处是它们比没有签名的jar子装载得慢。慢多less？它是受CPU限制的，但是我注意到加载时间增加了100％以上。此外，补丁更难（你必须重新签名的jar），类补丁是不可能的（一个包中的所有类必须具有相同的签名源），分裂jar变成一件杂事。更不用说你的构build过程更长，而且正确的证书花钱（自签是无用的）。

所以，除非你的公司政策强制你，不要在服务器端签名jar，并且保持签名和非签名版本的普通jar（签名转到客户端部署，非签名转到服务器端代码库）。

一个好的理由可能是，如果你从来不想让任何人能够潜入你的代码所调用的模类中。

不幸的是，包括你自己:-D所以这只是如果你真的需要它。检查“密封瓶”的概念。

在小程序方面：从6月10日开始，Sun JRE用较不显眼的（来自6u12，IIRC）警告三angular（用于支撑形状和透明窗口）replace警告标志。 6u10还允许通过JNLP服务API进行受控文件访问。

最小权限原则说，你不应该签署你的jar文件的类。安全不一定容易。

简单地显示一个证书对话框不应该被解释为意味着网页的全部内容是可信的。

对jar文件进行签名就像在其他上下文中使用证书一样，因此使用它的人知道它来自哪里。人们可能会相信Chris Carruthers不会写恶意代码，所以他们愿意让你的小程序访问他们的文件系统。签名给了他们一定的保证，这个jar子真的是你创造的，而不是由冒名顶替者或他们不信任的人创造的。

对于服务器端或库中的jar子，通常不需要为任何人提供这种保证。如果它是你的服务器，那么你知道你使用的是什么，以及它们来自哪里，而且你可能相信自己的代码不是恶意的。