Code signing [Was: JEP draft: Prepare to Restrict The Use of JNI]

[Andrew Haley]

On 9/6/23 09:33, Ron Pressler wrote:
 > Second, the question is not one of trust.

I think that depends on how narrowly you define "trust". In this
context, by "trusted" I mean trusted not to be clumsy, not just
trusted not to be hostile. Often in conversations around Java, "trust"
is narrowly interpreted to mean only non-hostile.

 > Every application needs to decide whether it wants to be in a mode
 > where those invariants that the JDK wants to maintain hold, or
 > whether certain libraries may change which of those invariants hold.

But as well as the application assembler you also say

 > Restricting the use of JNI means that the user will have to enable
 > native access on the command line.

and

 > all JDK features that are capable of breaking integrity must obtain
 > explicit approval from the end user or the application assembler.

There is an emphasis on "let the user decide". I'm proposing an
additional way for the user to express what they have decided.

 > In concrete terms, every application decides whether it runs in a
 > mode where JNI can be used or not. The assumption is that all code
 > you run is trusted to be benevolent (in terms of security,
 > benevolent code is actually far more dangerous than untrusted,
 > potentially malevolent, code because the latter is easy to deal with
 > — except maybe when it comes to supply chain attacks — but I’m
 > digressing).

Again, I am not only concerned about benevolence but also competence.

 > My question is this: We’ve heard from a few people that configuring
 > the JDK is difficult for them (or perhaps they think it may be
 > difficult for others).

I've also heard, from several customers, that changing startup scripts
can be difficult. I was surprised, but is seems to be common. From my
own experience, it's a pain to have to edit run configurations in an
IDE every time.

 > What you’re proposing seems to be simply a different kind of
 > configuration. Are you trying to address the configuration
 > difficulty issue or something else? If it’s something else, what is
 > it?

Two things. Firstly, per-library-author (or per-library) approval.
That is to say, I'm happy to allow Project X, which handles
e.g. offline authentication, for all of my applications. Signing
provides a way to extend the fine-grained --enable-native-access= to
non-modular libraries. Secondly, once I have authorized a library I
never want to hear about that library again.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671