<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I think your ideas are too jumpy.<br></div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">I agree that modules that require native access need to actively disclose their behavior.</div><div dir="ltr">I think it can be debated whether some form of authorization is required for native access, </div><div dir="ltr">and I am more inclined to agree.<br></div><div dir="ltr"><br></div><div dir="ltr">However, I am absolutely against enforcing encapsulation breaking and having to authorize with JVM options.<br></div><div dir="ltr">I don't think this has any positive meaning. Compared with the first two steps, it does not help security and</div><div dir="ltr">does not help users' right to know, but brings usability problems.</div><div dir="ltr"><br></div><div>Glavo</div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 29, 2023 at 7:05 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 27 Aug 2023, at 12:39, Remi Forax <<a href="mailto:forax@univ-mlv.fr" target="_blank">forax@univ-mlv.fr</a>> wrote:<br>
> <br>
> <br>
> I disagree.<br>
> 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.<br>
> 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.  <br>
> <br>
> Let's take an example, Netty [1], the server and all it's protocol/transport supports are using JNI.<br>
> 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.<br>
> <br>
> Why Java SE should consider the JDK code is more safe than the Netty code, given that both are using JNI ?<br>
> <br>
> 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 ?<br>
> <br>
> 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.<br>
<br>
<br>
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`.<br>
<br>
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.<br>
<br>
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?<br>
<br>
— Ron</blockquote></div>