Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 7/05/2021 1:17 pm, Peter Firmstone wrote: On 6/05/2021 9:46 pm, Ron Pressler wrote: That is correct. Here is where this is mentioned for ForkJoinPool: https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/ForkJoinPool.html And here it is for virtual threads (the JavaDoc is still a WIP): https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Thread.html#startVirtualThread(java.lang.Runnable) Can I use doPrivileged blocks with context, or will they be innefective? If yes to the former and no to the latter, then it's great these threads have no permission by default. Just trying to work out if I can use it with secure network connections? -- Regards, Peter
Re: JEP411: Missing use-case: Monitoring / restricting libraries
What would help in future: 1. Define a core Java api, a javadoc annotation? If parts of it are deprecated, they will not be removed for eg 3 LTS releases, pick a number, it provides certainty. Developers writing new software then know if they use this api, they will not be harmed by breaking changes for x years. 2. Removal of api from java.* or javax.* are breaking changes. This is worse than a library breakage, as we can write a compatibility layer for a library. In my own software I provide a compatibility library for older versions of software written for Jini, it just decorates old api over new as a compatibility layer. For example we could write a compatibility layer for AccessController and doPrivileged methods, so they still work, without shotgun surgery. but we can't do that because it's in Java package namespace. 3. An annotation will let us know that we can write programs, without risk of incurring potentially significant technical debt. 4. Sun always gave us plenty of time to remove usages of deprecated methods, it always took years to clean these up, but there are compiler warnings etc. My point is, we always got them removed eventually, meanwhile we were also able to take advantage of new features. If OpenJDK does that, then I personally would continue use of Java for new projects. OpenJDK is not doing anything to ease the pain of migration, when you could do better. I'm curious, what are other developers using instead of Subject.doAs, JAAS and AccessController.doPrivileged to authenticate TLS connections? In JGDMS I found: 916 matches of AccessController in 264 files, and that's excluding tests. 515 matches of AccessControlContext in 121 files, again excluding tests. It appears to me that stack walking, which you singled out as a performance problem (it isn't), is likely causing difficulties for another project you're working on, which is why you are strongly motivated to see it removed. This isn't like other API's that are being removed, so far we have only been impacted in parts of our codebase. This will inflict pain on many projects, I just can't see people upgrading their software. Who's going to pay for all the hours of programming to convert perfectly good running code to a new api, just to upgrade to a newer version of Java? Just can't see it happening. -- Regards, Peter On 8/05/2021 8:42 am, Ron Pressler wrote: Many of the people who worked at Sun still work at Oracle on Java today, and that group includes all the people who signed their names on this JEP, but Java today has ten more years of baggage to maintain than it did back then. The speed at which things are removed after deprecation is meant to be proportionate to their level of use. I believe that, despite the fact that some less used things are, indeed, being removed now while they weren’t before, Java still compares favourable with many other languages/platforms as far as stability and compatibility is concerned. I think that saying that “move fast and break things” is the new philosophy is not only unfair, but very, very far from the truth. — Ron On 7 May 2021, at 23:20, Peter Firmstone wrote: On 8/05/2021 4:21 am, Ron Pressler wrote: Deprecation/removal JEPs, and this one is no exception, make the following claim: that the total good a certain JDK capability currently contributes to the Java ecosystem at large does not justify the cost of its maintenance, and it should, therefore, be removed — gradually, of course, and with enough time for users to find alternatives. An argument against such a JEP would take the form of, no, the total good the feature contributes to the ecosystem does justify its cost. Sun Microsystems would deprecate, but were very slow to remove API that caused breakages, they were also very considerate about how they would modify api in a backward compatible manner. OpenJDK has already demonstrated it removes api very quickly after deprecation. OpenJDK has adopted the move quickly and break things philosophy. I really like the new language features under development, but the continual breakages are causing me to rethink. I still haven't worked out how to replace some of the more recently removed features, we are still building on Java 8, because of missing components in Java 11, although we use features from and test on later versions. We haven't been testing on Java 8, because our default ciphers target the most recent versions and we disable anything less by default. Other breaking changes that have been removed can be replaced by library code, but cause breakages since we are unable to use the java.* package namespace. It would be friendlier, if OpenJDK allowed libraries to be developed separately, using the java.* namespace, perhaps as part of the project. This core platform feature that will be removed, probably after Java 17, but before the following long term support
Re: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
On Fri, 7 May 2021 12:01:16 GMT, Alexey Bakhtin wrote:
>> Hello All,
>>
>> Could you please review the fix for the JDK-8241248?
>> The issue happens during the TLSv1.3 handshake without server stateless
>> session resumption in case of server receives several parallel requests with
>> the same pre_shared_key.
>> The main idea of the fix is to remove resuming session from the session
>> cache in the early stage.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8241248
>> Webrev 8u: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/
>>
>> The test from the bug report using OpenSSL is passed (
>> -Djdk.tls.server.enableSessionTicketExtension=false )
>> javax/net/ssl and sun/security/ssl jtreg tests passed
>>
>> Regards
>> Alexey
>
> Alexey Bakhtin has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add Cache.pull method
Thank you for take my comments. The code looks nice to me, except a few
trivial comments.
src/java.base/share/classes/sun/security/ssl/PreSharedKeyExtension.java line
377:
> 375: // If we are keeping state, see if the identity is
> in the cache
> 376: if (requestedId.identity.length ==
> SessionId.MAX_LENGTH) {
> 377: s = sessionCache.pull(requestedId.identity);
Would you please add a comment here so as we know why a pull method could be
used here? For example:
-// If we are keeping state, see if the identity is in the
cache
+// If we are keeping state, see if the identity is in the
+// cache. Note that for TLS 1.3, we would also clean
+// up the cached session if it is not rejoinable.
src/java.base/share/classes/sun/security/ssl/SSLSessionContextImpl.java line
183:
> 181: if (id != null)
> 182: return sessionCache.pull(new SessionId(id));
> 183: return null;
As this is an internal method, it should be safe to assume that the id is
non-null. I'm fine if you want to keep the non-null check, but please use
braces for if-statement (see also
https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#449).
src/java.base/share/classes/sun/security/util/Cache.java line 430:
> 428: return null;
> 429: }
> 430: V value;
I may add a blank line before this line.
src/java.base/share/classes/sun/security/util/Cache.java line 442:
> 440: entry.invalidate();
> 441: return value;
> 442: }
I may adjust the lines a little bit so as to avoid duplicated operations (see
the implementation code of isValid()).
long time = (lifetime == 0) ? 0 : System.currentTimeMillis();
if (entry.isValid(time)) {
V value = entry.getValue();
entry.invalidate();
return value;
} else {
if (DEBUG) {
System.out.println("Ignoring expired entry");
}
return null;
}
-
PR: https://git.openjdk.java.net/jdk/pull/3664
Re: JEP411: Missing use-case: Monitoring / restricting libraries
Many of the people who worked at Sun still work at Oracle on Java today, and that group includes all the people who signed their names on this JEP, but Java today has ten more years of baggage to maintain than it did back then. The speed at which things are removed after deprecation is meant to be proportionate to their level of use. I believe that, despite the fact that some less used things are, indeed, being removed now while they weren’t before, Java still compares favourable with many other languages/platforms as far as stability and compatibility is concerned. I think that saying that “move fast and break things” is the new philosophy is not only unfair, but very, very far from the truth. — Ron > On 7 May 2021, at 23:20, Peter Firmstone wrote: > > > On 8/05/2021 4:21 am, Ron Pressler wrote: >> Deprecation/removal JEPs, and this one is no exception, make the following >> claim: that the total good a certain JDK capability >> currently contributes to the Java ecosystem at large does not justify the >> cost of its maintenance, and it should, therefore, be >> removed — gradually, of course, and with enough time for users to find >> alternatives. An argument against such a JEP would take >> the form of, no, the total good the feature contributes to the ecosystem >> does justify its cost. >> > Sun Microsystems would deprecate, but were very slow to remove API that > caused breakages, they were also very considerate about how they would modify > api in a backward compatible manner. OpenJDK has already demonstrated it > removes api very quickly after deprecation. OpenJDK has adopted the move > quickly and break things philosophy. > > I really like the new language features under development, but the continual > breakages are causing me to rethink. > > I still haven't worked out how to replace some of the more recently removed > features, we are still building on Java 8, because of missing components in > Java 11, although we use features from and test on later versions. We > haven't been testing on Java 8, because our default ciphers target the most > recent versions and we disable anything less by default. > > Other breaking changes that have been removed can be replaced by library > code, but cause breakages since we are unable to use the java.* package > namespace. It would be friendlier, if OpenJDK allowed libraries to be > developed separately, using the java.* namespace, perhaps as part of the > project. > > This core platform feature that will be removed, probably after Java 17, but > before the following long term support version cannot be replaced by a > library. > > The maintenance debt is building up too fast to keep up with. > > I can't justify writing new projects in Java until the API has stabilized, > it's fair to say the new API is Java like, but C# is also Java like, as is > Android. > > It's clear OpenJDK wants Java to be like younger languages, and since that's > where it's headed, I might as well select one of those instead, what kept me > developing on Java was its stability and performance, when newer languages > could do the same with less. Performance of newer languages will improve > with time, just like Java did and their API's will become more stable. > > -- > Regards, > Peter Firmstone > Zeus Project Services Pty Ltd. >
Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 8/05/2021 4:21 am, Ron Pressler wrote: Deprecation/removal JEPs, and this one is no exception, make the following claim: that the total good a certain JDK capability currently contributes to the Java ecosystem at large does not justify the cost of its maintenance, and it should, therefore, be removed — gradually, of course, and with enough time for users to find alternatives. An argument against such a JEP would take the form of, no, the total good the feature contributes to the ecosystem does justify its cost. Sun Microsystems would deprecate, but were very slow to remove API that caused breakages, they were also very considerate about how they would modify api in a backward compatible manner. OpenJDK has already demonstrated it removes api very quickly after deprecation. OpenJDK has adopted the move quickly and break things philosophy. I really like the new language features under development, but the continual breakages are causing me to rethink. I still haven't worked out how to replace some of the more recently removed features, we are still building on Java 8, because of missing components in Java 11, although we use features from and test on later versions. We haven't been testing on Java 8, because our default ciphers target the most recent versions and we disable anything less by default. Other breaking changes that have been removed can be replaced by library code, but cause breakages since we are unable to use the java.* package namespace. It would be friendlier, if OpenJDK allowed libraries to be developed separately, using the java.* namespace, perhaps as part of the project. This core platform feature that will be removed, probably after Java 17, but before the following long term support version cannot be replaced by a library. The maintenance debt is building up too fast to keep up with. I can't justify writing new projects in Java until the API has stabilized, it's fair to say the new API is Java like, but C# is also Java like, as is Android. It's clear OpenJDK wants Java to be like younger languages, and since that's where it's headed, I might as well select one of those instead, what kept me developing on Java was its stability and performance, when newer languages could do the same with less. Performance of newer languages will improve with time, just like Java did and their API's will become more stable. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd.
Re: JEP411: Missing use-case: Monitoring / restricting libraries
Deprecation/removal JEPs, and this one is no exception, make the following claim: that the total good a certain JDK capability currently contributes to the Java ecosystem at large does not justify the cost of its maintenance, and it should, therefore, be removed — gradually, of course, and with enough time for users to find alternatives. An argument against such a JEP would take the form of, no, the total good the feature contributes to the ecosystem does justify its cost. But that is not the argument you are making. Instead, you are proposing a rethinking of the Security Manager. This is similar, and, I would say, identical, to proposing a new Project, which is judged by its *expected* merit vs. its expected cost. But that is a very different discussion. Obviously, arguing in favour of a new Project to redesign and re-market a feature that has been tried for over two decades and has failed to yield the expected good in recent years (possibly due to changing circumstances) would require a very compelling argument, and might be a tough sell, but in any event, this is not what is being discussed in this particular context. I could agree with some, most, or even all of your points, and yet I don’t think they are relevant to the central claim made by JEP 411. I also sense, from things you’ve said and also from reading between the lines, that you might be interpreting certain legal limitations in a manner that might be stricter than required. I am not qualified to give any legal advice and I would not attempt to do so, but I would like to point out that the JDK classes are distributed under a well-known open-source license with well-known terms, and the question of their use is separate from the question of introducing *new* classes that make use of certain trademarked names. I don't know where you can obtain advice on such matters. — Ron > On 7 May 2021, at 11:17, Peter Firmstone wrote: > > > On 6/05/2021 9:46 pm, Ron Pressler wrote: >> >> Trying to convince people, at this point, after twenty five years that the >> Security Manager isn’t complicated after all might >> be too little too late. > > > Static policy, terrible performance, no scalability at all, and the fact that > you continually have to edit policy files manually, and there's no auditing > tools? > > Ha ha ha. :) It's complicated, ha ha ha, it hardly works! Why would a > developer spend time writing concurrent code, then turn on security and slow > their hard work to a crawl? That's why they simplify it and bypass the > policy. > > No, complexity is not the problem. > > It was a good design for 1997, but the java code it's written in is also from > 1997 with little maintenance since. > > For shame. > > From my observations, the native code in AccessController is scalable and > performant and has little overhead, someone has done some very good work > there, that has to be more recent. This is a very good piece of work, very > good indeed. > > Sorry, I had to point out some truths. > > My static policy (as stated previously there is a dynamic policy also) is a > direct drop in replacement, you could ship with that, it would be a start. > You could even remove the Java policy implementation and I can make my policy > implementation available on Maven. It's AL2.0 licensed, I did look at > donating it some time ago. The code has provenance, I'm not the sole > author, I can only donate parts of it under GPL2.0 > > I can also donate the profiling tool. > > The thing is, if it was performant, people would stop switching it off, and > if there were tools to handle policy complexity, then they will start using > it, they have to use it for Principal permissions. > > Here's what OSGi does, they associate permissions with modules, to reduce > complexity: > > https://urldefense.com/v3/__https://docs.osgi.org/specification/osgi.core/8.0.0/service.condpermadmin.html__;!!GqivPVa7Brio!MA0LQDajtSBzAF17g-T_xjcu0qI1jv040zIzdYPlJ2ZRrM9RxvFl4ZxZc8leWZNQYw$ > > -- > Regards, > Peter Firmstone > Zeus Project Services Pty Ltd. >
Re: JEP411: Missing use-case: Monitoring / restricting libraries
You may be interested in tweakflow [1] in that case -- it's a scripting language that doesn't allow arbitrary operations (as opposed to Groovy etc) and can even limit the execution time [2] I would probably not set up a security manager to monitor operations, as any situation which called for a security manager could be targeted more precisely using a Java agent running Byte Buddy to do interception. [3] [1] https://twineworks.github.io/tweakflow/index.html [2] https://twineworks.github.io/tweakflow/embedding.html#limiting-evaluation-time [3] https://tersesystems.github.io/terse-logback/guide/instrumentation/ On Sat, Apr 17, 2021 at 1:24 AM Anthony Vanelverdinghe wrote: > Actually I think GraalVM can already do this today, since the mentioned > API is for use with any guest language, and Java can now run as a guest > language [1]. Note that this is also reminiscent of the `java.scripting` > module (JSR 223), which also has a `ScriptContext` class, but I'm not sure > what the long-term plans are for that API. > > Imho, any new mechanism should be tightly integrated with the module > system. In fact, Panama already has the concept of "restricted operations". > Currently, access to these operations is enabled with a simple system > property, but, quoting from [2]: > > We plan, in the future, to make access to restricted operations more > integrated with the module system; that is, certain modules might require > restricted native access; when an application which depends on said modules > is executed, the user might need to provide permissions to said modules to > perform restricted native operations, or the runtime will refuse to build > the application's module graph. > > Kind regards, Anthony > > [1] https://github.com/oracle/graal/tree/master/espresso > [2] > https://htmlpreview.github.io/?https://github.com/openjdk/panama-foreign/blob/eb2f956aef1d039a0d364eb69ed91bb9293c4387/doc/panama_memaccess.html > > On Friday, April 16, 2021 23:37 CEST, Mark Raynsford > wrote: > > > On 2021-04-16T17:02:06 -0400 > > Sean Mullan wrote: > > > > > > That said, I think it is worth exploring (in this JEP) or another JEP > > > ways that we might think about that could help provide DiD protection > > > for network and file access. This is an opportunity to look at the > > > problem with a fresh set of eyes, w/o the existing complicated > > > infrastructure and APIs that encompass the Security Manager. > > > > This is something that has interested me in the past. Although I'm not > > working on anything currently that would need it, I've often come up > > against this sort of thing in application plugin systems. That is, > > users have an application that they do trust and they want to load > > plugins into it that weren't written by the application author and that > > they do not necessarily trust. > > > > Languages such as Lua handle this fairly well by having programmers > > create lightweight scripting contexts for running scripts inside a > > host program. The guest scripts: > > > > * Can't call I/O methods if they aren't given access to a > > a table of I/O methods. This actually extends to not being > > able to call foreign code at all if access isn't provided; > > scripts are limited to objects within the provided table. > > > > * Can't use unbounded heap space if a custom allocator is > > handed to the script context. > > > > * Can't go into an infinite loop if instruction count limits > > are enabled (the interpreter is pre-empted or halted if it > > reaches N instructions, where N is some value configured > > by the host). > > > > * Can't create new threads. > > > > * Are probably memory-safe, assuming a lack of bugs in the > > Lua interpreter. :) > > > > Under those constraints, it's pretty tough to do anything disruptive > > even if you're trying to. Without access to I/O functions and other > > foreign code in the global table, you're pretty much limited to doing > > arithmetic. Quietly. And not too much of it. > > > > Similar constraints are available for code running under GraalJS [0] > > and that's certainly achieved without a security manager. > > > > I'm more inclined to think something that is rather blunt and brute > > force can be made to work well than something extremely fine-grained > > like the security manager. The blunt and brute force method says > > "put all this small piece of untrusted code in this box, and it's > > not allowed to do anything other than the very few things I say it can, > > and the code outside of the box is allowed to do whatever it could > > normally do". The security manager more or less has to have a large > > manually-maintained policy for the entire application and everything in > > it, and I think that's where it falls over. > > > > [0]: > https://www.graalvm.org/sdk/javadoc/org/graalvm/polyglot/Context.Builder.html > > > > -- > > Mark Raynsford | https://www.io7m.com > > > >
Re: RFR: 8266225: jarsigner is using incorrect security property to show weakness of certs [v2]
On Thu, 6 May 2021 20:57:13 GMT, Hai-May Chao wrote: >> Please review the change to jarsigner so it uses certpath security property >> in order to properly display the weakness of the certificate algorithms. > > Hai-May Chao has updated the pull request incrementally with one additional > commit since the last revision: > > Test with new java.security file Marked as reviewed by weijun (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3905
Re: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider
On Wed, 21 Apr 2021 01:26:18 GMT, Valerie Peng wrote: >> Added capability to allow the PKCS11 Token to be destroyed once a session is >> logged out from. New configuration properties via pkcs11 config file. >> Cleaned up the native resource poller also. >> >> New unit test case to test behaviour. Some PKCS11 tests refactored to allow >> pkcs11 provider to be configured (and tested) with a config file of choice. >> >> Reviewer request @valeriepeng > > I will take a look. Thanks! Thanks for the review @valeriepeng Apologies for delay, had to finish up other tasks -- I've made all suggested edits that you made for src/ code and pushed those changes to my branch. For the testing, then I recall the PKCS11Test framework not being able to return multiple PKCS11 Providers to me for testing (an array of providers) -- I thought editing the framework for such a use case would be useful but perhaps I'm better off just writing a customized test. I'm going to take a stab at that and will re-submit a test edit. Apologies for including the Login.java/ Login.sh edits - they were old left over edits from testing efforts before moving on to develop the new MultipleLogins.java test. - PR: https://git.openjdk.java.net/jdk/pull/3544
Re: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v2]
> Added capability to allow the PKCS11 Token to be destroyed once a session is > logged out from. New configuration properties via pkcs11 config file. Cleaned > up the native resource poller also. > > New unit test case to test behaviour. Some PKCS11 tests refactored to allow > pkcs11 provider to be configured (and tested) with a config file of choice. > > Reviewer request @valeriepeng Sean Coffey has updated the pull request incrementally with one additional commit since the last revision: Initial corrections from RFR - Changes: - all: https://git.openjdk.java.net/jdk/pull/3544/files - new: https://git.openjdk.java.net/jdk/pull/3544/files/dd185388..f053bc39 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3544=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3544=00-01 Stats: 94 lines in 8 files changed: 22 ins; 38 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/3544.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3544/head:pull/3544 PR: https://git.openjdk.java.net/jdk/pull/3544
Integrated: 8265426: Update java.security to use instanceof pattern variable
On Mon, 26 Apr 2021 08:50:36 GMT, Patrick Concannon wrote: > Hi, > > Could someone please review my code for updating the code in the > `java.security` package to make use of the `instanceof` pattern variable? > > Kind regards, > Patrick This pull request has now been integrated. Changeset: 86b8dc9f Author:Patrick Concannon URL: https://git.openjdk.java.net/jdk/commit/86b8dc9f5b3729e22e9cd31aba7b920fa39aa5c1 Stats: 169 lines in 23 files changed: 4 ins; 84 del; 81 mod 8265426: Update java.security to use instanceof pattern variable Reviewed-by: rriggs, weijun, dfuchs - PR: https://git.openjdk.java.net/jdk/pull/3687
Re: RFR: 8265426: Update java.security to use instanceof pattern variable [v5]
On Thu, 6 May 2021 14:42:20 GMT, Patrick Concannon wrote: >> Hi, >> >> Could someone please review my code for updating the code in the >> `java.security` package to make use of the `instanceof` pattern variable? >> >> Kind regards, >> Patrick > > Patrick Concannon has updated the pull request incrementally with one > additional commit since the last revision: > > 8265426: changed order of equals check; refactored Identity.equals method Marked as reviewed by rriggs (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3687
Re: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
On Thu, 6 May 2021 19:15:27 GMT, Xue-Lei Andrew Fan wrote: >> Unfortunately, simple pull() can not be used in this case. We have to check >> if the session found in the cache can be rejoined with parameters received >> in ClientHello and server context. Only rejoinable sessions should be >> removed from the session cache. >> It is possible to use simple pull() and restore session in the cache if the >> session is not rejoinable, but I do not like this approach. Also, it will >> require extending Cache with get/setExpirationTime methods. > >> Unfortunately, simple pull() can not be used in this case. We have to check >> if the session found in the cache can be rejoined with parameters received >> in ClientHello and server context. Only rejoinable sessions should be >> removed from the session cache. > > For TLS 1.3, I think it may be safe to remove the session from the cache even > if it is no rejoinable. @XueleiFan Thank you for suggestion. The patch is updated using a simple pull() - PR: https://git.openjdk.java.net/jdk/pull/3664
Re: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
> Hello All, > > Could you please review the fix for the JDK-8241248? > The issue happens during the TLSv1.3 handshake without server stateless > session resumption in case of server receives several parallel requests with > the same pre_shared_key. > The main idea of the fix is to remove resuming session from the session cache > in the early stage. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8241248 > Webrev 8u: http://cr.openjdk.java.net/~abakhtin/8241248/webrev.v0/ > > The test from the bug report using OpenSSL is passed ( > -Djdk.tls.server.enableSessionTicketExtension=false ) > javax/net/ssl and sun/security/ssl jtreg tests passed > > Regards > Alexey Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision: Add Cache.pull method - Changes: - all: https://git.openjdk.java.net/jdk/pull/3664/files - new: https://git.openjdk.java.net/jdk/pull/3664/files/aac8eee7..73f7e8e8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3664=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3664=01-02 Stats: 270 lines in 4 files changed: 128 ins; 129 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3664.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3664/head:pull/3664 PR: https://git.openjdk.java.net/jdk/pull/3664
Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v13]
> This PR contains the API and implementation changes for JEP-412 [1]. A more > detailed description of such changes, to avoid repetitions during the review > process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix issue in snippet in package-info - Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/926229ed..1ce6366a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=3699=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk=3699=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699
Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 6/05/2021 9:46 pm, Ron Pressler wrote: Trying to convince people, at this point, after twenty five years that the Security Manager isn’t complicated after all might be too little too late. Static policy, terrible performance, no scalability at all, and the fact that you continually have to edit policy files manually, and there's no auditing tools? Ha ha ha. :) It's complicated, ha ha ha, it hardly works! Why would a developer spend time writing concurrent code, then turn on security and slow their hard work to a crawl? That's why they simplify it and bypass the policy. No, complexity is not the problem. It was a good design for 1997, but the java code it's written in is also from 1997 with little maintenance since. For shame. From my observations, the native code in AccessController is scalable and performant and has little overhead, someone has done some very good work there, that has to be more recent. This is a very good piece of work, very good indeed. Sorry, I had to point out some truths. My static policy (as stated previously there is a dynamic policy also) is a direct drop in replacement, you could ship with that, it would be a start. You could even remove the Java policy implementation and I can make my policy implementation available on Maven. It's AL2.0 licensed, I did look at donating it some time ago. The code has provenance, I'm not the sole author, I can only donate parts of it under GPL2.0 I can also donate the profiling tool. The thing is, if it was performant, people would stop switching it off, and if there were tools to handle policy complexity, then they will start using it, they have to use it for Principal permissions. Here's what OSGi does, they associate permissions with modules, to reduce complexity: https://docs.osgi.org/specification/osgi.core/8.0.0/service.condpermadmin.html -- Regards, Peter Firmstone Zeus Project Services Pty Ltd.
Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v12]
On Thu, 6 May 2021 14:23:27 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-412 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] - https://openjdk.java.net/jeps/412
>
> Maurizio Cimadamore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Replace uses of -Djdk.foreign.restricted (useless now) with
> --enable-native-access
src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java
line 72:
> 70: *
> 71: * {@code
> 72: try (ResourceScope scope = ResourceScope.ofConfined()) {
The example might be out of date, I assume this should be newConfinedScope.
-
PR: https://git.openjdk.java.net/jdk/pull/3699
Re: RFR: 8265426: Update java.security to use instanceof pattern variable [v5]
On Mon, 26 Apr 2021 17:52:05 GMT, Jesper Steen Møller wrote: > Changes look good, except for the unneeded parenthesis? > > (but I'm not a committer, so it's less useful) Hi Jesper, thanks for your suggestions and well spotted. I've addressed the issues and responded to your comments with the commit id where the changes were made - PR: https://git.openjdk.java.net/jdk/pull/3687
