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

[Attila Kelemen]

What I meant by "by chance" is that whoever signed the library didn't
really consider that it would be used for such a purpose. I'm not saying it
is bad to use it for that, but that granting access based on manifest
entries could be more flexible, because if it is a very large company, then
I don't really want to auto trust everything, but rather I might want to
trust in a subgroup of that company.

Andrew Haley <aph-open at littlepinkcloud.com> ezt írta (időpont: 2023. szept.
9., Szo, 10:39):

> On 9/8/23 20:51, Attila Kelemen wrote:
> >      > In fact, it might even tells you more, because if not any
> manifest entry can be used, then you could tell from the presence of the
> manifest entry that people considered that these properties will be used
> for access rights (unlike signatures, because all libraries in Maven
> central are signed).
> >
> >     I can't understand the meaning of this sentence.
> >
> >     It's not necessary to trust the Maven central signature.
> >
> >
> > Basically I just meant that having a signature is a pretty low bar
> (because 100% of the libs in Maven Central have it). I'm not trying to
> imply that you thought it is a high bar, just wanted to clarify, if someone
> considered that a bonus. And that having manifest entries specifically
> added for the purpose of granting native access based on them is a higher
> bar, because it requires more conscious consideration from the library.
> That is, it is not just there by chance like a signature.
>
> The point of a signature is that you have enough knowledge of a
> particular signer to me happy the library will be good. The user
> chooses which signatures to trust. The user can, themself, also
> sign some libraries. There is no "just there by chance".
>
> --
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230909/4c029cbe/attachment.htm>