Exporting - the wrong default?

[Eric Johnson]

There's so much to tackle on this thread...

On 8/2/16 5:47 AM, Stephen Colebourne wrote:
> IMO, we need to get existing OSS libraries migrated to modules ASAP to
> maintain the ecosystem, which requires the migration to be really
> simple. Get this wrong, and we'll all just carry on using the
> classpath, and the last 5+ years of effort in the JDK will have little
> value.
Indeed. Commercial vendors will have the same problem. And to the extent 
that we use open source libraries, we may need to fork said libraries. 
In working with OSGi, my company has had enormous issues with getting 
the metadata right for libraries - nothing obviously wrong with the 
code, but the metadata is a royal pain. It doesn't appear to transfer 
between platforms seamlessly. Potentially a huge cost with JDK 9 
modularization.

At the same time, I work on security issues. I want security by default. 
So I want both sides of this question to get the answer they want. Nasty 
conundrum we've found ourselves in.

One part of the split is simple - modules are a (presumably) useful 
compile time constraint. Giving Java the ability to hide public classes 
simply because the author didn't really want to expose them, but the 
language constraints didn't give them a choice, that seems like an 
improvement. This is not a security problem, just a language problem.

Bring module enforcement into the runtime, and it is now a security 
problem. All security problems are trade-offs. For one step, (as I've 
mentioned before) I'd really like someone to point at some security 
analysis document that goes through the threat model analysis (or its 
equivalent), so we can have a deeper discussion than "default to secure" 
as the only answer. Off the top of my head, I cannot think of any 
threats to something like Eclipse, which has already embraced the OSGi 
form of modularization. How will Jigsaw modularization enforcement at 
runtime can actually make Eclipse safer? I don't think it will. On the 
server side - much different question.

On the server side, without deep analysis, I suspect the default to 
enforce module boundaries makes sense. However, we also know, up front, 
that such a step will break things. To fix that breakage, will mean lots 
of changes to code, made by a lot of people, not all with lots of 
experience, across a lot of libraries. In other words, an opportunity to 
accidentally introduce new security bugs while trying to work within a 
new security framework. Again, wanting a threat model analysis, because 
helping those developers cross the chasm should be part of the threat 
equation that we're trying to solve.

So we really want a place where people can start using modules at 
compile time, and choose to opt into module boundary enforcement at 
runtime. I suspect it is probably an OK starting position if the JRE 
itself always benefits from boundary enforcement. But everything else - 
not sure that's a good idea, as it will blow-up the Java ecosystem.

Two possibilities - either a flag for the Java runtime to enforce module 
boundaries (default off?), or let individual modules choose whether they 
opt-in. Actually, both might be useful.

With the opt-in on a module basis, the open source project that needs to 
produce a module can produce one quickly, and opt-out of boundary 
enforcement. No source code changes besides module declarations, so 
minimal risk. That way, those developers can avoid all the hacking on 
code and changes that might be necessary by flipping to strict 
enforcement immediately. Over time, downstream users of those open 
source projects will be able to test those libraries by flipping a 
switch, and enforcing module boundaries for a given module, then testing 
to see if that caused problems. They can then go back to the open source 
project with definitive information, gleaned from actual use, about what 
is necessary to opt-in to full enforcement.

As for flags on the runtime, it might be good to have a flag which 
defaults to off. Other settings would be "warn", and "strict". SELinux, 
which seems closely analogous to this problem, has a similar model of 
"warn" vs. "enforce". So perhaps a good pattern to follow?

Eric