[External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Alex Buckley]

Java has been adding lots of features to simplify small applications 
written and maintained by one person: the single-file source launcher 
(multi-file coming soon...), more "batteries included" (e.g., the Class 
File API, the simple web server), and all the Amber features like sealed 
classes that make code self-documenting.

At the same time, we're concerned about large applications, sitting on 
top of hundreds of libraries, whose maintainers have no overlap with the 
authors. Adding strong encapsulation of JDK modules, and disabling 
dynamic agent attach and native access by default, aim to ensure that 
maintainers know what their application is doing, so they can better 
manage the risks of adopting a new JDK, new OS, new libraries, etc.

Alex

On 8/28/2023 12:16 PM, Constantin Christoph wrote:
> When I build a small application, I usually do not make a startup 
> script. Same goes with a lot of other developers, who just want their 
> software to work. Adding yet another switch to properly use java without 
> massive restrictions will force a lot of applications to rethink their 
> build process, potentially even rework it. All of this work for what, a 
> small sense of security for a topic that hasn't really caused any issues 
> for the past few years?
> 
> Constantin
> 
> Am Mo., 28. Aug. 2023 um 21:02 Uhr schrieb Alex Buckley 
> <alex.buckley at oracle.com <mailto:alex.buckley at oracle.com>>:
> 
>     Usage of JNI *or the foreign-function parts of the FFM API* will
>     require
>     the end user of a library to acknowledge that native code is going
>     to be
>     invoked.
> 
>     (The *foreign-memory parts of the FFM API* are not involved in this
>     discussion, and their ability to manage off-heap memory will supersede
>     many traditional uses of JNI and --enable-native-access.)
> 
>     Who is the end user of a library? It's an *application* which, in the
>     vast majority of cases, already has a startup script. What does the
>     startup script do today?
> 
>     - Choose a GC and (sometimes) set GC tuning parameters
>     - Set system properties to configure security protocols
>     - Use --add-opens/exports to acknowledge that third, fourth, fifth
>         party dependencies may try to use setAccessible to access
>         non-standard JDK internals which can change at any time --
>         that is, acknowledge risk from libraries which can prevent the
>         application being run on newer JDKs.
> 
>     To this list, we're proposing to add:
> 
>     - Use --enable-native-access to acknowledge that third, fourth,
>         fifth party dependencies may use JNI or parts of the FFM
>         API which, despite being standard features of the Java Platform,
>         are inherently dangerous -- that is, acknowledge risk from libraries
>         which can prevent the application running correctly.
> 
>     The risk from libraries using setAccessible on JDK internals is bad:
>     exceptions are thrown when the internals change, and applications which
>     ran on JDK 8 don't run on JDK 17. But the risk from libraries invoking
>     native code are potentially catastrophic: undefined behavior, silent
>     data corruption, JVM crashes. That's why we propose that the end user
>     (application assembler) must be aware of the risks.
> 
>     All the ideas about enabling native access *from inside the program* --
>     typically in a module declaration -- are missing the point. The
>     point is
>     to acknowledge risk *from outside the program*. Why? Because if a
>     module
>     could silently enable native access, then it will (just as it would if
>     it could silently perform an --add-opens), and users will be unaware of
>     the risks posed to the application they are using.
> 
>     Alex
> 
>     On 8/28/2023 10:01 AM, Constantin Christoph wrote:
>      > I am very aware of what is being changed here; I know that JNI will
>      > still be around, and be usable. However, the restrictions that
>     are going
>      > to be imposed on using it won't exactly make it easier to use, and
>      > require even more boilerplate setup for an end user to set up an
>     app or
>      > library. I know that launchers exist, and I know that the
>     manifest can
>      > also permit the usage of JNI, but if it would solve the issue, I
>      > wouldn't be here talking about it. The issue at hand is that the
>     usage
>      > of JNI in the future will require the end user of a library to
>     either
>      > make a startup script (which is not always the default procedure for
>      > smaller applications), or to add another entry to their manifest,
>     both
>      > options often require a bit of rethinking about how they should
>     build
>      > their project. It's not an easy solution, and it certainly makes
>     things
>      > more annoying if a library just wants to use some more advanced
>     features.
>      >
>      > Am Mo., 28. Aug. 2023 um 18:39 Uhr schrieb Brian Goetz
>      > <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>
>     <mailto:brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>>>:
>      >
>      >     I think you have a serious misunderstanding of what is being
>     proposed
>      >     here.  Nobody is taking away JNI.  What is being taken away
>     is the
>      >     ability to bury the use of JNI in a library where the user is
>      >     unaware of
>      >     it.  By "user" here, I mean the person putting together a Java
>      >     application from a group of modules and JARs -- sometimes
>     called the
>      >     "application assembler."  This user has a right to know what
>     their
>      >     application is doing.
>      >
>      >     When we started to enforce the accessibility model in Java 9,
>     we didn't
>      >     take away the ability to do deep reflection, we took away the
>      >     ability to
>      >     do so _without the user knowing_.  The reason that the various
>      >     `--add-opens` are specified on the command line is so that
>     the user has
>      >     a chance to consent to relaxed integrity.  JNI is the same;
>     we're not
>      >     taking it away, but we're helping the user be aware of when a
>      >     library is
>      >     putting the integrity of the application at risk, so that
>     they have the
>      >     ability to make a judgement call on whether they are willing
>     to trust
>      >     that library.
>      >
>      >
>      >     On 8/28/2023 11:37 AM, Constantin Christoph wrote:
>      >      >
>      >      > JNI is a fundamental part of the java ecosystem, and it
>     shouldn't be
>      >      > restricted in a manner like this. It's a powerful, useful
>     tool, and
>      >      > should be treated like that. Developers should have that
>     option
>      >     freely
>      >      > available.
>      >
>