Re: [External] : Re: JEP 411, removal of finalizers, a path forward.

2021-08-02 Thread Peter Firmstone
Just thought I'd share some thoughts around a couple of statements in JEP 411: *|java.security.{AccessController, AccessControlContext, AccessControlException, DomainCombiner}|* — The primary APIs for the access controller, which is the default implementation to which the Security Ma

Re: [External] : Re: JEP 411, removal of finalizers, a path forward.

2021-08-02 Thread Peter Firmstone
Thanks Ron, What we do now is dynamic, so we need to figure out how to replicate that post SM.  Things we don't grant dynamically are good candidates for command line argument options. We basically authenticate, then authorize class loading dynamically at runtime, along with other things, su

Re: JEP 411, removal of finalizers, a path forward.

2021-08-02 Thread Peter Firmstone
Hello Andrew, Loss of SM is a significant threat to my software, if left unresolved. Your interpretations are your own, I make no apologies for your interpretation.  I am describing the difficulties that I am experiencing with JEP 411 migration and how it applies to my situation, it appears t

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

2021-08-02 Thread David Holmes
On 3/08/2021 2:25 am, Igor Ignatyev wrote: On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: Hi all, could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? the majority of the patch is the

[jdk17] Integrated: 8067223: [TESTBUG] Rename Whitebox API package

2021-08-02 Thread Igor Ignatyev
On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev wrote: > Hi all, > > could you please review this big tedious and trivial(-ish) patch which moves > `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? > > the majority of the patch is the following substitutions: > - `s~s

RFR: 8271566: DSA signature length value is not accurate in P11Signature

2021-08-02 Thread Martin Balao
As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Plea

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

2021-08-02 Thread Igor Ignatyev
On Mon, 2 Aug 2021 15:56:39 GMT, Vladimir Kozlov wrote: > I agree with these revised changes for JDK 17. Thanks for your review, Vladimir. I'll rerun my testing before integrating (just for good luck). -- Igor - PR: https://git.openjdk.java.net/jdk17/pull/290

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v3]

2021-08-02 Thread Igor Ignatyev
> Hi all, > > could you please review this big tedious and trivial(-ish) patch which moves > `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? > > the majority of the patch is the following substitutions: > - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` > - `s

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

2021-08-02 Thread Igor Ignatyev
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves >> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >>

Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]

2021-08-02 Thread Vladimir Kozlov
On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev wrote: >> Hi all, >> >> could you please review this big tedious and trivial(-ish) patch which moves >> `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package? >> >> the majority of the patch is the following substitutions: >>

Re: JEP 411, removal of finalizers, a path forward.

2021-08-02 Thread Andrew Dinn
On 02/08/2021 11:33, Peter Firmstone wrote: I think you may be misinterpreting my comment, let me clarify: Really? I'd suggest only if you stretch the meaning of your words beyond their elastic limit. I'm assuming that during the process of removal of security manager, any external ports or

Re: JEP 411, removal of finalizers, a path forward.

2021-08-02 Thread Andrew Haley
On 8/2/21 8:49 AM, Peter Firmstone wrote: > If I fix that bug, will JEP 411 be cancelled? No. The problem wasn't that we couldn't fix the [Speculative Execution Vulnerabilities], more that any fix would be so invasive and pervasive that it would severely hamper the whole platform. -- Andrew Hale

Re: JEP 411, removal of finalizers, a path forward.

2021-08-02 Thread Peter Firmstone
Hello Andrew, I think you may be misinterpreting my comment, let me clarify: I'm assuming that during the process of removal of security manager, any external ports or process hooks that we can only turn off now by not granting a permission will be replaced by a command line property or somet

Re: JEP 411, removal of finalizers, a path forward.

2021-08-02 Thread Andrew Dinn
On 01/08/2021 15:28, Uwe Schindler wrote: I'm working on the assumption that OpenJDK will close any external holes currently defended by permission checks. It would be good if the JDK was secure by default, with properties required to be set for allowing such things as agents, management, parsin

Re: JEP 411, removal of finalizers, a path forward.

2021-08-02 Thread Peter Firmstone
Thanks Florian, 1. If I fix that bug, will JEP 411 be cancelled?   BTW. Sparc isn't vulnerable. 2. My primary use case is for SM is for authorization decisions for remote users and services. JSR-121: Java Application Isolation API Specification. http://apt.cs.manchester.ac.uk/intranet/cso