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

[Glavo]

>
> No, there’s some misunderstanding here. The “end user” from the
> perspective of the JDK is the application author/maintainer. It is not the
> end user of the Java *application*.
>

Of course I know this, because you have said it many times.
When I said that I hope to declare relevant information in the module
information of the main module, Alex replied like this:

The main module is not the user. The user is the person who develops,
> maintains, or otherwise "owns" the application. The main module is part
> of the application. The point of the JEP is to let the user, outside the
> application, acknowledge the risk arising from use of JNI inside the
> application (whether in the main module or six levels down).
>

My question is why should we distinguish between the author of the main
module and the packager of the program?
Is such an identity completely independent of developers really meaningful?

If the other methods were restricted but not JNI, those libraries will use
> JNI for that purpose.
>

This reason would lead me to believe it if the same restrictions were not
imposed on Panama.
I support more restrictions on JNI to move users to Panama, but I would
like Panama to be available without JVM options.

I'm not saying there should be no restrictions at all. For features like
this that is really needed by people, I wish it could be managed more
finely.
This is what I want (3rd repetition):

1. Allows a module to declare that it wants native access:
>
> ```java
>
> module org.glavo.mylib {
>     requires native; // Check for permissions when loading
>
>     // or
>     requires static native;  // Check for permission when calling a
> restricted method
>
> }
>
> 2. Allows a module with native access enabled to grant permissions to
> other modules:
>
> ```java
>
> module org.glavo.myapp {
>     requires native;
>     requires org.glavo.mylib;
>
>     opens native to org.glavo.mylib;
>
> }
>
>
> 3. If the main module requires native access, it is allowed without the
> --enable-native-access.
>
> 4. Allows users to declare restricted methods.
>     This will prevent code from masking its true intent through low-level
> libraries like JNA/JNR.
>
>
I think future I/O should be limited in a similar way, since users can use
it to break integrity as well.
For example, using /proc/pid/mem can bypass the restriction and write
directly to memory.

I know you have some descriptions in the "future work", but you are now
preparing to modify the default behavior of the program.
Even just printing a warning is not harmless, it is urging the user to go
somewhere.
So please don't let them be "future work", they should be "dependencies".

-cp is a flag (even with ‘lib/*’), and the same work done to automate the
> classpath could be applied to this flag as well.
>

In theory, build tools could do this, but they haven't done so yet. It
sounds like you want the Java community to do this?
Then I must remind you that if it is not the OpenJDK team but the Java
community that does this, then the future development direction will not be
in your control.
As I said in another email, this will cause irreparable damage to the
integrity.

I like --add-opens the way it is now because it gives everyone enough
negative feedback to keep people away from it.
But if the community does this, the vigilance effect of --add-opens will be
greatly reduced, and more people may no longer think that breaking module
encapsulation is a super power.
Therefore, I hope that FFI, I/O, these superpowers that people really need,
should not be treated in the same way.

Glavo


On Sun, Sep 3, 2023 at 1:48 AM Ron Pressler <ron.pressler at oracle.com> wrote:

>
>
> > On 2 Sep 2023, at 14:51, Michał Kłeczek <michal at kleczek.org> wrote:
> >
> >
> > 1. I was talking about social issues - seem to me they would be the same
> if you tried to enforce SecurityManager
>
> The social aspect is certainly one of the most interesting and challenging
> parts, and the main reason why we’re moving so cautiously.
>
> > 2. I am not convinced that it really works as well as advertised by
> OpenJDK team. For example: you ignored my question about dynamically loaded
> modules - how are they handled by these command line flags?
>
> That's in the JEP.
>
> — Ron
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230904/0a22547e/attachment.htm>