request upstream libraries to split their jars #17
Description
Possible opportunities for splitting
- the Rhino jar bundles tools, REPL, debugger in it.
- h2 jar bundles a server with sql admin console in it!
- okhttp jar bundles the cache store inside it
If the upstream libraries separated out some of these functionalities in separate jars, it would help us (and others) in the following ways:
- reduction in surface-area of attacks
- more fine-grained sandboxing (see below)
- reduction in jar size
In the case that upstream developers refuse to split their jars we have the option to maintain a fork that provides the splits.
fine grained sandboxing
If functionality is broken down into separate jars, it allows us to assign different permissions to different components. For example, if the caching mechanism in okhttp is broken out into a separate jar, it could be given the file-access permission, while the networking component of okhttp can be given the network related permission (and no file access permission).
This is possible because Java's permission system is based on the notion of codesource. Every class has an associated codesource. The class loader specifies the codesource of a class whenever it loads a class. In the case of a class loaded from a jar, the typical value for codesource is the URL of the jar.