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

[Constantin Christoph]

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>:

> 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>>:
> >
> >     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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230828/2f2b0482/attachment.htm>