On 07/27/2016 10:26 AM, Remi Forax wrote:
----- Mail original -----
De: "dalibor topic" <dalibor.to...@oracle.com>
À: jigsaw-dev@openjdk.java.net
Envoyé: Mercredi 27 Juillet 2016 14:39:05
Objet: Re: Exporting - the wrong default?
On 26.07.2016 18:42, Stephen Colebourne wrote:
In many projects
packages change names frequently during development, everything is
open and locking stuff down is the last thing on peoples minds. While
this of course leads to slightly less secure software, it does achieve
*business value*.
I would recommend Cristina Cifuentes presentation "Are We Ready for
Secure Languages?" from the recent Curry On conference, of which a
recording is available at https://www.youtube.com/watch?v=-fC975HLhyc
for some less anecdotal thoughts on the business value of slightly more
secure software.
It even touches briefly on the utility of modules in JDK 9.
Interesting talk !
to get back to our issue,
there are 4 possibilities when exporting a package, for a public type,
(1) don't see it at compile time, don't see it at runtime (can't reflect on it)
(2) don't see it at compile time, see it at runtime (this is the OSGI/JBoss
model for not exported)
(3) see it at compile time, may not exist at runtime (so be prepared to get an
exception then)
(4) see it at compile time and see it at runtime
The default can not be (3) because it's a corner case, it can not be (4)
because in that case we lost the 'strong encapsulation' that a module should
provide by default, so the default can be either (1), either (2) or to force
the user to choose between (1) and (2) when declaring a module.
The problem with (1) is that:
- it makes most of the code that use reflection not working (and as Stephen
said, at lot of codes use reflection (or bytecode generation)),
- it will slow down the adoption of jigsaw (not jdk9 which will be run with a
-classpth) but the modularization of the already existing jars, so we will end
up with a module system which will be not used or worst, some jars will be
modularized, some will not and we will be in the same sad state of Python now
with 2 mostly compatible worlds *.
The problem of letting users to choose is that the hope to educate them by
forcing them to make their own choices will be destroyed because in practice
IDEs will chose for them (e.printStackTrace() anyone ?)
So the only valid choice seem to be (2), which
- still enable JDK and application server implementation modules to not export
some types at runtime, so the security will improve and by example, it will
avoid most of the access control bugs Christina talk about.
- the default behavior will make the move to convert their jars to modularized
jars easier because people will not conflate the problem of the modularization
itself with the problem of the access control at runtime.
- everybody will be happy and we will not see angry ponies on slides about Java
9.
This is all rearranging deck chairs. The critical problem here, lest we
forget, is that none of these solutions allow reflection to work on
modules without an export, even for public types, thus breaking
*everything* eventually. Any valid choice IMO must allow public types
to remain public and thus globally accessible.
Since everyone seems to concede that the migration to any more secure
form for users must be incremental, there is nothing left to be gained
by the existing Jigsaw public access restriction. After all, even if
public is left as public, it is still possible meet any reasonable
standard of encapsulation. That aforementioned incremental migration
could be for users and JDK developers to change public classes to be
non-public; the mechanism which currently allows for exporting packages
to modules is conceptually *very* close to a mechanism to share the
non-public classes in packages with modules.
In other words, users should be able to export packages with a module
target or a wildcard (which allows compile-time and run-time linkage to
connect to those packages), and also specify whether each (non-wildcard)
export should include access to private types (which allows that linkage
to connect types to those non-public members).
In addition to my aforementioned --safe-mode idea, I think it could also
be possible/easy to provide a facility for modules to be marked such
that using setAccessible from that module would be disallowed.
Would this not solve every problem and use case raised thus far, as well
as being far more intuitive for users?
--
- DML
