White-listing sensitive linker targets

[Alex Buckley]

On 6/2/2016 10:22 AM, Mike Samuel wrote:
> It sounds like the tech lead, specialists, and build master can
> exercise oversight using tools that just
>
> 1. look at the exports...to... relationships which should be apparent
> from module declarations in bytecode per
> http://openjdk.java.net/projects/jigsaw/spec/sotms/#qualified-exports

Yes, the qualified exports should drive everything, since they're 
bulletproof. (A module can choose to augment its own exports at run 
time, but hopefully the overseers recognize that more as a "feature" for 
Sally to use judiciously than as a "bug" which weakens the authority of 
the static white-list.)

> 2. check that sensitive packages are only contained in modules defined
> in build artifacts signed by the right group.

Yes, this is a job for the build system. The placement of packages in 
modules is something that the module system has to take on trust.

> What about JSR 223 style script engines?
> Can an embedder of an interpreter or bytecode compiler create a module
> that includes the scripting engine and just the stuff that the scripts
> need and be sure that, whether the script engine uses reflection under
> the hood, or compiles to bytecode?  Or does all that stuff tend to end
> up in the unnamed module?

The way that frameworks use the module system is a deep topic, but 
ultimately a JSR-223 ScriptEngineFactory is just a service provider, so 
you can create a module which 'provides' a class implementing 
ScriptEngineFactory and which 'requires' java.scripting + the other 
modules it needs. The module can't access anything which isn't exported 
to it, regardless of whether the access is from bytecode or via Core 
Reflection or via the Language Model or via MethodHandle lookup.

Alex