Re: RFR: 8269130: Replace usages of Collection.toArray() with Collection.toArray(T[]) to avoid redundant array copying
On Mon, 14 Jun 2021 17:00:29 GMT, Andrey Turbanov wrote: > I found few places, where code initially perform `Object[] > Colleciton.toArray()` call and then manually copy array into another array > with required type. > This PR cleanups such places to more shorter call `T[] > Collection.toArray(T[])`. Changes in the desktop module looks fine. - Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/4487
Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
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: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > Igor Ignatyev has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. The pull request contains 12 new > commits since the last revision: > > - fixed ctw build > - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class > - updated requires.VMProps > - updated TEST.ROOT > - adjusted hotspot source > - added test > - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox) > - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class > - removed sun/hotspot/parser/DiagnosticCommand > - deprecated sun/hotspot classes >disallowed s.h.WhiteBox w/ security manager > - ... and 2 more: > https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860 Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java? Thanks. - PR: https://git.openjdk.java.net/jdk17/pull/290
Re: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
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: >> - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g` >> - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g` >> - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g` >> - `s/sun.hotspot.code/jdk.test.whitebox.code/g` >> - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g` >> - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g` >> >> testing: tier1-4 >> >> Thanks, >> -- Igor > > Igor Ignatyev has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. Hi Igor, This set of changes seems much more manageable to me. Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class? Thanks, David - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/290
Re: JEP 411, removal of finalizers, a path forward.
On 01/08/2021 15:28, Uwe Schindler wrote: : What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas how Java threads should behave. I know the main problem is not "SecurityManager is too complex / too slow / wrongly used /..." -- the main problem of some OpenJDK people around the Loom project is that it won't work correctly with those new type of threads. You are now always arguing against use cases of SecurityManager for the purpose of secuirty because you just want to hide that the new "light" threads (aka fibers) in project Loom are incompatible to the stack-based access control provided by AccessController and SecurityManager. So the only canard is Project Loom - sorry! This isn't right, I don't know where you got that. The only connection to threads is the unspecified capturing of an access control context at Thread create time. Loom has been betting that it will be irrelevant and eventually removed so doesn't capture it. For the interim it just specifies that virtual threads have "no permissions". : - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem API is not enough: it does not cover java.io.File (why is this the case?) nor does the FileSystem API allows to hook in everywhere. We figured out that for example the new Panama interface to get a MemorySegment from a file path is not calling any API in the Filesystem abstraction! There are bootstrapping and compatibility issues, this isn't the right place to go into all that. We have seen this in Java 9 already: Suddenly the module system was weakened shortly before release: because there was no replacement for sun.misc.Unsafe. This isn't right either. Critical internal APIs, including sun.misc.Unsafe, were never encapsulated. So no change to the accessibility of Unsafe when relaxed strong encapsulated was introduced in Java 9. -Alan
Re: JEP 411, removal of finalizers, a path forward.
On 01.08.21 16:28, Uwe Schindler wrote: The problem is: you deprecate for removal without offering any API to replace the main pain points: ... - Disable damn java serialization completely JDK 9+ JVM flag / security property, see JEP 290 -Djdk.serialFilter=!* regards, michael
Re: JEP 411, removal of finalizers, a path forward.
Hi Peter. - JEP 411, like every spec-changing JEP, is meant to allow those that use the removed functionality a migration path forward. The API elements that are deprecated for removal have some years before they are actually removed, so there’s nothing too urgent other than beginning to think of a migration path. I think it’s still too soon to consider concrete suggestions for change, especially non-trivial ones. - If by Java 8 EOL you mean the time when the last vendor offers extended support for it, then 2030 is, I believe, the *earliest* possible date that is guaranteed *now. It’s possible that support would be extended until 2130. Such offerings have no bearing on the development of current JDK versions. - The number of significant code changes required since JDK 8 to keep up with current JDK releases is, for the vast majority of Java users, low (what’s affected most users is reliance on non-spec-compliant libraries, and the need to import the external artefacts for EE). The most impactful change has probably been the removal of some client deployment technologies from the Oracle JDK, but as far as OpenJDK is concerned, the affected areas have been CORBA, pack200, Nashorn, and now the process to remove SM is starting. The number of people using any one of these is low, and the number of those who need to work hard for alternatives is very low. I think that advance warning, and then support offerings by multiple vendors for those who have not managed to migrate in the advance warning period is reasonable; always offering ways to support removed technologies together with new features in current releases with the same code base is not. When compared with other ecosystems, Java’s strategy is exceptionally tolerant of those that prefer slow change. - Property-based testing is wonderful, I wish more people would use it, and I hope to see it used in the JDK as well. Java has several PBT tools, but I believe the most popular one these days is https://jqwik.net/. As long as you’re still with Java, give it a try. — Ron > On 31 Jul 2021, at 04:04, Peter Firmstone wrote: > > The current JEP 411 plan of action, if left unchanged, will leave developers > who adopted the SM architecture as an authorization layer unable to upgrade > to later versions of Java, until finalizers and the finalizer attack > defensive methods in constructors are removed. JEP 411 has the potential to > cause significant disruption for a small proportion of Java developers, but > doesn't have to if managed appropriately. > > The blocker is the ability to implement guard checks using Agents on public > API, due to finalizer attack defensive private static methods in constructors. > > Allan has advised when finalizers are removed, it will be practical to use > Agents to instrument public API to implement an authorization layer, this is > try, so can it be coordinated with JEP 411 et al? > > Furthermore, as developers must support multiple Java releases, I propose the > following amendments, to ease difficulties of multiple release support (with > multi release jars): > > * AccessController, AccessControlContext, DomainCombiner and related > Subject and Executors methods, remain until Java 8 is EOL in 2030. > Also consider un-deprecation of these methods, as their removal > causes shotgun surgery (used in 1000's of locations in my software > alone) and they are required for preservation of Subject, used for > obtaining TLS and Kerberos connection credentials on all existing > versions of Java. > * AccessControlContext - remove inherited thread context, replace it > with an unprivileged ProtectionDomain, such that doPrivileged > methods are required for authorization checks and only the current > thread stack needs to be walked when checks occur, and stack walks > aren't unnecessarily performed when creating new threads. This is > compatible with Loom, update loom to allow the use of > AccessControlContext to be used, to establish TLS and Kerberos > connections. Loom will be very useful for network connections, > especially long latency connections over the internet, which are > typically secured using TLS. This removes the problem of viral > checks, and Executor task privilege escalation. > * Modules that are mapped to the boot loader should get a unique PD > that includes a useful code source rather than using a "shared" PD, > this allows us to reduce the privileged footprint of the Java > platform libraries, to allow privileges to be granted to users, not > code, or users and code. This is useful to limit data parsing > privileges to authenticated users on servers (a practise that should > be more widely encouraged). > * Remove finalizers, and defensive methods in constructors where > permissions check points occur as these cause problems for Agents, > prior to removal of SecurityManager. > * Deprecate for removal Permission
Re: JEP 411, removal of finalizers, a path forward.
On 01.08.21 18:35, Michael Bien wrote: On 01.08.21 16:28, Uwe Schindler wrote: The problem is: you deprecate for removal without offering any API to replace the main pain points: ... - Disable damn java serialization completely JDK 9+ JVM flag / security property, see JEP 290 -Djdk.serialFilter=!* regards, michael (for deserialization only) -michael
RE: JEP 411, removal of finalizers, a path forward.
Hi Andrew, > > 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, parsing xml and serialization. > > You need to stop repeating this canard. There is no absolute need for > OpenJDK to retain a security mechanism to deal with problems that for > almost every use case are better solved by using non-OpenJDK > alternatives (such as OS security measures). Indeed, it's the other way > round: there is an imperative for the project to spend precious > resources on alternative capabilities (not necessarily security related). Sorry, as another open source project affected by the stupid JEP 411 desaster I would like to fully confirm to EVERYTHING that Peter said. It is not a canard, it is the reality and I am really disappointed what happened. What I figured out: You intend to remove SecurityManager because it does not fit your latest ideas how Java threads should behave. I know the main problem is not "SecurityManager is too complex / too slow / wrongly used /..." -- the main problem of some OpenJDK people around the Loom project is that it won't work correctly with those new type of threads. You are now always arguing against use cases of SecurityManager for the purpose of secuirty because you just want to hide that the new "light" threads (aka fibers) in project Loom are incompatible to the stack-based access control provided by AccessController and SecurityManager. So the only canard is Project Loom - sorry! So I will do the same: repeat the same story like Peter's over an over. Two large projects affected by your changes are Apache Solr and Elasticsearch. Both use security manager not only for security purposes, but also to control access to resources and classloading! Speed is also no issue if you use security manager correctly. In Apache Lucene/Solr/Elasticsearch there is NO slowdown visible as the hooks into security manager are only called for uncritical places (like opening a file before mmapping it, open a listening socket, loading a class...). The problem is: you deprecate for removal without offering any API to replace the main pain points: - preventing exit of JDK - an API to control class loading and prevent code from calling Method/Field/Constructor#setAccessible(true) for specific cases (e.g., you want a scripting language like Groovy to not allow caling sun.misc.Unsafe,...). Those things can never be done with code outside of the JVM! - Allow to hook into the I/O system. Unfortunately the java.nio FileSystem API is not enough: it does not cover java.io.File (why is this the case?) nor does the FileSystem API allows to hook in everywhere. We figured out that for example the new Panama interface to get a MemorySegment from a file path is not calling any API in the Filesystem abstraction! - Disable damn java serialization completely > The fact that your software can no longer profit from this specific > mechanism is a /special case/ which means any loss incurred is a > /special loss/ not a general one. Users who rely on your software for > the security guarantees you claim it provides may well no longer be able > to do so once this mechanism is removed. However, claiming that this > implies Java is no longer secure by default is a /gross/ > misrepresentation of what is at stake. The name "SecurityManager" is a legacy name. In fact "AccessController" and "Policy" is much better and exactly suits our needs and what we expect from it. We don't want security, we want access control and corresponding policies. That 2 different things! > Java can be used perfectly well to implement secure applications without > the security manager. That's evidenced by two facts: on the one hand > experience has shown that most programs that rely on the security > manager are not actually more secure because of using it; on the other > hand there are many highly secure Java programs out there in the field. That might be true, but the current state does not allow this for all use cases. Most projects use Security Manager not for security. Look at the code out there! > The fact that your software will no longer provide a specific route to > implementing a certain type of security capability may be a great loss > to you but it is not a significant loss, never mind some absolute loss > in kind, to Java and Java application developers. I recommend you stop > repeating this distorted opinion. It's only effect will be squander the > goodwill of those currently trying to help you, people whose driving > interest is nothing other than to make OpenJDK a better product. It is a great loss for many people, not only Peter. In Apache Lucene, Solr and Elastisearch, usage of SecurityManager will stay alive as long as possible (possible till Java version 27 or later). If it won't work
Re: JEP 411, removal of finalizers, a path forward.
On 01/08/2021 03:14, Peter Firmstone 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, parsing xml and serialization.
You need to stop repeating this canard. There is no absolute need for
OpenJDK to retain a security mechanism to deal with problems that for
almost every use case are better solved by using non-OpenJDK
alternatives (such as OS security measures). Indeed, it's the other way
round: there is an imperative for the project to spend precious
resources on alternative capabilities (not necessarily security related).
The fact that your software can no longer profit from this specific
mechanism is a /special case/ which means any loss incurred is a
/special loss/ not a general one. Users who rely on your software for
the security guarantees you claim it provides may well no longer be able
to do so once this mechanism is removed. However, claiming that this
implies Java is no longer secure by default is a /gross/
misrepresentation of what is at stake.
Java can be used perfectly well to implement secure applications without
the security manager. That's evidenced by two facts: on the one hand
experience has shown that most programs that rely on the security
manager are not actually more secure because of using it; on the other
hand there are many highly secure Java programs out there in the field.
The fact that your software will no longer provide a specific route to
implementing a certain type of security capability may be a great loss
to you but it is not a significant loss, never mind some absolute loss
in kind, to Java and Java application developers. I recommend you stop
repeating this distorted opinion. It's only effect will be squander the
goodwill of those currently trying to help you, people whose driving
interest is nothing other than to make OpenJDK a better product.
regards,
Andrew Dinn
---
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
