JEP draft: Prepare to Restrict The Use of JNI

[Glavo]

I think your ideas are too jumpy.

I agree that modules that require native access need to actively disclose
their behavior.
I think it can be debated whether some form of authorization is required
for native access,
and I am more inclined to agree.

However, I am absolutely against enforcing encapsulation breaking and
having to authorize with JVM options.
I don't think this has any positive meaning. Compared with the first two
steps, it does not help security and
does not help users' right to know, but brings usability problems.

Glavo

On Tue, Aug 29, 2023 at 7:05 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 27 Aug 2023, at 12:39, Remi Forax <forax at univ-mlv.fr> wrote:
> >
> >
> > I disagree.
> > I do not like the fact that you are promoting the idea that the JDK code
> is not superior to other libraries of the ecosystem.
> > Also the Java ecosystem is massive so even if it is true that the
> majority of applications do not do native call apart the JNI calls of the
> JDK, there are a lot of middleware libraries that do native access, so
> there are a lot of applications built on top of those middlewares that do
> native access. Those applications are not unsafe.
> >
> > Let's take an example, Netty [1], the server and all it's
> protocol/transport supports are using JNI.
> > Netty acts as a middleware, encapsulating unsafe JNI calls in a safe
> way. For example, you can use OpenSSL for HTTPv2, something the JDK does
> not do.
> >
> > Why Java SE should consider the JDK code is more safe than the Netty
> code, given that both are using JNI ?
> >
> > Why the user of one Netty libraries or one of the libraries that is
> using Netty libraries (for example, a JDBC driver [2]) need to be aware
> that Netty is using JNI ?
> >
> > If you think that Java has an integrity problem, I would prefer a
> solution including the Java ecosystem than a strawman solution where the
> JDK is good and everything else is bad. And don't get me wrong, I have no
> problem with having more protection to the JDK code (note JDK) but, this is
> not what we are discussing here.
>
>
> What’s different about the JDK is not its use as a library, but the fact
> that when you run the `java` launcher, you are running an *executable*
> given to you by the JDK. The launcher distributed with the JDK knows about
> the JDK modules, so it gives them permission. If, rather than asking users
> to add a flag, a library wants to distribute a launcher that grants it
> permissions and ask users to use that launcher — as the JDK does — it can
> do so, and that’s ok. The user now knows they’re running a different
> program that possibly makes different guarantees than `java`.
>
> But the program called `java` wants to make certain guarantees to its
> users, and it can’t do that if any library can override any contract it may
> want to make. Changing the contract has to be visible to the user, either
> as a flag or as running a different launcher. It’s not that the code in the
> JDK is necessarily safer, but it’s included in the contract the JDK is
> trying to make. Thanks to modules and jlink, anyone else can make their own
> contracts for their own programs.
>
> Notice that without the integrity in the JDK *no one* can make any
> contacts. Suppose Alice authors a library, `foo`, that has some powerful
> invariants, while Bob writes a library `bar`, that uses JNI and,
> intentionally or not, can break `foo`’s invariants. Requiring an
> application author to enable native access to use `bar` could certainly
> inconvenience Bob, but not requiring it would inconvenience Alice.
> Someone’s “rights” will be reduced; the *only* decision we can make is:
> whose?
>
> — Ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230829/4c99c071/attachment.htm>