Bug ID: JDK-6874884 Provide a way to sign jars as single blob

Type: Enhancement
Component: security-libs
Sub-Component: java.security
Affected Version: 6

Priority: P4
Status: Resolved
Resolution: Won't Fix
OS: generic
CPU: generic

Submitted: 2009-08-22
Updated: 2024-04-12
Resolved: 2015-02-12

Total size of MANIFEST and .SF file from FX runtime is 200k compressed and 500k uncompressed
because it contains signatures for several thousands classes.

On other hand everything is actually signed by single signer and we validate everything at the same time.
So, there is no real need to have thousands of signatures if we can find a way to sign and validate 
this jar as one large blob.
Considering FX runtime as an example jar - 2600 entries, 4.3Mb jar, 1.2Mb jar.pack.gz.

  Overhead of MANIFEST.MF and TEST.SF:
     A. Unjared - 510k (need to parse 500k of text on startup)
     B. jar - 170k, jar.pack.gz - 170k too (this is download overhead, in case of pack200 it is 15% overhead and translates directly to download time)

Note that many real world enterprise apps contain even large number of classes. It is not problem specific to FX runtime.

We won't do that now.
12-02-2015
EVALUATION Priority from 2 to 4. Will not sign jar as single blob or change jar spec for JDK 7. Might consider enhancing jar parsing codes, say, read and verify SF file as a stream.
23-11-2010
EVALUATION Plugin (at least plugin1) already has support for jarjar. Just search the workspace for 'jarjar'. I wonder if this already support this kind of signing? From what I remember jarjar was originally put in to give better compression to deployed apps. Jar the first jar with 0 compression, then jar it with better compression. This results in a smaller jar to deploy, and therefore download. We already do something similar with the fx runtime by gzipping the jars, but maybe we could replace this with jarjar if it gives us a more efficient way of signing.
15-09-2009
EVALUATION One possibility is to wrap this jar by other signed jar file. Or we can use some other version of package. Note that we should only return such jar for clients who are running JRE that knows how to deal with them. For this we can introduce new mime type and modify servlet to return this special type of package if client confirms it can handle this mimetype. This will ensure compatibility with older JRE versions.
22-08-2009