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
