<div dir="ltr"><div>If I'm understanding you correctly, then this proposal wants to be able to allow native access to the jars of a particular vendor. That would be actually useful to us, because at the moment we have some jars using native libraries, and a problem with these libraries is that they are split into a lot of small jars (all making native calls), and not everyone uses the same subset of these jars. Though I might have to repackage them anyway (even though they are not managed by me), but if I didn't need to merge them into a single module that would be better. And since they are all accessing the same set of native libraries (they are just split into many small jars for whatever reason), it is not useful to give access to them separately.</div><div><br></div><div>However, why would we need a signature for this? If some of the jars are malicious, then we are screwed even with Java only. If they are not malicious then a simple manifest entry (or a combination of multiple) for the group seems enough. For example, it would be enough I think, if we could enable native access on the basis of some manifest entries, like writing `--enable-native-by-manifest="Vendor=MyCompany,Native-Libs=my-native-libs"` (where both "Vendor" and "Native-Libs" would be a key in the manifest).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Andrew Haley <<a href="mailto:aph-open@littlepinkcloud.com">aph-open@littlepinkcloud.com</a>> ezt írta (időpont: 2023. szept. 5., K, 14:59):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[ I have tried to read all the replies. I hope that I haven't missed anyone<br>
making this point. ]<br>
<br>
In the "Alternatives" section you write<br>
<br>
 > Rather than restrict the loading of native libraries and the binding<br>
 > of native methods, the JVM could apply access control rules when<br>
 > native code uses JNI functions to access Java fields and methods<br>
<br>
Java has facilities that allow code to be cryptographically signed.<br>
Could not the end user configure, by means of a local permissions<br>
file, a list of code signers they trust to use JNI? That seems (to me)<br>
to satisfy the requirement to obtain explicit approval from the end<br>
user or the application assembler. It also provides an alternative to<br>
a command-line flag, which I know to be inconvenient and annoying. It<br>
also allows installers, as well as end users, to control native<br>
access.<br>
<br>
- Was this idea considered?<br>
<br>
- Is this sort of configury what you meant by "apply access control<br>
   rules?"<br>
<br>
- Is thre anything wrong with this as an idea? We already have the<br>
   machinery to sign and verify code sources, and as far as I can see<br>
   it keeps the control in the hands of the user.<br>
<br>
- The The JDK itself is implicitly trusted to use JNI. Allowing<br>
   signed code to do the same gives the user the power to extend that<br>
   trust.<br>
<br>
On 8/21/23 13:41, Ron Pressler wrote:<br>
 ><br>
 > In the future, code that uses JNI will run only if unsafe native<br>
 > access is enabled, and to prepare for that future, JDK 22 should<br>
 > spotlight the use of JNI with warnings. We've published a draft JEP<br>
 > that explains why using JNI is unsafe and describes the warnings<br>
 > [3].<br>
<br>
-- <br>
Andrew Haley  (he/him)<br>
Java Platform Lead Engineer<br>
Red Hat UK Ltd. <<a href="https://www.redhat.com" rel="noreferrer" target="_blank">https://www.redhat.com</a>><br>
<a href="https://keybase.io/andrewhaley" rel="noreferrer" target="_blank">https://keybase.io/andrewhaley</a><br>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671<br>
<br>
<br>
</blockquote></div></div>