Java 7 清单安全更改 [英] Java 7 Manifest Security Changes

问题描述

随着 Java 7s 安全检查的最新变化，我正在更新我们的 webstart 应用程序，以允许它在没有警告的情况下运行.

我们的 webstart 应用程序由许多 jar 文件组成，其中只有少数是我们开发的，我们使用了许多 3rd 方 jar 文件(log4j，swingx，...)

我们之前的设置使用了自签名证书，我们用它对所有 jar 文件进行了签名.我们现在已经从适当的 CA 购买了签名证书.

到目前为止我采取的步骤是:

• 解压jar文件
• 从所有 jar 文件中去除旧证书(从清单中删除 *.DSA *.SF *.RSA 和哈希值)
• 重新打包jar文件
• 向包含我们的主类的 jar 文件添加权限、代码库、应用程序名称属性.
• 使用新密钥对 jar 文件进行签名

在带有 Java 7 u45 的机器上的 webstart 中运行它不会给出警告对话框，这很好.

但是，查看 java 控制台，我看到它警告其他 jar 文件的所有 jar 缺少权限、代码库、应用程序名称属性.我还应该将这些属性添加到每个 jar 文件中吗?

我已经对重新打包 3rd 方 jar 文件感到不安，但现在不得不添加清单属性也让我觉得我错过了一些东西.

那么，是更改清单还是其他什么?谢谢，圣诞快乐

感谢您提供有用的回复，我只是想用我实施的解决方案的一些细节来更新它.

我采取以下步骤重新打包应用程序所需的每个 jar 文件.- 将 jar 文件解压到一个临时目录
- 从 META-INF
中删除 *.DSA *.RSA *.SF- 从 META-INF/MANIFEST.MF 中删除以
开头的行- SHA-256-摘要
- SHA1-摘要
- 权限
- 代码库
- 应用程序名称
- 将行插入 META-INF/MANIFEST.MF
- 权限:所有权限
- 代码库:*
- 应用程序名称:我的应用程序名称
- 确保 MANIFEST.MF 中的所有行结尾都适合我的系统 (dos2unix)
- 使用指定的新清单重新创建 jar 文件
- 使用当前的代码签名证书对 jar 文件进行签名

希望有帮助

解决方案

是的，需要添加Permission、Codebase和Application-Name 应用程序使用的每个 .jar 的清单属性.这是主应用程序 .jar 以及所有 3rd 方库 .jar.

请参阅此答案 https://stackoverflow.com/a/19659135/963076 到另一个 SO 问题.>

你感到不安是件好事.据我了解，向 3rd 方库的清单中添加内容违反了几乎所有库所附的 GNU 许可协议.我一直在摸不着头脑，因为 Oracle 一直在发布关于他们的想法的这些更新.为什么第 3 方库需要指定 JNLP 代码库?他们知道他们在强迫我们违反这些 3rd 方图书馆的许可协议吗?

但是，唉，如果您希望这些警告消失，并且更希望您的应用程序在未来的 Java 更新中工作，那么您必须这样做.事实是，如果您使用像 Netbeans 这样的 IDE，那么它已经在重新打包和重新签名您的第 3 方库 .jars 反正.因此，您不会违反 IDE 尚未违反的任何规则.

With recent changes to Java 7s security checks, I'm updating our webstart application to allow it to run without warnings.

Our webstart application consists of a number of jar files, only a few of which are developed by us, we use a number of 3rd party jar files (log4j, swingx, ...)

Our previous setup used a self signed certificate, with which we signed all jar files. We have now purchased a signing certificate from a proper CA.

The steps I've taken so far are:

• Unpack the jar files
• Strip out old certificates (remove *.DSA *.SF *.RSA and hashes from the manifest) from all jar files
• Re-package jar files
• Add Permission, Codebase, Application-Name attributes to the jar file which contains our main class.
• Sign jar files with the new key

Running this in webstart on a machine with Java 7 u45 gives no warning dialog, which is great.

However, looking in the java console, I see that it is warning about missing Permission, Codebase, Application-Name attributes for all jar of the other jar files. Should I also be adding these attributes to every jar file?

I'm already uneasy with repackaging 3rd party jar files, but now having to add manifest attributes too makes me feel I've missed something.

So, change manifests, or something else? Thanks, and Merry Christmas

Edit: Thanks for the useful responses, I just wanted to update this with some details of the solution I have implemented.

I take the following steps to repackage each jar file required by the application. - Unpack the jar file to a temporary directory
- Remove *.DSA *.RSA *.SF from META-INF
- Remove lines from META-INF/MANIFEST.MF which start with
- SHA-256-Digest
- SHA1-Digest
- Permissions
- Codebase
- Application-Name
- Insert lines into META-INF/MANIFEST.MF
- Permissions: all-permissions
- Codebase: *
- Application-Name: MY APP NAME
- Ensure all line endings in MANIFEST.MF are appropriate for my system (dos2unix)
- Recreate the jar file with the new manifest specified
- Sign the jar file with the current code signing certificate

Hope that helps

解决方案

Yes, you need to add the Permission, Codebase, and Application-Name manifest attributes to every .jar used by your app. This is the main app .jar plus all the 3rd party library .jars as well.

See this answer https://stackoverflow.com/a/19659135/963076 to another SO question.

It is good that you feel uneasy. As I understand it, adding things to the manifests of 3rd party libraries is a violation of the GNU license agreements attached to almost all libraries. I have been scratching my head as Oracle has been releasing these updates as to what they were thinking. Why should a 3rd party library need to designate a JNLP Codebase? Do they know they're forcing us to violate the license agreements of these 3rd party libraries?

But, alas, if you want those warnings to go away and, even more, want your app to work in future Java updates, you must. The truth is, if you use an IDE like Netbeans then it is already repackaging and resigning your 3rd party library .jars anyways. So you won't be breaking any rules your IDE isn't breaking already.

这篇关于Java 7 清单安全更改的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！