From valeriep at openjdk.java.net Mon May 3 19:06:51 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 3 May 2021 19:06:51 GMT Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey 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 test/jdk/sun/security/pkcs11/PKCS11Test.java line 555: > 553: } > 554: p = getSunPKCS11(nssConfig); > 555: test.premain(p); It seems a bit strange that the 2nd argument p isn't really used, but rather overridden with getSunPKCS11(String config) call. Do you mean to call getSunPKCS11(nssConfig, p) here if p is non-null? ------------- PR: https://git.openjdk.java.net/jdk/pull/3544 From sean.mullan at oracle.com Mon May 3 19:12:53 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 3 May 2021 15:12:53 -0400 Subject: Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization? In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> Message-ID: <64985afa-1d8b-cc6c-3283-4fd4ef0f5d1a@oracle.com> -bcc jdk-dev -cc security-dev On 4/30/21 10:04 PM, Peter Firmstone wrote: > Having had a day to think about this JEP, I have a simple request, I'd > like to add to this JEP. > > Because those of us who require Access Control functionality will have > to remain with a legacy version of Java until EOL and following that > need to maintain and backport security patches ourselves. > > Create a new JEP for deprecation and removal of Java's Serialization > implementation.? Please remove Java Serialization first, then remove the > Security Manager a version after that (Deprecating both now).? Make Java > more secure first, before reducing security.? We know that Serialization > will eventually be removed, and removing it will allow the community to > maintain a community LTS version with fewer resources.? After removal, > leave the public Serialization API in place, abstract without an > implementation, to allow third party implementations to continue utilize > and implement it and existing code to compile also add SerializerFactory > to RMI. > > We've had much longer (at least 10 years notice) to understand why Java > Serialization should be avoided and the luxury of many viable migration > alternatives to implement, not to mention it's the king of maintenance > burdens and security vulnerabilities. > > Don't get me wrong, removing Serialization will cause pain, but it's not > chronic pain, because we can migrate to alternatives, we will still be > able to migrate to later versions of Java, at least until the removal of > Access Control. > > Clearly there is no way for a library to provide AccessController > functionality, it's only possible to provide this functionality at the > platform level, not so with Serialization. > > We develop software that works peer to peer / distributed that blurs the > lines between server and client.? We realize this is no longer a target > market for Java development, along with applets and client code. > > Fine grained access control is required to control access to sensitive > data, to prevent unauthorised access. > > Now IoT, is often called the "Internet of S___t" because it lacks security. > > We realise there are shortcomings with Java Security, it's not perfect > but it does work for access control, when only limited access is > permitted, I am wondering how to maintain equivalent security without an > AccessController?? What other languages or platforms do security well, > that could be used to provide guidance? > > We put into practice the principle of least privilege, we have the > ability to dynamically grant additional permission as needed, we also > restrict the permissions that can be granted.?? Java 1.4 was modified to > allow dynamically granted permission, even though it wasn't implemented > by the Java Policy provider, it was intended to be extensible for > developers to develop their own implementations, and we did. > > This is functionality that is currently working, it remains in use and > under development it is not legacy code.?? It is the result of a > significant investment of time and money and we lack the resources to > rewrite it in another language that supports fine grained access control. > > We use dynamic code, via Maven :) > > In our software we use a ProtectionDomain to represent a remote server, > because a thread only runs with the user's Subject (and that Subject > must be carefully preserved for other threads), there is no way to > represent the remote Server's Subject in a local domain , other than > with a ProtectionDomain. ? Our software is peer to peer, clients can be > servers and servers can also be clients.? Code to interact with the > server is downloaded via Maven and loaded.? Any permission's granted to > a user, are injected into the stack when run as the client Subject, to > authenticate the user for the server and establish a secure connection, > calls made by the client are run with the user's Subject on the server, > again for access control purposes.? This functionality is beyond the > capability of Java RMI, we aren't using Java RMI to do this.? This is > very important to allow us to make fine grained access control > decisions, or perform event notification callbacks over secure > connections, without this feature, we can't make a secure connection > with a callback, and you know what happens when you have to do > something, but cannot do it securely??? We only grant network access > directly back to the server, downloaded code has been verified and is > not expected to cause denial of service, by consuming resources etc, but > we don't want to grant third party access to files, or random network > connections, we still have privacy obligations for third party information. > > We can allow a third party to use unsigned certificates to sign their > jar files or use a checksum and we verify them using a secure connection > to the server, prior to loading.?? We then dynamically grant permissions > to the server's self signed Certificate (used to sign the jar file), or > a ProtectionDomain, after authenticating the server and receiving a > check sum or certificate from it.? So the client authenticates the > server using signed TLS certificates (EG by letsencrypt.org or a trusted > CA). We use self signed certificates on Jar files if we sign them, we > are actually trusting the server entity in this case, eg a trusted > company, but also placing restrictions on them. I am probably missing something, but I don't understand how this is secure if you are using TLS server certificates as the basis for authenticating signed code. These are two very different use cases. > If we remove access control, third parties will be able to open local > network connections and freely and use Java Serialization over unsecured > connections, exposing us to an attacker who can use a gadget attack. > Presently they cannot open a network connection, access files or do much > of anything without Permission.? All those protections will be removed > with this JEP. > > from https://community.letsencrypt.org/t/do-you-support-code-signing/370 > >> Code-signing certificates as they?re used today are part of systems >> that try to decide whether a software source is malicious or >> legitimate. I don?t think Let?s Encrypt could easily play that kind of >> role when issuing certificates free of charge with an automated >> process without checking the real-world identity of the applicant. We >> could confirm that a code signing certificate applicant controls a >> domain name like iurewnrjewknkjqoiw.biz 408 >> , but that doesn?t give users or >> operating system developers much ability to know whether software that >> that applicant publishes is trustworthy or malicious. > > The JVM is one of very few platforms that has sufficient capability to > allow us to do this. > > If I could chose my pain, I would chose to remove Java Serialization > first, before SecurityManager because while I understand the maintenance > burden needs to be reduced for the ongoing viability of the Java > platform, security is still of utmost importance, as the vulnerabilities > of Java Serialization killed of client development. I don't think it is appropriate to block deprecation of the Security Manager until serialization is removed. Note that we have added mechanisms such as Serialization Filters [1] to help applications secure their serialization dependencies and that do not require a Security Manager to be enabled. We also are continuing to look at other improvements in this area, as well as introducing new features such as Records that can be serialized more securely [2]. --Sean [1] https://docs.oracle.com/en/java/javase/16/core/serialization-filtering1.html#GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A [2] https://inside.java/2021/04/06/record-serialization-in-practise/ From peter.firmstone at zeus.net.au Mon May 3 22:35:27 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 4 May 2021 08:35:27 +1000 Subject: Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization? In-Reply-To: <64985afa-1d8b-cc6c-3283-4fd4ef0f5d1a@oracle.com> References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <64985afa-1d8b-cc6c-3283-4fd4ef0f5d1a@oracle.com> Message-ID: On 4/05/2021 5:12 am, Sean Mullan wrote: > -bcc jdk-dev > -cc security-dev > > On 4/30/21 10:04 PM, Peter Firmstone wrote: >> >> >> In our software we use a ProtectionDomain to represent a remote >> server, because a thread only runs with the user's Subject (and that >> Subject must be carefully preserved for other threads), there is no >> way to represent the remote Server's Subject in a local domain , >> other than with a ProtectionDomain. ? Our software is peer to peer, >> clients can be servers and servers can also be clients.? Code to >> interact with the server is downloaded via Maven and loaded.? Any >> permission's granted to a user, are injected into the stack when run >> as the client Subject, to authenticate the user for the server and >> establish a secure connection, calls made by the client are run with >> the user's Subject on the server, again for access control purposes.? >> This functionality is beyond the capability of Java RMI, we aren't >> using Java RMI to do this.? This is very important to allow us to >> make fine grained access control decisions, or perform event >> notification callbacks over secure connections, without this feature, >> we can't make a secure connection with a callback, and you know what >> happens when you have to do something, but cannot do it securely??? >> We only grant network access directly back to the server, downloaded >> code has been verified and is not expected to cause denial of >> service, by consuming resources etc, but we don't want to grant third >> party access to files, or random network connections, we still have >> privacy obligations for third party information. >> >> We can allow a third party to use unsigned certificates to sign their >> jar files or use a checksum and we verify them using a secure >> connection to the server, prior to loading.?? We then dynamically >> grant permissions to the server's self signed Certificate (used to >> sign the jar file), or a ProtectionDomain, after authenticating the >> server and receiving a check sum or certificate from it.? So the >> client authenticates the server using signed TLS certificates (EG by >> letsencrypt.org or a trusted CA). We use self signed certificates on >> Jar files if we sign them, we are actually trusting the server entity >> in this case, eg a trusted company, but also placing restrictions on >> them. > > I am probably missing something, but I don't understand how this is > secure if you are using TLS server certificates as the basis for > authenticating signed code. These are two very different use cases. Clarifying the level of trust: 1. You have a trusted party, whom you trust to write their own code. 2. You run that code on your systems dynamically. 3. You trust the other party, but you either haven't or it's not practical to audit their code. 4. Using the principle of least privilege, you limit the ability of the other party's code to ensure they are unable observe data they shouldn't, eg a third party with whom you also do business. 5. While a trusted party (eg a supplier) could write code that caused denial of service, eg using up all available memory, there is no motivation for them to do so.? However there may be motivation for them to see quotes on your system from another supplier if they have access to it. The code is loaded dynamically, but before the jvm loads it, we authenticate the party that is asking us to load their code, after which we are basically asking them the question, is this the code you want us to load?? Please check that it hasn't been tampered with.?? The trusted party gives us a checksum, or a self signed certificate they used to sign the jar, we are then satisfied that we have received the software unaltered from the trusted party and not a MITM attack, so we load it.?? However we limit the permission of this software using the principle of least privilege.?? They don't get file permissions, they are only allowed to connect to the server they used to authenticate with. If a third party uses the same jar file, they don't gain the permissions granted to other parties, as it will be loaded into a separate ClassLoader with the permissions granted to that party only. > >> If we remove access control, third parties will be able to open local >> network connections and freely and use Java Serialization over >> unsecured connections, exposing us to an attacker who can use a >> gadget attack. Presently they cannot open a network connection, >> access files or do much of anything without Permission.? All those >> protections will be removed with this JEP. >> >> from https://community.letsencrypt.org/t/do-you-support-code-signing/370 >> >>> Code-signing certificates as they?re used today are part of systems >>> that try to decide whether a software source is malicious or >>> legitimate. I don?t think Let?s Encrypt could easily play that kind >>> of role when issuing certificates free of charge with an automated >>> process without checking the real-world identity of the applicant. >>> We could confirm that a code signing certificate applicant controls >>> a domain name like iurewnrjewknkjqoiw.biz 408 >>> , but that doesn?t give users or >>> operating system developers much ability to know whether software >>> that that applicant publishes is trustworthy or malicious. >> >> The JVM is one of very few platforms that has sufficient capability >> to allow us to do this. >> >> If I could chose my pain, I would chose to remove Java Serialization >> first, before SecurityManager because while I understand the >> maintenance burden needs to be reduced for the ongoing viability of >> the Java platform, security is still of utmost importance, as the >> vulnerabilities of Java Serialization killed of client development. > > I don't think it is appropriate to block deprecation of the Security > Manager until serialization is removed. Note that we have added > mechanisms such as Serialization Filters [1] to help applications > secure their serialization dependencies and that do not require a > Security Manager to be enabled. We also are continuing to look at > other improvements in this area, as well as introducing new features > such as Records that can be serialized more securely [2]. I'm not suggesting blocking deprecation of SecurityManager, I'm requesting blocking removal of SecurityManager until after Serialization has been removed.?? So deprecate SecurityManager, just don't mark it for removal yet.? Please mark SecurityManager for removal after Serialization has been removed.?? What follows is the reasoning for my request. We currently use SecurityManager and policy to prevent un-trusted connections which could otherwise use serialization or access sensitive data. ?? We only allow a limited subset re-implementation of serialization over trusted connections and permission must be granted before it can be used.? No trust established (TLS), then no Serialization.? Because we load code dynamically, we will not be able to profile it in advance, so we cannot create serialization whitelists because we have no way of knowing class names in advance, our only choice will be to disable Serialization entirely.?? At least with security policy, we can establish the permissions in advance. Presently the dynamically loaded code, contains a list of requested Permissions in META-INF, however they may not be granted, the security policy has a list of Permission's that are allowed to be granted based on the remote principal, the permissions granted will be the intersection of these two lists, requested and allowed permissions.? We can log permissions that are not granted.? This occurs dynamically at runtime.? A Permission requested may also be a subset of the Permissions allowed, because of implies checks.? So dynamically loaded code really does operate under least privilege principles.? You can't do that with Serialization filtering. Prior to the introduction of the Serialization's filtering mechanism, I re-implemented a subset of Java Serialization, focused on addressing vulnerabilities caused by gadget attacks. We did this when other companies solutions to addressing Java vulnerabilities was to remove Java altogether, which is why Java applets are no longer used.? Instead, we knuckled down and addressed the vulnerabilities. I had to remove circular links because they introduce security vulnerabilities, I also limited the number of bytes the stream can download before it must be reset, otherwise an IOException is thrown and control is returned to the caller.? It uses constructors, and all classes are expected to validate invariants.? We've discussed it previously.? Apart from Collection classes, serial form of existing classes has not been altered, instead classes have new Constructor's that are used to validate their de-serialized fields.? All fields have also undergone their own validation process.? J.B. called it atomic serialization, when we first discussed it, so that's what we call it. My first step was to re-implement deserialization and use that for some time with the new deserialization public API,? I'm currently implementing a public API for serialization.? After this I will introduce more serialization protocols that use the same API, at that time I may have to change the serial form of some classes, as Java serialization had a lot of complex features that other serialization protocols lack.? The deserialization api, is capable of supporting multiple serial forms, to allow class implementations to change them. Certain Java Collection classes are vulnerable to denial of service attacks, so they are not serialized, instead I have serializers that transfer the data, which is validated during deserialization, before populating the Java Collection classes via constructors.? This means any Collection class can be serialized, even those that don't implement Serializable, they all have the same serial form, so their serialized form basically respects the Collection interfaces of Map, Set and List, their bytes can be compared for equality, for example if two Map's are equal, their serialized bytes will also be equal. Furthermore serialization filters have the same complexity flaws as the Security Manager model, but in our case we use SecurityManager to grant a limited set of privileges that we are able to establish prior to loading dynamic code.??? We already have a profiling tool that generates policy files. Once SecurityManager is removed, third party code will have all permission's granted to the JVM, so they will be able to view files and make network connections.?? The serialization filters offer a similar level of complexity, but with less protection and less time for tool development.? No doubt this will require us to rethink the structure of our software and access control to sensitive data. Once we fixed Policy performance issues and created profiling tools for initial creation of policy files, which are used as a guide to create the requested permission lists and enable permissions to be granted dynamically at runtime, security becomes a significant benefit rather than a burden. To quote waratek: reference https://www.waratek.com/java-serialization-filtering/ > To configure Serialization Filtering, the application needs to first > be fully profiled. *Profiling* an app can be a complex process that > requires specialized tools and has to be performed by domain experts. > Typically, the process requires the app to run normally for a period > of time in order for all its paths to be executed. A dynamic profiling > tool can log the class names that are required for normal operation. > This list of class names will then be the basis of configuring the > white/black list of the Serialization Filters. And even after going > through this process, there is no guarantee that all of the execution > paths were run and all the required class names were logged. Of > course, the same process needs to be performed every time a new > release goes into production or even when a third-party library must > be upgraded. The lifecycle of this process becomes even more complex > since such any change in the Serialization Filters will first need to > go through QA and UAT before it reaches production. > > The Serialization Filtering mechanism follows a very similar approach > to the Security Manager > . > The Security Manager also works based on a whitelist > > and suffers from the same scalability problems. Java?s Security > Manager has proved to be unsuitable for enterprise, large-scale > environments, given that *it moves the responsibility of protecting > the system to the user*. The user is responsible for understanding the > application?s security requirements and technical details and > correctly configuring the security policy, which in essence is a > whitelist of permissions. Such security policies are typically very > complicated in enterprise applications that change frequently and > integrate with numerous different systems and components. The > *operational cost* of correctly configuring and maintaining such > security policies is so high that Security Manager is rarely deployed > in production environments [6 > ] [7 > ]. > I would elaborate that the above problems with SecurityManager have been address in practice, as we've had many years to address them, these solutions are not included with Java of course.? The responsibility is not with the user, but developers and administrators. Also it has become apparent to me, that Java is following in the footsteps of Unix.?? First workstations were replaced by cheaper PC's, so the workstation market was lost, then the PC version of Unix, Linux ate Unix's lunch in the Server market.? Java no longer has a client market, no longer on phones or the browser, some desktop deployments, it has largely retreated to servers.? Be careful not to diminish Java's market too much, lest Android eat Java's server market lunch.? Android has a newer fine grained security model, I don't know if it can be applied to a server environment.?? I don't mean to be inflammatory, just giving you ammunition, should you require it. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. > > --Sean > > [1] > https://docs.oracle.com/en/java/javase/16/core/serialization-filtering1.html#GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A > [2] https://inside.java/2021/04/06/record-serialization-in-practise/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.firmstone at zeus.net.au Mon May 3 22:42:59 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 4 May 2021 08:42:59 +1000 Subject: Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization? In-Reply-To: References: <20210415180500.5D0DE3E00E5@eggemoggin.niobe.net> <64985afa-1d8b-cc6c-3283-4fd4ef0f5d1a@oracle.com> Message-ID: Clarification inline below On 4/05/2021 8:35 am, Peter Firmstone wrote: > On 4/05/2021 5:12 am, Sean Mullan wrote: >> -bcc jdk-dev >> -cc security-dev >> >> On 4/30/21 10:04 PM, Peter Firmstone wrote: >>> >>> >>> In our software we use a ProtectionDomain to represent a remote >>> server, because a thread only runs with the user's Subject (and that >>> Subject must be carefully preserved for other threads), there is no >>> way to represent the remote Server's Subject in a local domain , >>> other than with a ProtectionDomain. ? Our software is peer to peer, >>> clients can be servers and servers can also be clients.? Code to >>> interact with the server is downloaded via Maven and loaded.? Any >>> permission's granted to a user, are injected into the stack when run >>> as the client Subject, to authenticate the user for the server and >>> establish a secure connection, calls made by the client are run with >>> the user's Subject on the server, again for access control >>> purposes.? This functionality is beyond the capability of Java RMI, >>> we aren't using Java RMI to do this.? This is very important to >>> allow us to make fine grained access control decisions, or perform >>> event notification callbacks over secure connections, without this >>> feature, we can't make a secure connection with a callback, and you >>> know what happens when you have to do something, but cannot do it >>> securely??? We only grant network access directly back to the >>> server, downloaded code has been verified and is not expected to >>> cause denial of service, by consuming resources etc, but we don't >>> want to grant third party access to files, or random network >>> connections, we still have privacy obligations for third party >>> information. >>> >>> We can allow a third party to use unsigned certificates to sign >>> their jar files or use a checksum and we verify them using a secure >>> connection to the server, prior to loading. We then dynamically >>> grant permissions to the server's self signed Certificate (used to >>> sign the jar file), or a ProtectionDomain, after authenticating the >>> server and receiving a check sum or certificate from it.? So the >>> client authenticates the server using signed TLS certificates (EG by >>> letsencrypt.org or a trusted CA). We use self signed certificates on >>> Jar files if we sign them, we are actually trusting the server >>> entity in this case, eg a trusted company, but also placing >>> restrictions on them. >> >> I am probably missing something, but I don't understand how this is >> secure if you are using TLS server certificates as the basis for >> authenticating signed code. These are two very different use cases. > > > Clarifying the level of trust: > > 1. You have a trusted party, whom you trust to write their own code. > 2. You run that code on your systems dynamically. > 3. You trust the other party, but you either haven't or it's not > practical to audit their code. > 4. Using the principle of least privilege, you limit the ability of > the other party's code to ensure they are unable observe data they > shouldn't, eg a third party with whom you also do business. > 5. While a trusted party (eg a supplier) could write code that caused > denial of service, eg using up all available memory, there is no > motivation for them to do so.? However there may be motivation for > them to see quotes on your system from another supplier if they > have access to it. > > The code is loaded dynamically, but before the jvm loads it, we > authenticate the party that is asking us to load their code, after > which we are basically asking them the question, is this the code you > want us to load?? Please check that it hasn't been tampered with.?? > The trusted party gives us a checksum, or a self signed certificate > they used to sign the jar, we are then satisfied that we have received > the software unaltered from the trusted party and not a MITM attack, > so we load it.?? However we limit the permission of this software > using the principle of least privilege.?? They don't get file > permissions, they are only allowed to connect to the server they used > to authenticate with.? If a third party uses the same jar file, they > don't gain the permissions granted to other parties, as it will be > loaded into a separate ClassLoader with the permissions granted to > that party only. > Just to clarify, these are software logic interactions. > >> >>> If we remove access control, third parties will be able to open >>> local network connections and freely and use Java Serialization over >>> unsecured connections, exposing us to an attacker who can use a >>> gadget attack. Presently they cannot open a network connection, >>> access files or do much of anything without Permission.? All those >>> protections will be removed with this JEP. >>> >>> from >>> https://community.letsencrypt.org/t/do-you-support-code-signing/370 >>> >>>> Code-signing certificates as they?re used today are part of systems >>>> that try to decide whether a software source is malicious or >>>> legitimate. I don?t think Let?s Encrypt could easily play that kind >>>> of role when issuing certificates free of charge with an automated >>>> process without checking the real-world identity of the applicant. >>>> We could confirm that a code signing certificate applicant controls >>>> a domain name like iurewnrjewknkjqoiw.biz 408 >>>> , but that doesn?t give users or >>>> operating system developers much ability to know whether software >>>> that that applicant publishes is trustworthy or malicious. >>> >>> The JVM is one of very few platforms that has sufficient capability >>> to allow us to do this. >>> >>> If I could chose my pain, I would chose to remove Java Serialization >>> first, before SecurityManager because while I understand the >>> maintenance burden needs to be reduced for the ongoing viability of >>> the Java platform, security is still of utmost importance, as the >>> vulnerabilities of Java Serialization killed of client development. >> >> I don't think it is appropriate to block deprecation of the Security >> Manager until serialization is removed. Note that we have added >> mechanisms such as Serialization Filters [1] to help applications >> secure their serialization dependencies and that do not require a >> Security Manager to be enabled. We also are continuing to look at >> other improvements in this area, as well as introducing new features >> such as Records that can be serialized more securely [2]. > > I'm not suggesting blocking deprecation of SecurityManager, I'm > requesting blocking removal of SecurityManager until after > Serialization has been removed.?? So deprecate SecurityManager, just > don't mark it for removal yet.? Please mark SecurityManager for > removal after Serialization has been removed.?? What follows is the > reasoning for my request. > > We currently use SecurityManager and policy to prevent un-trusted > connections which could otherwise use serialization or access > sensitive data. ?? We only allow a limited subset re-implementation of > serialization over trusted connections and permission must be granted > before it can be used.? No trust established (TLS), then no > Serialization.? Because we load code dynamically, we will not be able > to profile it in advance, so we cannot create serialization whitelists > because we have no way of knowing class names in advance, our only > choice will be to disable Serialization entirely.?? At least with > security policy, we can establish the permissions in advance. > > Presently the dynamically loaded code, contains a list of requested > Permissions in META-INF, however they may not be granted, the security > policy has a list of Permission's that are allowed to be granted based > on the remote principal, the permissions granted will be the > intersection of these two lists, requested and allowed permissions.? > We can log permissions that are not granted.? This occurs dynamically > at runtime.? A Permission requested may also be a subset of the > Permissions allowed, because of implies checks.? So dynamically loaded > code really does operate under least privilege principles.? You can't > do that with Serialization filtering. > > Prior to the introduction of the Serialization's filtering mechanism, > I re-implemented a subset of Java Serialization, focused on addressing > vulnerabilities caused by gadget attacks. > > We did this when other companies solutions to addressing Java > vulnerabilities was to remove Java altogether, which is why Java > applets are no longer used.? Instead, we knuckled down and addressed > the vulnerabilities. > > I had to remove circular links because they introduce security > vulnerabilities, I also limited the number of bytes the stream can > download before it must be reset, otherwise an IOException is thrown > and control is returned to the caller.? It uses constructors, and all > classes are expected to validate invariants.? We've discussed it > previously.? Apart from Collection classes, serial form of existing > classes has not been altered, instead classes have new Constructor's > that are used to validate their de-serialized fields.? All fields have > also undergone their own validation process.? J.B. called it atomic > serialization, when we first discussed it, so that's what we call it. > > My first step was to re-implement deserialization and use that for > some time with the new deserialization public API,? I'm currently > implementing a public API for serialization.? After this I will > introduce more serialization protocols that use the same API, at that > time I may have to change the serial form of some classes, as Java > serialization had a lot of complex features that other serialization > protocols lack.? The deserialization api, is capable of supporting > multiple serial forms, to allow class implementations to change them. > > Certain Java Collection classes are vulnerable to denial of service > attacks, so they are not serialized, instead I have serializers that > transfer the data, which is validated during deserialization, before > populating the Java Collection classes via constructors.? This means > any Collection class can be serialized, even those that don't > implement Serializable, they all have the same serial form, so their > serialized form basically respects the Collection interfaces of Map, > Set and List, their bytes can be compared for equality, for example if > two Map's are equal, their serialized bytes will also be equal. > > Furthermore serialization filters have the same complexity flaws as > the Security Manager model, but in our case we use SecurityManager to > grant a limited set of privileges that we are able to establish prior > to loading dynamic code.??? We already have a profiling tool that > generates policy files. > > Once SecurityManager is removed, third party code will have all > permission's granted to the JVM, so they will be able to view files > and make network connections.?? The serialization filters offer a > similar level of complexity, but with less protection and less time > for tool development.? No doubt this will require us to rethink the > structure of our software and access control to sensitive data. > > Once we fixed Policy performance issues and created profiling tools > for initial creation of policy files, which are used as a guide to > create the requested permission lists and enable permissions to be > granted dynamically at runtime, security becomes a significant benefit > rather than a burden. > > To quote waratek: reference > https://www.waratek.com/java-serialization-filtering/ > >> To configure Serialization Filtering, the application needs to first >> be fully profiled. *Profiling* an app can be a complex process that >> requires specialized tools and has to be performed by domain experts. >> Typically, the process requires the app to run normally for a period >> of time in order for all its paths to be executed. A dynamic >> profiling tool can log the class names that are required for normal >> operation. This list of class names will then be the basis of >> configuring the white/black list of the Serialization Filters. And >> even after going through this process, there is no guarantee that all >> of the execution paths were run and all the required class names were >> logged. Of course, the same process needs to be performed every time >> a new release goes into production or even when a third-party library >> must be upgraded. The lifecycle of this process becomes even more >> complex since such any change in the Serialization Filters will first >> need to go through QA and UAT before it reaches production. >> >> The Serialization Filtering mechanism follows a very similar approach >> to the Security Manager >> . >> The Security Manager also works based on a whitelist >> >> and suffers from the same scalability problems. Java?s Security >> Manager has proved to be unsuitable for enterprise, large-scale >> environments, given that *it moves the responsibility of protecting >> the system to the user*. The user is responsible for understanding >> the application?s security requirements and technical details and >> correctly configuring the security policy, which in essence is a >> whitelist of permissions. Such security policies are typically very >> complicated in enterprise applications that change frequently and >> integrate with numerous different systems and components. The >> *operational cost* of correctly configuring and maintaining such >> security policies is so high that Security Manager is rarely deployed >> in production environments [6 >> ] [7 >> ]. >> > > I would elaborate that the above problems with SecurityManager have > been address in practice, as we've had many years to address them, > these solutions are not included with Java of course.? The > responsibility is not with the user, but developers and administrators. > > Also it has become apparent to me, that Java is following in the > footsteps of Unix.?? First workstations were replaced by cheaper PC's, > so the workstation market was lost, then the PC version of Unix, Linux > ate Unix's lunch in the Server market. Java no longer has a client > market, no longer on phones or the browser, some desktop deployments, > it has largely retreated to servers.? Be careful not to diminish > Java's market too much, lest Android eat Java's server market lunch.? > Android has a newer fine grained security model, I don't know if it > can be applied to a server environment.?? I don't mean to be > inflammatory, just giving you ammunition, should you require it. > > -- > Regards, > > Peter Firmstone > Zeus Project Services Pty Ltd. > > >> >> --Sean >> >> [1] >> https://docs.oracle.com/en/java/javase/16/core/serialization-filtering1.html#GUID-3ECB288D-E5BD-4412-892F-E9BB11D4C98A >> [2] https://inside.java/2021/04/06/record-serialization-in-practise/ -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron.pressler at oracle.com Mon May 3 23:24:55 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Mon, 3 May 2021 23:24:55 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: On 29 Apr 2021, at 13:06, Peter Firmstone > wrote: Is there a simpler way to limit permissions of library code? Limiting permissions of library code is a spectacular idea, and the stack-dependent deep sandbox offered by the Security Manager is the most spectacular software sandbox ever created. The problem is that while the idea is terrific, it does not seem to work in practice in any way that is simple and scalable enough to give assured security for applications written by millions of developers. That a select few could, perhaps, use it to build secure systems while the rest just get a false impression of security is not a viable security strategy for a popular platform. There are simpler, and therefore more scalably-secure ways to either sandbox an application or restrict the Java APIs accessible to untrusted plugins. I don?t believe that semi-trusting and selectively sandboxing third-party libraries that otherwise make use of the full range of Java?s core APIs is cost-effective and obviously secure. Companies need SMT solvers these days to check the security of policy files that are much simpler than those that would be required to sandbox arbitrary third-party libraries. Perhaps if we instead address the performance and usability issues, we could improve adoption,so it adds to Java's appeal, rather than detracting from it? Let's take is as a given that everyone here is interested in adding to Java?s appeal, yet there might be disagreement over which decision would do that. Clearly, those who propose removing the Security Manager believe it will add to Java?s appeal, if for no other reason than freeing resources to features many people actually use, while also having a positive effect on security. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Tue May 4 00:59:52 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 4 May 2021 00:59:52 GMT Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey 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 test/jdk/sun/security/pkcs11/Provider/Login.java line 52: > 50: } > 51: System.out.println("Finish: "+ weakRef.refersTo(null)); > 52: } What is this particular block of code for? main(Provider) is non-static and may be called more than once, but then you store the passed-in Provider object into a static field? Also, must the static field use type SunPKCS11? It seems AuthProvider is sufficient and most of the "ap->pkcs11Provider" changes can be avoided? test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 2: > 1: /* > 2: * Copyright (c) 2003, 2016, Oracle and/or its affiliates. All rights reserved. New file, should just be 2021? ------------- PR: https://git.openjdk.java.net/jdk/pull/3544 From valeriep at openjdk.java.net Tue May 4 01:08:49 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 4 May 2021 01:08:49 GMT Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider In-Reply-To: References: Message-ID: <6U2p9r-LkayIrZhrzjtC9nRqg5JvC3pHOJj51wIQlg8=.f8c076bc-6417-480d-ab2a-224a92fb0246@github.com> On Fri, 16 Apr 2021 11:24:57 GMT, Sean Coffey 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 test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 42: > 40: import jdk.test.lib.util.ForceGC; > 41: > 42: public class MultipleLogins extends PKCS11Test { The overall pattern seems a bit different from the typical PKCS11Test usage pattern. When a class extends PKCS11Test, the main test functionality is under its main(Provider) method. It is expected that the PKCS11Test class will call the main(Provider) method with the to-be-tested PKCS11 provider obj. Here it seems that you are doing that in the static main(String[]) method. Do you really need to extend PKCS11Test then? ------------- PR: https://git.openjdk.java.net/jdk/pull/3544 From peter.firmstone at zeus.net.au Tue May 4 02:49:14 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 4 May 2021 12:49:14 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: Thanks Ron, more discussion below. On 4/05/2021 9:24 am, Ron Pressler wrote: > > >> On 29 Apr 2021, at 13:06, Peter Firmstone >> > wrote: >> >> Is there a simpler way to limit permissions of library code? >> > > Limiting permissions of library code is a spectacular idea, and the > stack-dependent deep sandbox offered by the Security Manager > is the most spectacular software sandbox ever created. The problem is > that while the idea is terrific, it does not seem to work > in practice in any way that is simple and scalable enough to give > assured security for applications written by millions of developers. > That a select few could, perhaps, use it to build secure systems while > the rest just get a false impression of security is not a viable > security strategy for a popular platform. > I would argue that it is not just an idea, that we have been able to successfully use it in practice and have had enough time to write tools and develop software to get around the shortcomings of what ships by default with Java. Assured security is a dreamer's paradise, one morning to awaken with their reputation in tatters, and anyone who believes the dreamer is similarly disillusioned, it is only possible to make life very difficult for a determined attacker, in the hope they will go elsewhere, it's an evolutionary arms race. Developers who deploy security features, don't advertise it, doing so provides information for would be attackers and those who don't value security have little to protect.?? Therefore removing SecurityManager will have a delayed, but unexpected response, most developers haven't kept up with the pace of Java's development. Most changes to date have been very positive for Java, I'm looking forward to using the new Vector API. :) Java's policy provider isn't scalable, but we shouldn't use that as an example.? I can argue that Map isn't scalable because Hashtable isn't, while ignoring ConcurrentHashMap, I'm sure someone would correct me. Present me with an application that has trouble scaling and I will provide SecurityManager and Policy provider implementations that scale as well as the JVM can without a SecurityManager (once warmed up of course).?? There is a negligible performance penalty, but we're talking scalability.? Happy to accept a challenge. AccessController scales nicely.? I'm sure John Rose has had something to do with that, thank you John, it wasn't a wasted effort. The built in Java policy provider is static, therefore all permissions need to be known prior, but this was always just a toy, that's why there's a policy provider interface, it was understood from the beginning.? Our policy provider is dynamic, permissions are granted at runtime.? We also have a profiling tool that creates a policy file, to be edited of course, takes out all the guess work.?? I've attached two examples, took 5 minutes to produce, easy-peasy.? No I've never used the policy editing tool lol :)? That too was just a toy. If you read the generated policy files attached, you'll also notice some viral leaked permissions from Java platform code, note that my code only uses Java's public API, no implementation API's from jdk.internal.reflect or sun.* package namespaces are accessed directly. Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. I can say that I'm relatively confident that I use it correctly, feel free to point out where I'm doing it wrong of course https://github.com/pfirmstone/JGDMS Java's? security capabilities will be reduced as a result of SecurityManager's removal and I understand that we will no longer be able to provide fine grained access control to sensitive data and as security is intertwined throughout our software, that it will have significant impact.? I don't know how to replace that functionality, I've got nothing, zero, zit, zilch, nada. SecurityManager is not a theoretical feature that no one uses. Lets drop the excuses that it's just a theoretical, impractical thing that nobody uses, and say instead that we know that this does something important, it is very powerful, it is a deployed API that is in use, probably the only least privileged protection domain model that really works, but we are no longer supporting it moving forward because it is not well understood by those maintaining it and for this reason it creates a significant maintenance burden. > > There are simpler, and therefore more scalably-secure ways to either > sandbox an application or restrict the Java APIs > accessible to untrusted plugins. I don?t believe that semi-trusting > and selectively sandboxing third-party libraries that otherwise > make use of the full range of Java?s core APIs is cost-effective and > obviously secure. Companies need SMT solvers these days to > check the security of policy files that are much simpler than those > that would be required to sandbox arbitrary third-party libraries. Please provide some examples,? migration options suggestions will be appreciated. I'm only aware of simpler and therefore less secure ways. Scalability is not a valid argument, my implementation scales. I have a profiling tool that creates policy files, then you edit it, it's not that hard.? If you don't have a tool like that, then I can see it would be difficult, but that's why we learn to code, to automate manual tasks?? The more difficult component for developers is preserving a subject across threads preserving context and using privileged calls.? You need that for TLS connections.? That will still have to happen after SecurityManager's removal. But if you think having to preserve a Subject between threads is a chore, I have to preserve Subject's in threads on other JVM's. The SecurityManager is only one of the tools developers must consider for security, one must also be careful to validate invariants during construction and avoid shared access to mutable state. I think static analysis security auditing tools would be useful, to help developers. > >> Perhaps if we instead address the performance and usability issues, >> we could improve adoption,so it adds to Java's appeal, rather than >> detracting from it? >> > > Let's take is as a given that everyone here is interested in adding to > Java?s appeal, yet there might be disagreement over which > decision would do that. Clearly, those who propose removing the > Security Manager believe it will add to Java?s appeal, if for no > other reason than freeing resources to features many people actually > use, while also having a positive effect on security. IMHO Removal of SecurityManager will make Java less appealing to developers because it breaks the promise that our existing software will continue to work on later versions.?? See now you're not just removing something that has a good reason for removal, that was implemented badly, and has been replaced by a better API, this time it's different. With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses.? Removing Serialization has greater appeal :) This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. Removing SecurityManager has a significantly negative effect on security for me, just so you know.? I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager.? The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager.? I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1092", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1094", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1095", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1103", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1104", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1106", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar" { permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "setIO"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041128016443", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "setPolicy"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.defaultTestConfig", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "testConfiguration", "read"; permission java.util.PropertyPermission "testFailureAnalyzers", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; }; grant codebase "jrt:/jdk.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/classserver-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1094", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1095", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1103", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1104", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1106", "accept,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission java.lang.RuntimePermission "createClassLoader"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission java.lang.RuntimePermission "createClassLoader"; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "jrt:/java.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "setLoginConfiguration"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessSystemModules"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.nio"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "loggerFinder"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "readFileDescriptor"; permission java.lang.RuntimePermission "reflectionFactoryAccess"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.RuntimePermission "writeFileDescriptor"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getNetworkInformation"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache1725612075511757359.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache1725612075511757359.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache1725612075511757359.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache3423522293513651042.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache3423522293513651042.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache3423522293513651042.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jinitests.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041128016443", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.crypto.policy"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred"; permission java.security.SecurityPermission "getProperty.jdk.serialFilter"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.login.config.url.1"; permission java.security.SecurityPermission "getProperty.login.configuration.provider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.securerandom.source"; permission java.security.SecurityPermission "getProperty.security.provider.1"; permission java.security.SecurityPermission "getProperty.security.provider.10"; permission java.security.SecurityPermission "getProperty.security.provider.11"; permission java.security.SecurityPermission "getProperty.security.provider.12"; permission java.security.SecurityPermission "getProperty.security.provider.13"; permission java.security.SecurityPermission "getProperty.security.provider.14"; permission java.security.SecurityPermission "getProperty.security.provider.2"; permission java.security.SecurityPermission "getProperty.security.provider.3"; permission java.security.SecurityPermission "getProperty.security.provider.4"; permission java.security.SecurityPermission "getProperty.security.provider.5"; permission java.security.SecurityPermission "getProperty.security.provider.6"; permission java.security.SecurityPermission "getProperty.security.provider.7"; permission java.security.SecurityPermission "getProperty.security.provider.8"; permission java.security.SecurityPermission "getProperty.security.provider.9"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SUN"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "putProviderProperty.SunJCE"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunJSSE"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunRsaSign"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.security.SecurityPermission "setPolicy"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.util.PropertyPermission "*", "read,write"; permission java.util.logging.LoggingPermission "control"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1092", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1094", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1095", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1103", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1104", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1106", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "jrt:/jdk.localedata" { permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "jrt:/java.smartcardio" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1092", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1094", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1095", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1103", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1104", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1106", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1107", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1123", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1176", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1187", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1188", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1198", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar" { permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1107", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1123", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1176", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1187", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1188", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1198", "accept,resolve"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar" { permission java.lang.RuntimePermission "createClassLoader"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; }; grant codebase "jrt:/jdk.security.auth" { permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; }; grant codebase "jrt:/java.xml.crypto" { permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.util.PropertyPermission "java.specification.version", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1092", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1101", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1107", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1123", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1176", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1187", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1188", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1198", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar;md5=02e8620ac1109684fa26b78ee6e69387" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar" { permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "shutdownHooks"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1107", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1123", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1176", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1187", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1188", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1198", "accept,resolve"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission java.lang.RuntimePermission "createClassLoader"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=336e846557a89bbdfad2070befb358a1" { permission java.lang.RuntimePermission "createClassLoader"; }; -------------- next part -------------- grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "jrt:/jdk.localedata" { permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1093", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "shutdownHooks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar" { permission org.apache.river.jeri.internal.EndpointInternalsPermission "get"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin"; permission net.jini.security.AccessPermission "org.apache.river.admin.DestroyAdmin.destroy"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission java.security.SecurityPermission "getPolicy"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1097", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1117", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:4160", "listen,resolve"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission java.security.SecurityPermission "getPolicy"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime"; }; grant codebase "jrt:/java.smartcardio" { permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; }; grant codebase "jrt:/jdk.security.jgss" { permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "get"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1093", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "exitVM.0"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar;sha=2d4933c826a47df4166159c612c71f164cf71677" { permission java.lang.RuntimePermission "createClassLoader"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.lang.RuntimePermission "createClassLoader"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "*", "read,write"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read"; permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getNetworkInformation"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "get"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.crypto.policy"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred"; permission java.security.SecurityPermission "getProperty.jdk.serialFilter"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.login.config.url.1"; permission java.security.SecurityPermission "getProperty.login.configuration.provider"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.policy.url.1"; permission java.security.SecurityPermission "getProperty.policy.url.2"; permission java.security.SecurityPermission "getProperty.policy.url.3"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.securerandom.source"; permission java.security.SecurityPermission "getProperty.security.provider.1"; permission java.security.SecurityPermission "getProperty.security.provider.10"; permission java.security.SecurityPermission "getProperty.security.provider.11"; permission java.security.SecurityPermission "getProperty.security.provider.12"; permission java.security.SecurityPermission "getProperty.security.provider.13"; permission java.security.SecurityPermission "getProperty.security.provider.14"; permission java.security.SecurityPermission "getProperty.security.provider.2"; permission java.security.SecurityPermission "getProperty.security.provider.3"; permission java.security.SecurityPermission "getProperty.security.provider.4"; permission java.security.SecurityPermission "getProperty.security.provider.5"; permission java.security.SecurityPermission "getProperty.security.provider.6"; permission java.security.SecurityPermission "getProperty.security.provider.7"; permission java.security.SecurityPermission "getProperty.security.provider.8"; permission java.security.SecurityPermission "getProperty.security.provider.9"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SUN"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "putProviderProperty.SunJCE"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunJSSE"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunRsaSign"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "setLoginConfiguration"; permission java.util.logging.LoggingPermission "control"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1093", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessSystemModules"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "exitVM.0"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.nio"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "loggerFinder"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "reflectionFactoryAccess"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "loadLibrary.sunec"; }; grant codebase "jrt:/jdk.security.auth" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getProtectionDomain"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar" { permission java.util.PropertyPermission "*", "read,write"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6039440544431131695.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "get"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.policy.url.1"; permission java.security.SecurityPermission "getProperty.policy.url.2"; permission java.security.SecurityPermission "getProperty.policy.url.3"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.util.logging.LoggingPermission "control"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "exitVM.0"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission java.security.SecurityPermission "getPolicy"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1097", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1117", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:4160", "listen,resolve"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Reggie" { permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.security.SecurityPermission "getPolicy"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";"; permission javax.security.auth.AuthPermission "getSubject"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1102", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1105", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1115", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1122", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1166", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1179", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1186", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1197", "accept,resolve"; permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:4160", "listen,resolve"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "doAsPrivileged"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar" { permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.policy", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass"; permission java.security.SecurityPermission "setPolicy"; permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1093", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:1199", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "exitVM.0"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases"; }; grant codebase "jrt:/java.security.jgss" { permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant principal javax.security.auth.x500.X500Principal "CN=Tester" { permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin"; permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getClassAnnotation"; permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getEncodedCerts"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.notiFy"; permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.register"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:"; }; grant codebase "jrt:/java.xml.crypto" { permission java.util.PropertyPermission "java.specification.version", "read"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; }; From alanb at openjdk.java.net Tue May 4 08:23:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 08:23:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 15:20:42 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 two additional commits since the last revision: > > - Revert bad change in benchmark copyright > - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value Just to double, there is no way to enable native access for modules in module layers (other than the boot layer), right? src/java.base/share/classes/java/lang/Module.java line 115: > 113: > 114: // is this module a native module > 115: private volatile boolean enableNativeAccess = false; Can you drop "= false", it's not needed and I don't think we want a volatile-write here. Also the comment may date from a previous iteration as there isn't any concept of a "native module". src/java.base/share/classes/java/lang/System.java line 2346: > 2344: public boolean isEnableNativeAccess(Module m) { > 2345: return m.isEnableNativeAccess(); > 2346: } Can you move this up so they are with the other Module methods? src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: > 32: import java.util.Set; > 33: > 34: public final class IllegalNativeAccessChecker { Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 47: > 45: private static IllegalNativeAccessChecker checker; > 46: > 47: static Collection enableNativeAccessModules() { I assume this can be changed to Iterable as you don't want anything outside of this class changing the collection. src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 889: > 887: } else { > 888: // silently skip. > 889: // warnUnknownModule(ENABLE_NATIVE_ACCESS, name); Maybe for later but the other options do emit a warning when unknown module is specified. If the decoding of this command line option is moved to ModuleBootstrap then most of this class will go away and you will be able to use warnUnknownModule. src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 113: > 111: if (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) { > 112: String moduleName = module.isNamed()? module.getName() : "UNNAMED"; > 113: throw new IllegalCallerException("Illegal native access from module: " + moduleName); "UNNAMED" is a bit inconsistent with the other exception messages. Can you just use Module::toString here instead, meaning "Illegal native access from " + module ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 09:54:04 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 09:54:04 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 08:20:43 GMT, Alan Bateman wrote: > Just to double, there is no way to enable native access for modules in module layers (other than the boot layer), right? No, at the moment it is not possible to enable native access programmatically. We will explore something along those lines in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 10:06:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 10:06:25 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v8] In-Reply-To: References: Message-ID: > 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 two additional commits since the last revision: - Remove redundant initializer in Module - Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/793ea5c5..6a659d87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=06-07 Stats: 19 lines in 3 files changed: 6 ins; 11 del; 2 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 From mcimadamore at openjdk.java.net Tue May 4 11:58:22 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 11:58:22 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v9] In-Reply-To: References: Message-ID: > 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 three additional commits since the last revision: - Tweak code some more - Use uniform naming convention for implementation metods in Module - Remove IllegalNativeAccessChecker ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/6a659d87..ead71078 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=07-08 Stats: 169 lines in 5 files changed: 41 ins; 114 del; 14 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 From mcimadamore at openjdk.java.net Tue May 4 12:05:16 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 12:05:16 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> On Tue, 4 May 2021 08:12:23 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: >> >> - Revert bad change in benchmark copyright >> - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value > > src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: > >> 32: import java.util.Set; >> 33: >> 34: public final class IllegalNativeAccessChecker { > > Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. I've decided to drop this class and move the logic in ModuleBootstrap. To handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED module and set the flag there when decoding the command line option. This seems to be consistent with what is done in other areas. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 12:05:15 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 12:05:15 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10] In-Reply-To: References: Message-ID: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> > 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: Tweak comment in Module::enableNativeAccess ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/ead71078..2a31da40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=08-09 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 From alanb at openjdk.java.net Tue May 4 14:24:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:24:56 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v10] In-Reply-To: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> References: <-ForVlVYhV48Iw44ATh9hmpPNNDJsl3UZnte-RLtuRA=.44826ded-dbaa-4b8a-b58e-473f8ce4a991@github.com> Message-ID: On Tue, 4 May 2021 12:05:15 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: > > Tweak comment in Module::enableNativeAccess src/java.base/share/classes/jdk/internal/reflect/Reflection.java line 112: > 110: Module module = currentClass.getModule(); > 111: if (!SharedSecrets.getJavaLangAccess().isEnableNativeAccess(module)) { > 112: throw new IllegalCallerException("Illegal native access from module: " + module); You may want to drop "module" from the exception message as Module::toString is specified to return "module XXXX" or "unnamed module XXXX" so you'll end up duplication "module" in the message. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From alanb at openjdk.java.net Tue May 4 14:24:55 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 4 May 2021 14:24:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> References: <6prALGyA4mz4fP09-t2OrUtApa_WW7iRKsw2lhmilUA=.3ac938b7-422f-4a3d-942b-16bd8c5fd3c6@github.com> Message-ID: On Tue, 4 May 2021 12:01:44 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 34: >> >>> 32: import java.util.Set; >>> 33: >>> 34: public final class IllegalNativeAccessChecker { >> >> Are you sure about the name of the this class? It doesn't do any checking and it's not concerned with "illegal native access" either, instead it just provides access to the names of modules that have been granted native access. > > I've decided to drop this class and move the logic in ModuleBootstrap. To handle unnamed modules, I had to piggy back on the special static ALL_UNNAMED module and set the flag there when decoding the command line option. This seems to be consistent with what is done in other areas. Good, this looks much simpler now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue May 4 14:37:25 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 4 May 2021 14:37:25 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v11] In-Reply-To: References: Message-ID: > 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 message string in Reflection::ensureNativeAccess ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/2a31da40..72eb9bbc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=09-10 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 From cronier.jy at gmail.com Mon May 3 17:16:52 2021 From: cronier.jy at gmail.com (Jean-Yves Cronier) Date: Mon, 3 May 2021 19:16:52 +0200 Subject: Fwd: Java Bug : Mutual HTTPS authentication not possible with a non-extractable private key with Apple/KeychainStore References: <254BEC5E-C3DD-4884-9045-40B94A694CCB@oracle.com> Message-ID: <2FD2B199-EF5E-446E-A474-FF09C766F159@gmail.com> Following the advice of Wei-Jun Wang, I share/forward to this mailing-list, details of a problem that I encounter on MacOS. At the moment, I don't know how to modify the existing code so that the Apple Provider can behave like SunMSCAPI > D?but du message r?exp?di? : > > De: Wei-Jun Wang > Objet: R?p. : Java Bug : Mutual HTTPS authentication not possible with a non-extractable private key with Apple/KeychainStore > Date: 3 mai 2021 ? 18:11:12 UTC+2 > ?: Jean-Yves Cronier > > And BTW, it?s better to write to an area-specific mail list next time when you find an issue in OpenJDK. The jdk-dev@ mail list is probably too big and people discuss more grand things there. :-) > > For security, it?s security-dev at openjdk.java.net. > > Thanks, > Weijun > >>>> Le 3 mai 2021 ? 16:03, Wei-Jun Wang a ?crit : >>>> >>>> Hi Jean-Yves, >>>> >>>> On macOS there?s only native key/certificate management but no signature signing/verification. If you look at https://docs.oracle.com/javase/9/security/oracleproviders.htm, the Apple provider only implements KeyStore. If you need to use a key in client auth, it needs to extract that key and use another provider (SunRsaSign or SunEC) to use it. >>>> >>>> On the other hand, SunMSCAPI has implemented both KeyStore and Signature, therefore it can do both things inside the provider and the key does not need to be extracted. >>>> >>>> I?ve filed https://bugs.openjdk.java.net/browse/JDK-8266439. >>>> >>>> Thanks, >>>> Weijun >>>> >>>>> On May 1, 2021, at 8:19 AM, Jean-Yves Cronier wrote: >>>>> >>>>> Description >>>>> >>>>> I have imported my personal certificate in macOS keychain with "non-extractable" option (cf. https://ss64.com/osx/security-export.html). >>>>> Private key is now protected, and we can't export private key from macOS KeyChain >>>>> But I am unable to establish connexion with a web-API which require client certificate for mutual authentication with Java >>>>> It work perfectly well with curl/git, and browsers (safari/chrome) >>>>> >>>>> >>>>> <>System / OS / Java Runtime Information >>>>> >>>>> openjdk 11.0.11 >>>>> macOS 11.3 >>>>> >>>>> >>>>> <>Steps to Reproduce >>>>> >>>>> 1. Add personal certificate with "non-extractable" option. Example with a personal certificate sent to me in a P12 file named "my-certificate.p12", with following command-line: >>>>> security import my-certificate.p12 -x -P ? my-strong-password" >>>>> 2. Connect a site require mutual authentication (for example : https://server.cryptomix.com/secure/ ) >>>>> >>>>> >>>>> <>Expected Result >>>>> >>>>> Display content detail of selected client certificate >>>>> >>>>> >>>>> <>Actual Result >>>>> >>>>> Error: No TLS client certificate presented >>>>> >>>>> >>>>> <>Source code for an executable test case >>>>> >>>>> import javax.net.ssl.HttpsURLConnection; >>>>> import java.io.IOException; >>>>> import java.net.URL; >>>>> import java.security.cert.X509Certificate; >>>>> >>>>> public class MutualAuthenticationTest { >>>>> public static void main(String[] args) throws IOException { >>>>> System.setProperty("javax.net.ssl.keyStoreType", "KeychainStore"); >>>>> System.setProperty("javax.net.ssl.keyStore", "NONE"); >>>>> System.setProperty("javax.net.ssl.keyStorePassword", "-"); >>>>> testUrl(new URL("https://server.cryptomix.com/secure/")); >>>>> } >>>>> >>>>> public static void testUrl(URL targetUrl) throws IOException { >>>>> HttpsURLConnection con = (HttpsURLConnection) targetUrl.openConnection(); >>>>> // Open the connection >>>>> con.getResponseCode(); >>>>> >>>>> assert con.getLocalCertificates() != null && con.getLocalCertificates().length > 0 : "Must use a personnel certificate for mutual authentication"; >>>>> X509Certificate personalCertificate = (X509Certificate) con.getLocalCertificates()[0]; >>>>> assert personalCertificate.getSubjectDN() != null; >>>>> } >>>>> } >>>>> >>>>> >>>>> <>Workaround >>>>> >>>>> No possible workaround on MacOS which Apple/KeychainStore >>>>> NB : Perfectly work on Windows/MSCAPI with personnel certificate (with non-exportable private key option) >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fguallini at openjdk.java.net Tue May 4 15:19:07 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Tue, 4 May 2021 15:19:07 GMT Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption Message-ID: test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame With this changeset, the server is checking whether the client thread has initiated handshake, and retrying if needed after waiting a short time. In addition, the test is now reusing SSLSocketTemplate to simplify sockets configuration and client/server synchronization ------------- Commit messages: - close socket after handshake started Changes: https://git.openjdk.java.net/jdk/pull/3856/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3856&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8164804 Stats: 103 lines in 1 file changed: 39 ins; 50 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3856/head:pull/3856 PR: https://git.openjdk.java.net/jdk/pull/3856 From dfuchs at openjdk.java.net Tue May 4 16:12:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 4 May 2021 16:12:51 GMT Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption In-Reply-To: References: Message-ID: On Tue, 4 May 2021 15:12:39 GMT, Fernando Guallini wrote: > test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame > > With this changeset, the server is checking whether the client thread has initiated handshake, and retrying if needed after waiting a short time. In addition, the test is now reusing SSLSocketTemplate to simplify sockets configuration and client/server synchronization test/jdk/sun/security/ssl/SSLSocketImpl/CloseSocket.java line 45: > 43: public class CloseSocket extends SSLSocketTemplate { > 44: > 45: private static Thread clientThread = null; Shouldn't this variable be `volatile`? If I'm not mistaken it's set in one thread and potentially read in a different thread? An alternative could be to use a CountDownLatch instead. ------------- PR: https://git.openjdk.java.net/jdk/pull/3856 From ron.pressler at oracle.com Tue May 4 16:39:14 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Tue, 4 May 2021 16:39:14 +0000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> Message-ID: <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> On 4 May 2021, at 03:49, Peter Firmstone > wrote: Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. The Security Manager hasn?t been a central part of Java?s server-side security for years. Some of the most critical and best-secured systems in the world are written in Java, and they don?t use the Security Manager, so let?s not equate a particular sandboxing mechanism designed for untrusted code with security. Lets drop the excuses that it's just a theoretical, impractical thing that nobody uses, and say instead that we know that this does something important, it is very powerful, it is a deployed API that is in use, probably the only least privileged protection domain model that really works, but we are no longer supporting it moving forward because it is not well understood by those maintaining it and for this reason it creates a significant maintenance burden. I have to disagree on all counts here. Also, I want to emphasise that if Security Manager were an important security feature for Java these days, then ?some people have been able to make it effective? is the very opposite of ?works? when it comes to security and a mainstream language. You can believe that the maintainers misunderstand this feature ? that is a very bold claim ? but even if it were true it doesn?t change the following empirical facts: 1. SM is not used as a central security Java feature, 2. It is used at all by very few projects, and 3. it is a heavy maintenance burden. Maybe the reasons for these is misunderstanding or general incompetence but that doesn?t change the reality. Please provide some examples, migration options suggestions will be appreciated. I?ve jotted down some thoughts in a blog post: https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses. Removing Serialization has greater appeal :) This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. Removing SecurityManager has a significantly negative effect on security for me, just so you know. I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. Not everyone has to agree on every priority decision, and the process doesn?t require convincing every last Java developer. But it is not sudden, and there will be alternatives for those aspects of Security Manager that many people use. I don?t think it is fair to harm millions of Java developers by diverting resources from features they want to features very few people want, as long as a reasonable removal process is employed, and I think it is here. Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager. The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. I disagree. Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager. I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. I wouldn?t say Java (or anything else, for that matter) is ?able" to do it now, except in the sense that people (scientists) are able (in a billion- dollar particle accelerator) to transmute lead into gold (a few atoms). We?ve had twenty five years to convince the world this could work, the world isn?t buying, and our job isn?t to sell ideas but to serve millions of developers. It?s time to move on. ? Ron -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbray at textuality.com Tue May 4 18:48:44 2021 From: tbray at textuality.com (Tim Bray) Date: Tue, 4 May 2021 11:48:44 -0700 Subject: Tentative suggestion: Make X509Key.getKey() non-protected Message-ID: Pardon the interruption. I'm working on a social-media identity federation project involving zero-knowledge proofs where you post public-key/nonce/sig combinations to multiple places to prove the poster identities' shared ownership of a private key. Details (not really relevant to the following): https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity The representation of the public key needs to be textual. The most straightforward way to do that is a one-liner like so: Base64.getEncoder().encodeToString(key.getEncoded()) which gives you Base64'ed PKIX. Problem is, people are wondering why they need PKIX. They want to use EdDSA and they don't see the need for algorithm agility (there's a faction that thinks it's actively harmful) and point out that ed25119 keys are just 32 bytes worth of bits and don't see why they need to use Eighties technologies to express them in ASCII and ask "why can't I just base64 those bytes?" Which is straightforward in Go and JS and so on. It is however not straightforward in Java (unless I'm missing something obvious, wouldn't be surprising) because sun.security.x509.X509Key.getKey() is protected; see https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131 I have verified, via abuse of the reflection APIs, that the BitArray that call returns does indeed represent the appropriate 32 ed25519 bytes. So, I have an object that has the data that I need inside but for reasons of policy it is declining to reveal them. BTW you can do this in BouncyCastle and friends. Rather than changing protection on a long-established method, maybe a new public byte[] getKeyBytes() would be the thing to do? Or maybe it would be better to make this an EdDSA-specific operation? Maybe the EdDSA classes already provide a way to do this that I couldn't find? So, with an apology for possibly wasting your time, two questions: 1. Is there a principled Java 15 way to get the key bytes that I'm not smart enough to have found? 2. Failing that, would a proposal to allow access to un-PKIX'ed EdDSA key bytes be ruled out in principle for some good reason that I don't know about? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstjohns at comcast.net Tue May 4 19:30:29 2021 From: mstjohns at comcast.net (Michael StJohns) Date: Tue, 4 May 2021 15:30:29 -0400 Subject: Tentative suggestion: Make X509Key.getKey() non-protected In-Reply-To: References: Message-ID: <6126ff6a-c936-f6f2-fb6d-27d3b0de9fef@comcast.net> Hi Tim - Pardon the top posting, and I'm only speaking for myself, but your suggestion is unlikely to get any traction. First and most importantly, sun.security.x509 et al are non-public classes (e.g. not part of the JDK API, rather than a reference to their java tagging), and generally align their public behaviors with the API, and modify their private behaviors as necessary to make them more efficient etc.?? E.g. you can't even count on X509Key to exist from JDK to JDK as its possible that the plugin maintainer may completely refactor those classes at any time. Secondly, the API and the encoding of the public and private keys generally reflects what the various RFCs and other standards documents specify.? Most of the key material has multiple ways to encode it, but that's not the responsibility of either the JDK or the underlying plugins - they all support a common PKIX encoding basis and expect that "foreign" keys (e.g. keys originating outside of a given provider) will be encoded in the common fashion when they enter or leave the provider.???? It's left to the programmer to do whatever other encodings are necessary and to do the translations to and from those.? (I have personal code for translating between raw EC keys and at least two different forms of secure element native forms, as well as moving public key material in and out of smart cards in various formats). Third, yes it is 80s technology or earlier, but for better or worse, its what the infrastructure supports. You may find a better place to make this suggestion over with the BouncyCastle folk.? There are a host of utilities included with their ASN1 libraries and crypto Providers that can be used to get what you want - but I see you've already noted that. You could always build your own provider classes to do what you want. Later, Mike On 5/4/2021 2:48 PM, Tim Bray wrote: > Pardon the interruption.? I'm working on a social-media identity > federation project involving zero-knowledge proofs where you post > public-key/nonce/sig combinations to multiple places to prove the > poster identities' shared ownership of a private key. Details (not > really relevant to the following): > https://www.tbray.org/ongoing/When/202x/2020/12/01/Bluesky-Identity > > > The representation of the public key needs to be textual. The most > straightforward way to do that is a one-liner like so: > Base64.getEncoder().encodeToString(key.getEncoded()) which gives you > Base64'ed PKIX. > > Problem is, people are wondering why they need PKIX. They want to use > EdDSA and they don't see the need for algorithm agility (there's a > faction that thinks it's actively harmful) and ?point out that ed25119 > keys are just 32 bytes worth of bits and don't see why they need to > use Eighties technologies to express them in ASCII and ask "why can't > I just base64 those bytes?" ?Which is straightforward in Go and JS and > so on. > > It is however not straightforward in Java (unless I'm missing > something obvious, wouldn't be surprising) > because?sun.security.x509.X509Key.getKey() is protected; see > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/X509Key.java#L131 > > > I have?verified, via abuse of the reflection APIs,?that the BitArray > that call returns does indeed represent the appropriate 32 ed25519 > bytes. So, I have an object that has the data that I need inside but > for reasons of policy it is declining to reveal them.? BTW you can do > this in BouncyCastle and friends. > > Rather than changing protection on a long-established method, maybe a > new public byte[] getKeyBytes() would be the thing to do?? Or maybe it > would be better to make this an EdDSA-specific operation? Maybe the > EdDSA classes already provide a way to do this that?I couldn't find? > > So, with an apology for possibly wasting your time, two questions: > > 1. Is there a principled Java 15 way to get the key bytes that I'm not > smart enough to have found? > 2. Failing that, would a proposal to allow access to un-PKIX'ed EdDSA > key bytes be ruled out in principle for some good reason that I don't > know about? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Tue May 4 22:16:52 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 4 May 2021 22:16:52 GMT Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao wrote: > Hi, > > Please find in this PR a proposal to fix JDK-8265462 [1]. > > With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior. > > No regressions observed in the jdk/sun/security/pkcs11 tests category. > > A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8265462 src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11t.h line 105: > 103: #define CKN_OTP_CHANGED 1UL > 104: > 105: typedef CK_ULONG CK_PROFILE_ID; There is already a typedef for CK_PROFILE_ID further down in this file. ------------- PR: https://git.openjdk.java.net/jdk/pull/3661 From valeriep at openjdk.java.net Tue May 4 22:21:53 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 4 May 2021 22:21:53 GMT Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao wrote: > Hi, > > Please find in this PR a proposal to fix JDK-8265462 [1]. > > With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior. > > No regressions observed in the jdk/sun/security/pkcs11 tests category. > > A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8265462 src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11t.h line 112: > 110: #define NETSCAPE_SLOT_ID 1 > 111: #define PRIVATE_KEY_SLOT_ID 2 > 112: #define FIPS_SLOT_ID 3 These NSS specific defines is better off to be placed in a separate header file for ease of maintenance. In the past when PKCS#11 version is updated, we just drop the latest header files in and replace existing ones. Why not adding them to to j2secmod.h or pkcs11wrapper.h? ------------- PR: https://git.openjdk.java.net/jdk/pull/3661 From valeriep at openjdk.java.net Tue May 4 23:29:53 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 4 May 2021 23:29:53 GMT Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao wrote: > Hi, > > Please find in this PR a proposal to fix JDK-8265462 [1]. > > With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior. > > No regressions observed in the jdk/sun/security/pkcs11 tests category. > > A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it. > > Thanks, > Martin.- > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8265462 Here are some comments. Rest looks fine. Thanks. Valerie src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java line 81: > 79: > 80: private final static int FIPS_SLOT_ID = 0x3; > 81: Add a comment on where these are defined in native side, i.e. which sunpkcs11 header file as well as the NSS header just in case? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java line 415: > 413: } else { > 414: throw new RuntimeException("Unexpected slot ID in the" + > 415: " NSS Internal Module"); Add the slot ID to the exception message? src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h line 78: > 76: > 77: /* represent a pkcs#11 slot reference counted. */ > 78: struct PK11SlotInfoStr { nit: add which nss header this is from. src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h line 166: > 164: }; > 165: > 166: struct SECMODModuleStr { Same nit: add which nss header this is from. ------------- PR: https://git.openjdk.java.net/jdk/pull/3661 From ron.pressler at oracle.com Wed May 5 00:08:36 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 5 May 2021 00:08:36 +0000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> Message-ID: <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Resent with plain-text formatting (I hope) & corrections/rephrasing > On 4 May 2021, at 03:49, Peter Firmstone wrote: > > > Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. > The Security Manager hasn?t been a central part of Java?s server-side security for years. Some of the most critical and best-secured systems in the world are written in Java, and they don?t use the Security Manager, so let?s not equate a particular sandboxing mechanism designed for untrusted code with security. > Lets drop the excuses that it's just a theoretical, impractical thing that nobody uses, and say instead that we know that this does something important, it is very powerful, it is a deployed API that is in use, probably the only least privileged protection domain model that really works, but we are no longer supporting it moving forward because it is not well understood by those maintaining it and for this reason it creates a significant maintenance burden. I have to disagree on all counts here. Also, I want to emphasise that if Security Manager were an important security feature for Java these days, then "some people have been able to make it effective" is the very opposite of ?works? when it comes to security and a mainstream language. A mechanism that confuses most people is still undesirable even if a small minority uses it correctly. You can believe that the maintainers misunderstand this feature ? that is a very bold claim ? but even if it were true it doesn?t change the following empirical facts: 1. SM is not used as a central security Java feature, 2. It is used at all by very few projects, and 3. it is a heavy maintenance burden. Maybe the reasons for these is misunderstanding or general incompetence but that doesn?t change the reality. We need to work in the world we have, not the one we wish we had. > Please provide some examples, migration options suggestions will be appreciated. I?ve jotted down some thoughts in a blog post: https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ > With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses. Removing Serialization has greater appeal :) > > This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. > > Removing SecurityManager has a significantly negative effect on security for me, just so you know. I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. > > I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. Not everyone has to agree with every priority decision, and the process doesn?t require convincing every last Java developer. But it is not sudden, and there will be alternatives for those aspects of Security Manager that more people use. I don?t think it is fair to harm millions of Java developers by diverting resources from features they want to features very few people want, as long as a reasonable removal process is employed, and I think it is here. > Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager. The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. I disagree. I don?t think that the Security Manager offers a higher level of security, just a very elaborate and fine-grained one. > Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager. I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. I wouldn?t say Java (or anything else, for that matter) is ?able" to do it now, except in the sense that people (scientists) are able (in a billion-dollar particle accelerator) to transmute lead into gold (a few atoms). We?ve had twenty five years to convince the world this could work, the world isn?t buying, and our job isn?t to sell ideas but to serve millions of developers by giving them what we believe they need now, not what we wished they wanted. ? Ron From xuelei at openjdk.java.net Wed May 5 03:43:52 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 5 May 2021 03:43:52 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v2] In-Reply-To: References: <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com> Message-ID: On Thu, 29 Apr 2021 15:58:28 GMT, Xue-Lei Andrew Fan wrote: >> Yes, I?ve made a test that calculates total time spent by server to receive "N" connections. Every server handshake is performed in a separate thread >> The client starts "T" threads. Every thread sends one initial connection and "R-1" renegotiated connections. So, the total number of connections is "N"="T"*"R" >> >> Results for the original and JDK-8241248 code are almost identical: >> "T"=10 "R"=100 >> Original OpenJDK: 1140 ms >> JDK-8241248 code: 1090 ms >> >> "T"=50 "R"=100 >> Original OpenJDK: 1164 ms >> JDK-8241248 code: 1108 ms >> >> "T"=60 "R"=100 >> Original OpenJDK: 1461 ms >> JDK-8241248 code: 1579 ms >> >> "T"=70 "R"=100 >> Original OpenJDK: 2058 ms >> JDK-8241248 code: 1999 ms >> >> "T"=80 "R"=100 >> Original OpenJDK: 2148 ms >> JDK-8241248 code: 2125 ms >> >> "T"=90 "R"=100 >> Original OpenJDK: 2540 ms >> JDK-8241248 code: 2514 ms >> >> "T"=90 "R"=100 >> Original OpenJDK: 3011 ms >> JDK-8241248 code: 3010 ms >> >> I can confirm that the synchronization code works. Without it, I still catch exception from different threads trying to resume the same session from the cache > > Thank you for the update. > > I also expect the code easy to read and maintain in the future. But please go ahead for the integration if you don't want to make the update now. We could file an enhancement later on. > @XueleiFan , @jnimeh, thank you for your suggestions. I have updated synchronization using ReentrantLock in the Cache object. The performance test showed no issues. Thank you for considering use ReentrantLock, the "synchronized" keyword is something we are trying to avoid in the JSSE implementation. However, the reentrant lock introduced is not the lock in the Cache implementation. They are overlapped and could be conflict. The performance test looks good with just a few threads, but I'm not very sure of the through put impact if the threads goes up to 1M or more (there were complaints previously for large volume traffics). Maybe, you could keep it simple by adding a pull() method in the Cache class (find the session and remove it from the cache if found), by using the Cache class internal synchronize methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From peter.firmstone at zeus.net.au Wed May 5 04:04:41 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 5 May 2021 14:04:41 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API,? java.* API's ONCE REMOVED CANNOT BE REPLACED.? IF YOU ARE CONCERNED SOMETHING MAY BE REMOVED IN FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN INTERFACE WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER BACKWARD COMPATIBLE API EVOLUTION. On 5/05/2021 10:08 am, Ron Pressler wrote: > Resent with plain-text formatting (I hope) & corrections/rephrasing > >> On 4 May 2021, at 03:49, Peter Firmstone wrote: >> >> >> Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. >> > The Security Manager hasn?t been a central part of Java?s server-side security for years. Some of the most critical and > best-secured systems in the world are written in Java, and they don?t use the Security Manager, so let?s not equate a > particular sandboxing mechanism designed for untrusted code with security. Got any example best-secured systems? I think we are talking past each other here.?? You keep talking about untrusted code, which sounds like applets to me.? I've read and still have a copy of Li Gong's book, applets were only one of the considerations.? I am talking about authorization and access control.? We use and develop distributed or p2p systems, we don't allow untrusted code to run at all, never ever, that's a dumb idea, so lets stop talking about untrusted code, we don't use that.? ? We do utilize dynamic downloaded code from others and use dynamic class loading, we verify this prior to loading.? We check it's authorized to run before running it.? Again I repeat, we do not run untrusted code, that would allow an attacker to cause denial of service etc, the JVM has no control over badly behaving code. We've been using this since Java 1.4, to control access to networks, file systems and other custom permissions we created, it is used to protect access to sensitive data.? We are still using it.? I understand access control will be removed: https://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc4.html#20389 We would like to continue restricting access to data after the above is removed.? Will Java be introducing new Role Based Access Control API or something similar? Our software will fail to run on Java after the above is removed.?? I understand we have to remove access control functionality from our software for it to continue functioning? We do need to understand how this will impact security, I think you are trying to convince me or yourself that security will not be impacted?? We can't just assume we can remove access control and our software will be no less secure. What is the new API for access control in Java? Obviously we won't have a call stack with domains, I don't know how we will transfer the user Subject to other threads, for TLS and Kerberos connections.? No doubt something is planned. Is the recommendation simply not to upgrade Java until new access control API is developed? >> Please provide some examples, migration options suggestions will be appreciated. > I?ve jotted down some thoughts in a blog post: https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ Noted, a good start.? I get the feeling this JEP is being rushed through however, with little regard for those of us who were foolish enough to use Java's security API's and will have to suffer the consequences. > > >> With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses. Removing Serialization has greater appeal :) >> >> This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. >> >> Removing SecurityManager has a significantly negative effect on security for me, just so you know. I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. >> >> I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. > > Not everyone has to agree with every priority decision, and the process doesn?t require convincing every last Java developer. But > it is not sudden, and there will be alternatives for those aspects of Security Manager that more people use. I don?t think it is fair > to harm millions of Java developers by diverting resources from features they want to features very few people want, as long as > a reasonable removal process is employed, and I think it is here. > >> Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager. The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. > I disagree. I don?t think that the Security Manager offers a higher level of security, just a very elaborate and fine-grained one. Right now I can limit network access using a permission, or I can prevent file access, database access, or even access to objects themselves.? This is for generally well behaved party's, but we still have to have controls in place. https://www.acsac.org/2009/program/keynotes/gong.pdf Regarding a higher level of security: Q1. What does an attacker who is using serialization as an attack vector want to gain? A1. Property: intellectual, fiat currency, identity theft etc. Q2. Why does an attacker use Serialization as the attack vector? A2. Because it allows an attacker to create any object they like in the JVM, even inject code, the attacker first attempts privilege escalation.? Java makes this easy, because the implementation doesn't place an unprivileged ProtectionDomain onto the call stack.? A simple initial fix would have been to modify the AccessControlContext to include an unprivileged ProtectionDomain on the call stack when a user creates an instance of ObjectInputStream.?? Granted there were still cases of JVM classes that deserialized into a doPrivileged call that needed to be addressed. Q3. SecurityManager and policy providers use whitlists.?? The complaint about SecurityManager is that whitelisting is too complex.? Why entertain a new white listing api for Java Serialization, when complexity is the argument for removing SecurityManager, but it's even worse than SecurityManager, at least with the policy whitelist you have some forward knowledge. A3. Any ideas? > >> Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager. I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. > I wouldn?t say Java (or anything else, for that matter) is ?able" to do it now, except in the sense that people (scientists) are > able (in a billion-dollar particle accelerator) to transmute lead into gold (a few atoms). We?ve had twenty five years to convince the world this could work, the world isn?t buying, and our job isn?t to sell ideas but to serve millions of developers by giving them > what we believe they need now, not what we wished they wanted. > > ? Ron Of course Java is "able" to do access control, it's well documented, I have working examples.? No security defense is 100% effective, if you look at the history of defenses, they continue to evolve.? Just because ObjectInputStream was a huge security hole, it didn't inject an unprivileged ProtectionDomain onto the stack, which would have stopped a number of deserialization gadgets.?? ObjectInputStream runs as privileged code, tut, tut, tut!?? Perl taint mode anyone? Java 6 introduced a security feature where an object will not be constructed if Object's constructor is not called, so that invariants must be satisfied before object creation.? Java Serialziation bypasses this.? Prior to Java 6, objects could be left in a partially constructed state and obtained via a finalizer attack. Besides, serialization whitelists don't protect against denial of service, so why have them at all if you using trusted systems and TLS connections?? Java Serialization should never be used to process untrusted data, because it doesn't and cannot validate invariants until after objects are constructed which is too late. As soon as you implement Serializable, all the effort you put into defensively coding constructors can be bypassed.?? So why code defensively at all if we leave a back door wide open anyway?? All code is trusted now right, soon we can make sure all connections are secure, so we don't need to worry about input validation anymore either right, because the users are trusted now too? Maybe we should just whitelist the classes allowed to run on the JVM and not worry about coding defensively?? Sounds silly, well that's how it sounds to me, just thought I'd put it into perspective. Java Serialization still compromises the security of the JVM because it doesn't prevent object creation if invariants aren't satisfied, the vulnerability is still there, and future attackers will find a way take advantage of it for that reason. It is clear that no further progress will be made in this matter and I will simply have to live with the consequences. Stick a fork in me, because I'm done. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From fguallini at openjdk.java.net Wed May 5 10:08:15 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 5 May 2021 10:08:15 GMT Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2] In-Reply-To: References: Message-ID: > test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame > > With this changeset, the server is checking whether the client thread has initiated handshake, and retrying if needed after waiting a short time. In addition, the test is now reusing SSLSocketTemplate to simplify sockets configuration and client/server synchronization Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: var volatile ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3856/files - new: https://git.openjdk.java.net/jdk/pull/3856/files/43a97f64..300ac1ad Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3856&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3856&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3856.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3856/head:pull/3856 PR: https://git.openjdk.java.net/jdk/pull/3856 From fguallini at openjdk.java.net Wed May 5 10:08:16 2021 From: fguallini at openjdk.java.net (Fernando Guallini) Date: Wed, 5 May 2021 10:08:16 GMT Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2] In-Reply-To: References: Message-ID: On Tue, 4 May 2021 16:07:42 GMT, Daniel Fuchs wrote: >> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: >> >> var volatile > > test/jdk/sun/security/ssl/SSLSocketImpl/CloseSocket.java line 45: > >> 43: public class CloseSocket extends SSLSocketTemplate { >> 44: >> 45: private static Thread clientThread = null; > > Shouldn't this variable be `volatile`? If I'm not mistaken it's set in one thread and potentially read in a different thread? An alternative could be to use a CountDownLatch instead. Thanks, updated to be volatile. SSLSocket::startHandshake internally first checks that the socket is not closed or broken and still connected, so it needs the server to close the socket after those verifications are performed to reproduce the test scenario, thus a CountDownLatch in the test before calling startHandshake would not guarantee that its internal operations are run before the server, already unblocked at that time, closes the socket A CountDownLatch after startHandshake does not work either since the client keeps waiting for a server response, which is blocked waiting for the latch. That is why I think that looking at the thread stack is the best way to guarantee the scenario is properly verified ------------- PR: https://git.openjdk.java.net/jdk/pull/3856 From ssahoo at openjdk.java.net Wed May 5 10:09:14 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Wed, 5 May 2021 10:09:14 GMT Subject: RFR: 8180568: Refactor javax/crypto shell tests to plain java tests Message-ID: <48tPj8EJ5WABFRBKUu5g-PLZuJA7-Eu4ltcicXgM5eM=.9b9b74f9-5fd7-4773-a43c-39e003d524eb@github.com> This change is to remove the shell Test and convert to it's java equivalent. That is the reason the shell Tests are deleted and the equivalent Java implementation provided. The purpose of the Test TestExemption.java is with limited crypto policy a JCE provider can supplemented additional crypto permissions through "cryptoPerms" file bundled inside the JCE signed jar. It also need to be noticed that TestExemption.java has '@requires java.runtime.name ~= "OpenJDK.*"'. It looks the intension of this Test availability in open GIT is to run by any other JDK providers. ------------- Commit messages: - 8180568: Refactor javax/crypto shell tests to plain java tests Changes: https://git.openjdk.java.net/jdk/pull/3876/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3876&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8180568 Stats: 339 lines in 4 files changed: 138 ins; 183 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3876.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3876/head:pull/3876 PR: https://git.openjdk.java.net/jdk/pull/3876 From dfuchs at openjdk.java.net Wed May 5 11:16:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 5 May 2021 11:16:51 GMT Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2] In-Reply-To: References: Message-ID: <2LHxbK4aOjRRcuAswgjb8utXRGty792U2gcdZRykV_k=.540ed388-7674-4c0b-ab73-bc5b02d23cbf@github.com> On Wed, 5 May 2021 10:08:15 GMT, Fernando Guallini wrote: >> test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame >> >> With this changeset, the server is checking whether the client thread has initiated handshake, and retrying if needed after waiting a short time. In addition, the test is now reusing SSLSocketTemplate to simplify sockets configuration and client/server synchronization > > Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision: > > var volatile Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3856 From dfuchs at openjdk.java.net Wed May 5 11:16:52 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 5 May 2021 11:16:52 GMT Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption [v2] In-Reply-To: References: Message-ID: On Wed, 5 May 2021 10:05:14 GMT, Fernando Guallini wrote: >> test/jdk/sun/security/ssl/SSLSocketImpl/CloseSocket.java line 45: >> >>> 43: public class CloseSocket extends SSLSocketTemplate { >>> 44: >>> 45: private static Thread clientThread = null; >> >> Shouldn't this variable be `volatile`? If I'm not mistaken it's set in one thread and potentially read in a different thread? An alternative could be to use a CountDownLatch instead. > > Thanks, updated to be volatile. > > SSLSocket::startHandshake internally first checks that the socket is not closed or broken and still connected, so it needs the server to close the socket after those verifications are performed to reproduce the test scenario, thus a CountDownLatch in the test before calling startHandshake would not guarantee that its internal operations are run before the server, already unblocked at that time, closes the socket > > A CountDownLatch after startHandshake does not work either since the client keeps waiting for a server response, which is blocked waiting for the latch. That is why I think that looking at the thread stack is the best way to guarantee the scenario is properly verified OK ------------- PR: https://git.openjdk.java.net/jdk/pull/3856 From peter.firmstone at zeus.net.au Wed May 5 12:23:03 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Wed, 5 May 2021 22:23:03 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: On 5/05/2021 10:08 am, Ron Pressler wrote: > I wouldn?t say Java (or anything else, for that matter) is ?able" to do it now, except in the sense that people (scientists) are > able (in a billion-dollar particle accelerator) to transmute lead into gold (a few atoms). We?ve had twenty five years to convince the world this could work, the world isn?t buying, and our job isn?t to sell ideas but to serve millions of developers by giving them > what we believe they need now, not what we wished they wanted. > > ? Ron We just want our software to work Ron, we invest years of time and effort, we just want it to work.? We don't want to have to test and rework it for every Java release, you are creating too much maintenance for us to keep up with. You'll be serving fewer and fewer developers as more and more are left behind as breakages accumulate.? I was at least keeping up and testing newer releases, even though we still only build on Java 8. Last I checked the stats, 58% were using Java 8, 23% using Java 11 and 6% of developers using 12 or newer. I think you'll have trouble selling it as you say, we won't have time to learn and implement new language features if we're too busy fixing breakages. Hard life creates hard people, hard people create easy life, easy life creates soft people, soft people create hard life. -- Regards, Peter Firmstone My personal opinion only. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Wed May 5 12:55:51 2021 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 5 May 2021 08:55:51 -0400 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> -bcc jdk-dev -cc security-dev On 5/5/21 12:04 AM, Peter Firmstone wrote: > > I think we are talking past each other here.?? You keep talking about > untrusted code, which sounds like applets to me.? I've read and still > have a copy of Li Gong's book, applets were only one of the > considerations.? I am talking about authorization and access control. We > use and develop distributed or p2p systems, we don't allow untrusted > code to run at all, never ever, that's a dumb idea, so lets stop talking > about untrusted code, we don't use that.? ? We do utilize dynamic > downloaded code from others and use dynamic class loading, we verify > this prior to loading.? We check it's authorized to run before running > it.? Again I repeat, we do not run untrusted code, that would allow an > attacker to cause denial of service etc, the JVM has no control over > badly behaving code. But you use self-signed certificates to sign the code that will be run. There is no trust in self-signed certificates unless you have previously used some out-of-band mechanism to trust the public key. I still don't understand why this is not the same as running untrusted code, even if the code is sandboxed. And trusting the TLS server is not an equivalent basis of trust. > We've been using this since Java 1.4, to control access to networks, > file systems and other custom permissions we created, it is used to > protect access to sensitive data.? We are still using it.? I understand > access control will be removed: > > https://docs.oracle.com/javase/8/docs/technotes/guides/security/spec/security-spec.doc4.html#20389 > > > We would like to continue restricting access to data after the above is > removed.? Will Java be introducing new Role Based Access Control API or > something similar? > > Our software will fail to run on Java after the above is removed.?? I > understand we have to remove access control functionality from our > software for it to continue functioning? We do need to understand how > this will impact security, I think you are trying to convince me or > yourself that security will not be impacted?? We can't just assume we > can remove access control and our software will be no less secure. > > What is the new API for access control in Java. > Obviously we won't have a call stack with domains, I don't know how we > will transfer the user Subject to other threads, for TLS and Kerberos > connections.? No doubt something is planned. There is a plan for preserving the capability to transfer Subjects to other threads. It is described in the JEP: https://openjdk.java.net/jeps/411#Alternate-JAAS-APIs --Sean > > Is the recommendation simply not to upgrade Java until new access > control API is developed? > > > >>> Please provide some examples,? migration options suggestions will be >>> appreciated. >> I?ve jotted down some thoughts in a blog post: >> https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ >> > > Noted, a good start.? I get the feeling this JEP is being rushed through > however, with little regard for those of us who were foolish enough to > use Java's security API's and will have to suffer the consequences. > > >> >> >>> With Serialization, we've been given more than ample notice to do >>> something about migrating away from it, but OpenJDK paints over it >>> and wastes resources adding features to putty and paint over it some >>> more, features that no one uses.? Removing Serialization has greater >>> appeal :) >>> >>> This step to remove SecurityManager is so sudden with no replacement >>> options, it's a broken promise to developers, who've invested in Java. >>> >>> Removing SecurityManager has a significantly negative effect on >>> security for me, just so you know.? I'm not happy about its proposed >>> removal, but I realise there's not much I can do about it, other than >>> request it be done in the least painful manner. >>> >>> I began learning Java over 20 years ago, I understand the need to >>> keep Java relevant, however move quickly and break things is for >>> younger software platforms. >> >> Not everyone has to agree with every priority decision, and the >> process doesn?t require convincing every last Java developer. But >> it is not sudden, and there will be alternatives for those aspects of >> Security Manager that more people use. I don?t think it is fair >> to harm millions of Java developers by diverting resources from >> features they want to features very few people want, as long as >> a reasonable removal process is employed, and I think it is here. >> >>> Once SecurityManager has been removed, we will lose control over who >>> has access to sensitive data, so it's likely we will be stuck on the >>> last version of Java that provides SecurityManager.? The best way I >>> can see for those who need the level of security that SecurityManager >>> provides is to maintain a community LTS edition on OpenJDK, it will >>> be much easier to maintain and backport security patches if >>> Serialization in its current form has been removed, as it will likely >>> have been removed from later versions of Java by that time. >> I disagree. I don?t think that the Security Manager offers a higher >> level of security, just a very elaborate and fine-grained one. > > Right now I can limit network access using a permission, or I can > prevent file access, database access, or even access to objects > themselves.? This is for generally well behaved party's, but we still > have to have controls in place. > > https://www.acsac.org/2009/program/keynotes/gong.pdf > > Regarding a higher level of security: > > Q1. What does an attacker who is using serialization as an attack vector > want to gain? > > A1. Property: intellectual, fiat currency, identity theft etc. > > Q2. Why does an attacker use Serialization as the attack vector? > > A2. Because it allows an attacker to create any object they like in the > JVM, even inject code, the attacker first attempts privilege > escalation.? Java makes this easy, because the implementation doesn't > place an unprivileged ProtectionDomain onto the call stack.? A simple > initial fix would have been to modify the AccessControlContext to > include an unprivileged ProtectionDomain on the call stack when a user > creates an instance of ObjectInputStream.?? Granted there were still > cases of JVM classes that deserialized into a doPrivileged call that > needed to be addressed. > > Q3. SecurityManager and policy providers use whitlists.?? The complaint > about SecurityManager is that whitelisting is too complex.? Why > entertain a new white listing api for Java Serialization, when > complexity is the argument for removing SecurityManager, but it's even > worse than SecurityManager, at least with the policy whitelist you have > some forward knowledge. > > A3. Any ideas? > > >> >>> Lets be clear Java will no longer be able to finely control access to >>> sensitive data with the removal of SecurityManager.? I'm sure it will >>> be a great bonus for OpenJDK dev's not to have to think about, but it >>> will impact some developers significantly, who would like to do so >>> with the least suffering possible. >> I wouldn?t say Java (or anything else, for that matter) is ?able" to >> do it now, except in the sense that people (scientists) are >> able (in a billion-dollar particle accelerator) to transmute lead into >> gold (a few atoms). We?ve had twenty five years to convince the world >> this could work, the world isn?t buying, and our job isn?t to sell >> ideas but to serve millions of developers by giving them >> what we believe they need now, not what we wished they wanted. >> >> ? Ron > > Of course Java is "able" to do access control, it's well documented, I > have working examples.? No security defense is 100% effective, if you > look at the history of defenses, they continue to evolve.? Just because > ObjectInputStream was a huge security hole, it didn't inject an > unprivileged ProtectionDomain onto the stack, which would have stopped a > number of deserialization gadgets.?? ObjectInputStream runs as > privileged code, tut, tut, tut!?? Perl taint mode anyone? > > Java 6 introduced a security feature where an object will not be > constructed if Object's constructor is not called, so that invariants > must be satisfied before object creation.? Java Serialziation bypasses > this.? Prior to Java 6, objects could be left in a partially constructed > state and obtained via a finalizer attack. > > Besides, serialization whitelists don't protect against denial of > service, so why have them at all if you using trusted systems and TLS > connections?? Java Serialization should never be used to process > untrusted data, because it doesn't and cannot validate invariants until > after objects are constructed which is too late. As soon as you > implement Serializable, all the effort you put into defensively coding > constructors can be bypassed.?? So why code defensively at all if we > leave a back door wide open anyway?? All code is trusted now right, soon > we can make sure all connections are secure, so we don't need to worry > about input validation anymore either right, because the users are > trusted now too? Maybe we should just whitelist the classes allowed to > run on the JVM and not worry about coding defensively?? Sounds silly, > well that's how it sounds to me, just thought I'd put it into perspective. > > Java Serialization still compromises the security of the JVM because it > doesn't prevent object creation if invariants aren't satisfied, the > vulnerability is still there, and future attackers will find a way take > advantage of it for that reason. > > It is clear that no further progress will be made in this matter and I > will simply have to live with the consequences. Stick a fork in me, > because I'm done. > From ron.pressler at oracle.com Wed May 5 13:12:16 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 5 May 2021 13:12:16 +0000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: > On 5 May 2021, at 05:04, Peter Firmstone wrote: > > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API, java.* API's ONCE REMOVED CANNOT BE REPLACED. IF YOU ARE CONCERNED SOMETHING MAY BE REMOVED IN FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN INTERFACE WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER BACKWARD COMPATIBLE API EVOLUTION. Any API has a non-zero risk of removal after decades of use, and that risk is commensurate with its level of use. I think this is always true, and that everyone already knows that and finds that acceptable, because it?s better than any other alternative. In this particular case, we?re discussing the removal of an API after three decades of use, with under 0.1% of codebases making use of it. > > Got any example best-secured systems? I would hope that Apple's, Amazon?s, Google?s and my bank?s systems, many of which are Java, are secure. > > I think we are talking past each other here. You keep talking about untrusted code, which sounds like applets to me. I've read and still have a copy of Li Gong's book, applets were only one of the considerations. I am talking about authorization and access control. We use and develop distributed or p2p systems, we don't allow untrusted code to run at all, never ever, that's a dumb idea, so lets stop talking about untrusted code, we don't use that. We do utilize dynamic downloaded code from others and use dynamic class loading, we verify this prior to loading. We check it's authorized to run before running it. Again I repeat, we do not run untrusted code, that would allow an attacker to cause denial of service etc, the JVM has no control over badly behaving code. The whole design of the security manager as a ?path-dependent? deep sandbox is built around untrusted code, hence all the stack-walking and doPrivileged. Trusted code means assumed not to be malicious. As such, what you want to protect against is vulnerabilities. Since you don?t know where they are, you place the entire application in a sandbox that?s both more airtight and less complex than the Security Manager. That is, in fact, how most people do it. > > Of course Java is "able" to do access control, it's well documented, I have working examples. No security defense is 100% effective, if you look at the history of defenses, they continue to evolve. Just because ObjectInputStream was a huge security hole, it didn't inject an unprivileged ProtectionDomain onto the stack, which would have stopped a number of deserialization gadgets. ObjectInputStream runs as privileged code, tut, tut, tut! Perl taint mode anyone? We are not talking about authorisation or access control. We?re talking about the Security Manager?s design and implementation which is about code domains and stack-dependence. Serialisation?s security is one thing and the Security Manager is a whole other thing. > > Java 6 introduced a security feature where an object will not be constructed if Object's constructor is not called, so that invariants must be satisfied before object creation. Java Serialziation bypasses this. Prior to Java 6, objects could be left in a partially constructed state and obtained via a finalizer attack. > > Besides, serialization whitelists don't protect against denial of service, so why have them at all if you using trusted systems and TLS connections? Java Serialization should never be used to process untrusted data, because it doesn't and cannot validate invariants until after objects are constructed which is too late. As soon as you implement Serializable, all the effort you put into defensively coding constructors can be bypassed. So why code defensively at all if we leave a back door wide open anyway? All code is trusted now right, soon we can make sure all connections are secure, so we don't need to worry about input validation anymore either right, because the users are trusted now too? Maybe we should just whitelist the classes allowed to run on the JVM and not worry about coding defensively? Sounds silly, well that's how it sounds to me, just thought I'd put it into perspective. > > Java Serialization still compromises the security of the JVM because it doesn't prevent object creation if invariants aren't satisfied, the vulnerability is still there, and future attackers will find a way take advantage of it for that reason. > > It is clear that no further progress will be made in this matter and I will simply have to live with the consequences. Stick a fork in me, because I'm done. You are conflating the Security Manager with security. A lot of security work has been going on in the JDK for the past few years (and will continue for as long Java exists), but not in the code-protection-domain-sandbox known as the Security Manager. ? Ron From peter.tribble at gmail.com Wed May 5 15:02:51 2021 From: peter.tribble at gmail.com (Peter Tribble) Date: Wed, 5 May 2021 16:02:51 +0100 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: On Wed, May 5, 2021 at 2:13 PM Ron Pressler wrote: > > > > On 5 May 2021, at 05:04, Peter Firmstone > wrote: > > > > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY java.* > package namespace API'S THAT MAY BE AT RISK OF LATER REMOVAL IN YOUR API, > java.* API's ONCE REMOVED CANNOT BE REPLACED. IF YOU ARE CONCERNED > SOMETHING MAY BE REMOVED IN FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN > INTERFACE WITH SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER > BACKWARD COMPATIBLE API EVOLUTION. > > Any API has a non-zero risk of removal after decades of use, and that risk > is commensurate with its level of use. I think > this is always true, and that everyone already knows that and finds that > acceptable, because it?s better than any other > alternative. In this particular case, we?re discussing the removal of an > API after three decades of use, with under 0.1% > of codebases making use of it. > It appears that my employer's codebase is in that 0.1%. I've looked around the JEP, and your article, and it isn't clear to me if there's a viable alternative to a Security Manager for us. We run server-side code, including a commercial library, and simply need to ensure that its behaviour remains within defined limits. For our own code, we know whether a file or network access is legitimate, because we can add the appropriate checks to the code. For this 3rd-party code, we simply install a security manager before calling it and uninstall it afterwards. We can't modify the code; we can't implement a sandbox at the system level (we do anyway, but the point is that we need to impose conditional access controls depending on which java code is running). We have no particular tie to the existing APIs, but the ability to apply sufficiently fine-grained permissions to sections of code is one that has value to us. > > > > Got any example best-secured systems? > > I would hope that Apple's, Amazon?s, Google?s and my bank?s systems, many > of which are Java, are secure. > > > > > I think we are talking past each other here. You keep talking about > untrusted code, which sounds like applets to me. I've read and still have > a copy of Li Gong's book, applets were only one of the considerations. I > am talking about authorization and access control. We use and develop > distributed or p2p systems, we don't allow untrusted code to run at all, > never ever, that's a dumb idea, so lets stop talking about untrusted code, > we don't use that. We do utilize dynamic downloaded code from others and > use dynamic class loading, we verify this prior to loading. We check it's > authorized to run before running it. Again I repeat, we do not run > untrusted code, that would allow an attacker to cause denial of service > etc, the JVM has no control over badly behaving code. > > The whole design of the security manager as a ?path-dependent? deep > sandbox is built around untrusted code, hence > all the stack-walking and doPrivileged. Trusted code means assumed not to > be malicious. As such, what you want to protect > against is vulnerabilities. Since you don?t know where they are, you place > the entire application in a sandbox that?s > both more airtight and less complex than the Security Manager. That is, in > fact, how most people do it. > > > > > Of course Java is "able" to do access control, it's well documented, I > have working examples. No security defense is 100% effective, if you look > at the history of defenses, they continue to evolve. Just because > ObjectInputStream was a huge security hole, it didn't inject an > unprivileged ProtectionDomain onto the stack, which would have stopped a > number of deserialization gadgets. ObjectInputStream runs as privileged > code, tut, tut, tut! Perl taint mode anyone? > > We are not talking about authorisation or access control. We?re talking > about the Security Manager?s design and implementation > which is about code domains and stack-dependence. Serialisation?s security > is one thing and the Security Manager is a whole other > thing. > > > > > Java 6 introduced a security feature where an object will not be > constructed if Object's constructor is not called, so that invariants must > be satisfied before object creation. Java Serialziation bypasses this. > Prior to Java 6, objects could be left in a partially constructed state and > obtained via a finalizer attack. > > > > Besides, serialization whitelists don't protect against denial of > service, so why have them at all if you using trusted systems and TLS > connections? Java Serialization should never be used to process untrusted > data, because it doesn't and cannot validate invariants until after objects > are constructed which is too late. As soon as you implement Serializable, > all the effort you put into defensively coding constructors can be > bypassed. So why code defensively at all if we leave a back door wide > open anyway? All code is trusted now right, soon we can make sure all > connections are secure, so we don't need to worry about input validation > anymore either right, because the users are trusted now too? Maybe we > should just whitelist the classes allowed to run on the JVM and not worry > about coding defensively? Sounds silly, well that's how it sounds to me, > just thought I'd put it into perspective. > > > > Java Serialization still compromises the security of the JVM because it > doesn't prevent object creation if invariants aren't satisfied, the > vulnerability is still there, and future attackers will find a way take > advantage of it for that reason. > > > > It is clear that no further progress will be made in this matter and I > will simply have to live with the consequences. Stick a fork in me, because > I'm done. > > You are conflating the Security Manager with security. A lot of security > work has been going on in the JDK for the past few years > (and will continue for as long Java exists), but not in the > code-protection-domain-sandbox known as the Security Manager. > > ? Ron > > -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From valeriep at openjdk.java.net Wed May 5 17:54:51 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 5 May 2021 17:54:51 GMT Subject: RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" In-Reply-To: References: Message-ID: <3_gntv-7lQ7twTliR0vnx6_eIkcXSPx_lbn6ktHVrlA=.b9a65a5a-161b-4542-80db-236048ea296a@github.com> On Fri, 30 Apr 2021 17:35:46 GMT, Weijun Wang wrote: > `PKCS12KeyStore` always uses a 20-byte salt in encryption but PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt used for this algorithm will be 8 bytes. > > RFC 2898 only requires the salt to be at least 8 bytes, but I don't intend to modify the `PBES1Core.java` to accept a long salt. Otherwise, a newly generated PKCS #?12 file using a long salt will not be recognized by an old JDK. > > Also, although `PBES1Core.java` also take cares of another algorithm named PBEWithMD5AndDESede but it's not usable in a PKCS #?12 keystore as we have not defined its Object Identifier anywhere. I will take a look. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3822 From peter.firmstone at zeus.net.au Wed May 5 20:54:30 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 6 May 2021 06:54:30 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> Message-ID: <7c873661-0b3b-db36-9200-98aee8a9049a@zeus.net.au> On 5/05/2021 10:55 pm, Sean Mullan wrote: > -bcc jdk-dev > -cc security-dev > > On 5/5/21 12:04 AM, Peter Firmstone wrote: > >> >> I think we are talking past each other here.?? You keep talking about >> untrusted code, which sounds like applets to me.? I've read and still >> have a copy of Li Gong's book, applets were only one of the >> considerations.? I am talking about authorization and access control. >> We use and develop distributed or p2p systems, we don't allow >> untrusted code to run at all, never ever, that's a dumb idea, so lets >> stop talking about untrusted code, we don't use that.? ? We do >> utilize dynamic downloaded code from others and use dynamic class >> loading, we verify this prior to loading. We check it's authorized to >> run before running it.? Again I repeat, we do not run untrusted code, >> that would allow an attacker to cause denial of service etc, the JVM >> has no control over badly behaving code. > > But you use self-signed certificates to sign the code that will be > run. There is no trust in self-signed certificates unless you have > previously used some out-of-band mechanism to trust the public key. I > still don't understand why this is not the same as running untrusted > code, even if the code is sandboxed. And trusting the TLS server is > not an equivalent basis of trust. Yes, we have a dynamic out of band mechanism.? We authenticate the other party using TLS, and depending on who it is (whether Permission has been granted to their Principal), we dynamically grant them permission to load their code on our system.? They can use a self signed certificate on their code, and we dynamically grant permission for the code signed by that certificate to be loaded, otherwise they can use a cryptographic checksum, so we can be sure their code hasn't been modified by a third party, it just simplifies the process, so we don't have to introduce another CA, we are actually trusting the remote end to audit their own code because we know who they are (configuration concerns).?? We also give that code Permission to connect to the remote end of the TLS connection, because threads only run with one Subject, we need the code to represent the remote Principal.? We are not concerned with the names of classes or packages in their code as that is their implementation concern. Provided there is no data theft, if something is taken down by badly behaving software, it has a level of fault tolerance, services will be restarted automatically, if they fall over, they are re-activated.? We don't use RMI's activation implementation, but we do depend on some activation API classes. The problem with removal of access control is we would be permitting unrestricted access to a trusted third party, who doesn't require unrestricted access, nor is it in our interests to allow it. It's a matter of trusting the TLS enpoint, both clients and servers are authenticated.?? But these may just be servers talking to each other, not necesarilly a client server relationship, for example a client of a service may require an event notification, so it passes a Remote object as a parameter to the service, now the server of the service, is also a client, when it sends the event notification to listeners.? It's distributed, p2p.? This is used by some as a cluster back end for JEE, although I must admit I don't know many of the details there. One of the reasons SecurityManager didn't control many Java Serialization vulnerabilities, is because ObjectInputStream was granted AllPermission as it was a platform class.? Clearly ObjectInputStream belonged in an unprivileged domain. Also it's not good that Java serialization circumvents invariant checks that constructors perform. Our software also allows the company we are dealing with for example, to provide their own GUI window within a GUI so to to speak, to allow a supplier to be integrated in to the system, as an example.? That us if it's a system with user interaction, otherwise it could be an automated process between two systems, based on an agreed interface. The only thing known prior are the Java interfaces used for intra system communication, the platform software (which we try to maintain as backward compatible) and the principal of the other party which we have granted permission to. Also I have been developing a public api for serialization (we've discussed the de-serialization component of it previously), which is suitable for other serialization protocols as well as Java's. We don't support circular links in serialized object graphs.? The only class we found that required a circular link was Throwable and we have found it's possible to program around circular links. ? Developers implementing it use an annotation and implement a public constructor for de-serialization, a public static method for serialization and another public static method that defines the parameter arguments for serialization, which are wrapped by a common serialization parameter type.?? Permission must be granted to allow serialization to be implemented (this is required by the serialization protocol implementation) and different permission is required to serialize, the parameters passed to these methods require a permission for their creation. The first serialization protocol implemented is compatible with Java's Serialization protocol, and for now, we can use the same serial form, to ease transition. To use this system, doesn't require a physics degree, and you don't need a billion dollar particle accelerator, because we don't need to turn lead into gold, this is all just Java, basically POJO domain driven design style programming.?? We've simplified the permissions systems to Principals, but dynamically grant to code, so that administrators don't have to.?? Jar files declare a list of permission required and we have a tool to determine those permissions at testing time.? The actual permissions granted is the intersection of the permissions allowed and the permissions requested.?? The set of permissions allowed typically have a wider scope, or are more permissive than those requested. We reduced complexity with dynamic permission grants and we improved performance by writing our on policy implementation. Developers do need to preserve the Subject across threads in their code. We use a remote invocation system / protocol, that's similar in principle to RMI, but unlike RMI, it preserves the Subject across secure network connections and it can be configured to use other Serialization protocols.? So serialization protocols are becoming an administration concern.?? Unlike RMI, class resolution is determined by ClassLoader's at each endpoint, not a duplicate class resolution mechanism, so it also works on systems that use graph class resolution, rather than a hierarchical class loading system, eg OSGi. These systems are also capable of dynamically discovering each other, even on global networks using IPv6 dynamic discovery, provided Principal's are known in advance. Remember Jini and Javaspaces?? We've had twenty years to simplify it and address some fundamental issues, this is modern well maintained code.?? We do depend on some classes that will be removed from Java, which originate from Java RMI's API, like the Remote interface and RemoteException, but that's life I guess.? We will have to break backward compatibility to replace them. That's probably why it sounds like you need a Physics degree and particle accelerator to do these things, because we have made things that would be otherwise very difficult, possible and simple enough for practical application. One of the things that isn't clear, is functionality provided by Java's module system how it will be used to replace SecurityManager, is how this will work with OSGi module systems. To date, I've considered the Java module system as a platform concern and systems like OSGi as an application concern.?? We produce OSGi bundles, in software releases, but we don't depend on OSGi.? OSGi's been around a lot longer, we may consider producing Java modules also, but we are waiting to learn best practices, because it's still relatively young. It does appear that we might not be able to support Java past version 17 assuming this JEP goes ahead, which seems likely.? But that might not matter, if enough software has the same difficulty, then perhaps support for Java 17 will be extended.?? If we had many years, we will probably find a solution, but in 8 years, I'm not sure it's long enough.? You only need to look at how long it took for Project Jigsaw (over 10 years wasn't it? ) to be implemented to realise some things take a long time to implement, especially low level pervasive systems. Oracle's a pretty big ship, I don't think these decisions were made in haste, but judging by conversations so far, the decision is a done deal, not a proposal, it seems unlikely this ship will be turned around.?? No doubt there will be other use cases that come to light. Thanks for your time and thanks for asking. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From wetmore at openjdk.java.net Wed May 5 22:04:53 2021 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Wed, 5 May 2021 22:04:53 GMT Subject: RFR: 8180568: Refactor javax/crypto shell tests to plain java tests In-Reply-To: <48tPj8EJ5WABFRBKUu5g-PLZuJA7-Eu4ltcicXgM5eM=.9b9b74f9-5fd7-4773-a43c-39e003d524eb@github.com> References: <48tPj8EJ5WABFRBKUu5g-PLZuJA7-Eu4ltcicXgM5eM=.9b9b74f9-5fd7-4773-a43c-39e003d524eb@github.com> Message-ID: On Wed, 5 May 2021 10:00:22 GMT, Sibabrata Sahoo wrote: > This change is to remove the shell Test and convert to it's java equivalent. That is the reason the shell Tests are deleted and the equivalent Java implementation provided. > The purpose of the Test TestExemption.java is with limited crypto policy a JCE provider can supplemented additional crypto permissions through "cryptoPerms" file bundled inside the JCE signed jar. > It also need to be noticed that TestExemption.java has '@requires java.runtime.name ~= "OpenJDK.*"'. It looks the intension of this Test availability in open GIT is to run by any other JDK providers. Looks good to me. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3876 From peter.firmstone at zeus.net.au Wed May 5 23:56:32 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 6 May 2021 09:56:32 +1000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: Thanks Peter, This is a similar use case, we are using trusted code also, but we are preventing unauthorized access to sensitive data.? I think they will discover there are many use cases like this and there will be many existing deployed systems that are not on github or wherever they've obtained their figures from that will break as a result.?? It's an API that is used in such a way that if your application makes use of it,? shotgun surgery must be prescribed to remove it,? and there will be code that people don't have source code for that will just break and that's it. It's about access control, not applets or untrusted code. @Ron, please stop deliberately conflating access control with untrusted code and security! @Ron Please stop pretending it doesn't work or that it requires a physics degree and a billion dollar budget, it's just code, maybe you should investigate and try to understand it how it works before disregarding it. Just in case you missed it I've attached it again, it is easy to do principal of least privilege using a tool to generate policy files, which also happens to provide you with an audit of every access check and you do this prior to populating it with sensitive data. It's all about access control. On 6/05/2021 1:02 am, Peter Tribble wrote: > > > On Wed, May 5, 2021 at 2:13 PM Ron Pressler > wrote: > > > > > On 5 May 2021, at 05:04, Peter Firmstone > > > wrote: > > > > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY > java.* package namespace API'S THAT MAY BE AT RISK OF LATER > REMOVAL IN YOUR API,? java.* API's ONCE REMOVED CANNOT BE > REPLACED.? IF YOU ARE CONCERNED SOMETHING MAY BE REMOVED IN > FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN INTERFACE WITH > SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER BACKWARD > COMPATIBLE API EVOLUTION. > > Any API has a non-zero risk of removal after decades of use, and > that risk is commensurate with its level of use. I think > this is always true, and that everyone already knows that and > finds that acceptable, because it?s better than any other > alternative. In this particular case, we?re discussing the removal > of an API after three decades of use, with under 0.1% > of codebases making use of it. > > > It appears that my employer's codebase is in that 0.1%. > > I've looked around the JEP, and your article, and it isn't clear to me > if there's > a viable alternative to a Security Manager for us. We run server-side > code, > including a commercial library, and simply need to ensure that its > behaviour > remains within defined limits. For our own code, we know whether a file or > network access is legitimate, because we can add the appropriate checks to > the code. For this 3rd-party code, we simply install a security > manager before > calling it and uninstall it afterwards. We can't modify the code; we > can't implement > a sandbox at the system level (we do anyway, but the point is that we > need to > impose conditional access controls depending on which java code is > running). > > We have no particular tie to the existing APIs, but the ability to > apply sufficiently > fine-grained permissions to sections of code is one that has value to us. > > > > > Got any example best-secured systems? > > I would hope that Apple's, Amazon?s, Google?s and my bank?s > systems, many of which are Java, are secure. > > > > > I think we are talking past each other here.? ?You keep talking > about untrusted code, which sounds like applets to me.? I've read > and still have a copy of Li Gong's book, applets were only one of > the considerations.? I am talking about authorization and access > control.? We use and develop distributed or p2p systems, we don't > allow untrusted code to run at all, never ever, that's a dumb > idea, so lets stop talking about untrusted code, we don't use > that.? ? We do utilize dynamic downloaded code from others and use > dynamic class loading, we verify this prior to loading.? We check > it's authorized to run before running it.? Again I repeat, we do > not run untrusted code, that would allow an attacker to cause > denial of service etc, the JVM has no control over badly behaving > code. > > The whole design of the security manager as a ?path-dependent? > deep sandbox is built around untrusted code, hence > all the stack-walking and doPrivileged. Trusted code means assumed > not to be malicious. As such, what you want to protect > against is vulnerabilities. Since you don?t know where they are, > you place the entire application in a sandbox that?s > both more airtight and less complex than the Security Manager. > That is, in fact, how most people do it. > > > > > Of course Java is "able" to do access control, it's well > documented, I have working examples.? No security defense is 100% > effective, if you look at the history of defenses, they continue > to evolve.? Just because ObjectInputStream was a huge security > hole, it didn't inject an unprivileged ProtectionDomain onto the > stack, which would have stopped a number of deserialization > gadgets. ?ObjectInputStream runs as privileged code, tut, tut, > tut! ?Perl taint mode anyone? > > We are not talking about authorisation or access control. We?re > talking about the Security Manager?s design and implementation > which is about code domains and stack-dependence. Serialisation?s > security is one thing and the Security Manager is a whole other > thing. > > > > > Java 6 introduced a security feature where an object will not be > constructed if Object's constructor is not called, so that > invariants must be satisfied before object creation.? Java > Serialziation bypasses this.? Prior to Java 6, objects could be > left in a partially constructed state and obtained via a finalizer > attack. > > > > Besides, serialization whitelists don't protect against denial > of service, so why have them at all if you using trusted systems > and TLS connections?? Java Serialization should never be used to > process untrusted data, because it doesn't and cannot validate > invariants until after objects are constructed which is too late. > As soon as you implement Serializable, all the effort you put into > defensively coding constructors can be bypassed.? ?So why code > defensively at all if we leave a back door wide open anyway?? All > code is trusted now right, soon we can make sure all connections > are secure, so we don't need to worry about input validation > anymore either right, because the users are trusted now too? Maybe > we should just whitelist the classes allowed to run on the JVM and > not worry about coding defensively?? Sounds silly, well that's how > it sounds to me, just thought I'd put it into perspective. > > > > Java Serialization still compromises the security of the JVM > because it doesn't prevent object creation if invariants aren't > satisfied, the vulnerability is still there, and future attackers > will find a way take advantage of it for that reason. > > > > It is clear that no further progress will be made in this matter > and I will simply have to live with the consequences. Stick a fork > in me, because I'm done. > > You are conflating the Security Manager with security. A lot of > security work has been going on in the JDK for the past few years > (and will continue for as long Java exists), but not in the > code-protection-domain-sandbox known as the Security Manager. > > ? Ron > > > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - > http://ptribble.blogspot.com/ -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar" { permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "setIO"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041751026391", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "setPolicy"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.defaultTestConfig", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "testConfiguration", "read"; permission java.util.PropertyPermission "testFailureAnalyzers", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/java.smartcardio" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "jrt:/java.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar;md5=c1233e711b1fc12d6df366839f425ebd" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "setLoginConfiguration"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessSystemModules"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.nio"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "loggerFinder"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "readFileDescriptor"; permission java.lang.RuntimePermission "reflectionFactoryAccess"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.RuntimePermission "writeFileDescriptor"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getNetworkInformation"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jinitests.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041751026391", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.crypto.policy"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred"; permission java.security.SecurityPermission "getProperty.jdk.serialFilter"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.login.config.url.1"; permission java.security.SecurityPermission "getProperty.login.configuration.provider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.securerandom.source"; permission java.security.SecurityPermission "getProperty.security.provider.1"; permission java.security.SecurityPermission "getProperty.security.provider.10"; permission java.security.SecurityPermission "getProperty.security.provider.11"; permission java.security.SecurityPermission "getProperty.security.provider.12"; permission java.security.SecurityPermission "getProperty.security.provider.13"; permission java.security.SecurityPermission "getProperty.security.provider.14"; permission java.security.SecurityPermission "getProperty.security.provider.2"; permission java.security.SecurityPermission "getProperty.security.provider.3"; permission java.security.SecurityPermission "getProperty.security.provider.4"; permission java.security.SecurityPermission "getProperty.security.provider.5"; permission java.security.SecurityPermission "getProperty.security.provider.6"; permission java.security.SecurityPermission "getProperty.security.provider.7"; permission java.security.SecurityPermission "getProperty.security.provider.8"; permission java.security.SecurityPermission "getProperty.security.provider.9"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SUN"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "putProviderProperty.SunJCE"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunJSSE"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunRsaSign"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.security.SecurityPermission "setPolicy"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.util.PropertyPermission "*", "read,write"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/jdk.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar" { permission java.lang.RuntimePermission "createClassLoader"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; }; grant codebase "jrt:/jdk.security.auth" { permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/classserver-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "shutdownHooks"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; }; grant codebase "jrt:/jdk.localedata" { permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "jrt:/java.xml.crypto" { permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.util.PropertyPermission "java.specification.version", "read"; }; From peter.firmstone at zeus.net.au Thu May 6 00:00:52 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 6 May 2021 10:00:52 +1000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> Message-ID: <7546bda1-d05b-6a3d-62a8-cc0af49294d9@zeus.net.au> Thanks Peter, This is a similar use case, we are using trusted code also, but we are preventing unauthorized access to sensitive data.? I think they will discover there are many use cases like this and there will be many existing deployed systems that are not on github or wherever they've obtained their figures from that will break as a result.?? It's an API that is used in such a way that if your application makes use of it,? shotgun surgery must be prescribed to remove it,? and there will be code that people don't have source code for that will just break and that's it. It's about access control, not applets or untrusted code. @Ron, please stop deliberately conflating access control with untrusted code and security! @Ron Please stop pretending it doesn't work or that it requires a physics degree and a billion dollar budget, it's just code, maybe you should investigate and try to understand it how it works before disregarding it. Just in case you anyone missed it I've attached it again, it is easy to comply with principles of least privilege using a tool to generate policy files, then edited, which also happens to provide you with an audit of every access check and you do this prior to populating it with sensitive data. It's all about access control and it's an established api, which you rightly point out has been with the platform a long time, so there will be an accumulation of uses people aren't aware of. -- Regards, Peter Firmstone On 6/05/2021 1:02 am, Peter Tribble wrote: > > > On Wed, May 5, 2021 at 2:13 PM Ron Pressler > wrote: > > > > > On 5 May 2021, at 05:04, Peter Firmstone > > > wrote: > > > > A VALUABLE LESSON FOR ANY JAVA DEVELOPER: DON'T PUBLISH ANY > java.* package namespace API'S THAT MAY BE AT RISK OF LATER > REMOVAL IN YOUR API,? java.* API's ONCE REMOVED CANNOT BE > REPLACED.? IF YOU ARE CONCERNED SOMETHING MAY BE REMOVED IN > FUTURE, SUBCLASS IT IN YOUR API, OR CREATE AN INTERFACE WITH > SUBCLASS DECORATOR, SO THAT YOU HAVE SOME CONTROL OVER BACKWARD > COMPATIBLE API EVOLUTION. > > Any API has a non-zero risk of removal after decades of use, and > that risk is commensurate with its level of use. I think > this is always true, and that everyone already knows that and > finds that acceptable, because it?s better than any other > alternative. In this particular case, we?re discussing the removal > of an API after three decades of use, with under 0.1% > of codebases making use of it. > > > It appears that my employer's codebase is in that 0.1%. > > I've looked around the JEP, and your article, and it isn't clear to me > if there's > a viable alternative to a Security Manager for us. We run server-side > code, > including a commercial library, and simply need to ensure that its > behaviour > remains within defined limits. For our own code, we know whether a file or > network access is legitimate, because we can add the appropriate checks to > the code. For this 3rd-party code, we simply install a security > manager before > calling it and uninstall it afterwards. We can't modify the code; we > can't implement > a sandbox at the system level (we do anyway, but the point is that we > need to > impose conditional access controls depending on which java code is > running). > > We have no particular tie to the existing APIs, but the ability to > apply sufficiently > fine-grained permissions to sections of code is one that has value to us. > > > > > Got any example best-secured systems? > > I would hope that Apple's, Amazon?s, Google?s and my bank?s > systems, many of which are Java, are secure. > > > > > I think we are talking past each other here.? ?You keep talking > about untrusted code, which sounds like applets to me.? I've read > and still have a copy of Li Gong's book, applets were only one of > the considerations.? I am talking about authorization and access > control.? We use and develop distributed or p2p systems, we don't > allow untrusted code to run at all, never ever, that's a dumb > idea, so lets stop talking about untrusted code, we don't use > that.? ? We do utilize dynamic downloaded code from others and use > dynamic class loading, we verify this prior to loading.? We check > it's authorized to run before running it.? Again I repeat, we do > not run untrusted code, that would allow an attacker to cause > denial of service etc, the JVM has no control over badly behaving > code. > > The whole design of the security manager as a ?path-dependent? > deep sandbox is built around untrusted code, hence > all the stack-walking and doPrivileged. Trusted code means assumed > not to be malicious. As such, what you want to protect > against is vulnerabilities. Since you don?t know where they are, > you place the entire application in a sandbox that?s > both more airtight and less complex than the Security Manager. > That is, in fact, how most people do it. > > > > > Of course Java is "able" to do access control, it's well > documented, I have working examples.? No security defense is 100% > effective, if you look at the history of defenses, they continue > to evolve.? Just because ObjectInputStream was a huge security > hole, it didn't inject an unprivileged ProtectionDomain onto the > stack, which would have stopped a number of deserialization > gadgets. ?ObjectInputStream runs as privileged code, tut, tut, > tut! ?Perl taint mode anyone? > > We are not talking about authorisation or access control. We?re > talking about the Security Manager?s design and implementation > which is about code domains and stack-dependence. Serialisation?s > security is one thing and the Security Manager is a whole other > thing. > > > > > Java 6 introduced a security feature where an object will not be > constructed if Object's constructor is not called, so that > invariants must be satisfied before object creation.? Java > Serialziation bypasses this.? Prior to Java 6, objects could be > left in a partially constructed state and obtained via a finalizer > attack. > > > > Besides, serialization whitelists don't protect against denial > of service, so why have them at all if you using trusted systems > and TLS connections?? Java Serialization should never be used to > process untrusted data, because it doesn't and cannot validate > invariants until after objects are constructed which is too late. > As soon as you implement Serializable, all the effort you put into > defensively coding constructors can be bypassed.? ?So why code > defensively at all if we leave a back door wide open anyway?? All > code is trusted now right, soon we can make sure all connections > are secure, so we don't need to worry about input validation > anymore either right, because the users are trusted now too? Maybe > we should just whitelist the classes allowed to run on the JVM and > not worry about coding defensively?? Sounds silly, well that's how > it sounds to me, just thought I'd put it into perspective. > > > > Java Serialization still compromises the security of the JVM > because it doesn't prevent object creation if invariants aren't > satisfied, the vulnerability is still there, and future attackers > will find a way take advantage of it for that reason. > > > > It is clear that no further progress will be made in this matter > and I will simply have to live with the consequences. Stick a fork > in me, because I'm done. > > You are conflating the Security Manager with security. A lot of > security work has been going on in the JDK for the past few years > (and will continue for as long Java exists), but not in the > code-protection-domain-sandbox known as the Security Manager. > > ? Ron > > > > -- > -Peter Tribble > http://www.petertribble.co.uk/ - > http://ptribble.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar" { permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "setIO"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041751026391", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "setPolicy"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.defaultTestConfig", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "testConfiguration", "read"; permission java.util.PropertyPermission "testFailureAnalyzers", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/java.smartcardio" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "jrt:/java.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar;md5=c1233e711b1fc12d6df366839f425ebd" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "setLoginConfiguration"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessSystemModules"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.nio"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "loggerFinder"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "readFileDescriptor"; permission java.lang.RuntimePermission "reflectionFactoryAccess"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.RuntimePermission "writeFileDescriptor"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getNetworkInformation"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jinitests.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041751026391", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.crypto.policy"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred"; permission java.security.SecurityPermission "getProperty.jdk.serialFilter"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.login.config.url.1"; permission java.security.SecurityPermission "getProperty.login.configuration.provider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.securerandom.source"; permission java.security.SecurityPermission "getProperty.security.provider.1"; permission java.security.SecurityPermission "getProperty.security.provider.10"; permission java.security.SecurityPermission "getProperty.security.provider.11"; permission java.security.SecurityPermission "getProperty.security.provider.12"; permission java.security.SecurityPermission "getProperty.security.provider.13"; permission java.security.SecurityPermission "getProperty.security.provider.14"; permission java.security.SecurityPermission "getProperty.security.provider.2"; permission java.security.SecurityPermission "getProperty.security.provider.3"; permission java.security.SecurityPermission "getProperty.security.provider.4"; permission java.security.SecurityPermission "getProperty.security.provider.5"; permission java.security.SecurityPermission "getProperty.security.provider.6"; permission java.security.SecurityPermission "getProperty.security.provider.7"; permission java.security.SecurityPermission "getProperty.security.provider.8"; permission java.security.SecurityPermission "getProperty.security.provider.9"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SUN"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "putProviderProperty.SunJCE"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunJSSE"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunRsaSign"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.security.SecurityPermission "setPolicy"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.util.PropertyPermission "*", "read,write"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/jdk.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar" { permission java.lang.RuntimePermission "createClassLoader"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; }; grant codebase "jrt:/jdk.security.auth" { permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/classserver-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "shutdownHooks"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; }; grant codebase "jrt:/jdk.localedata" { permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "jrt:/java.xml.crypto" { permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.util.PropertyPermission "java.specification.version", "read"; }; From weijun.wang at oracle.com Thu May 6 00:09:52 2021 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Thu, 6 May 2021 00:09:52 +0000 Subject: Java Bug : Mutual HTTPS authentication not possible with a non-extractable private key with Apple/KeychainStore In-Reply-To: <2FD2B199-EF5E-446E-A474-FF09C766F159@gmail.com> References: <254BEC5E-C3DD-4884-9045-40B94A694CCB@oracle.com> <2FD2B199-EF5E-446E-A474-FF09C766F159@gmail.com> Message-ID: > On May 3, 2021, at 1:16 PM, Jean-Yves Cronier wrote: > > Following the advice of Wei-Jun Wang, I share/forward to this mailing-list, details of a problem that I encounter on MacOS. > > At the moment, I don't know how to modify the existing code so that the Apple Provider can behave like SunMSCAPI You won?t be able to do this in an application. This is only possible if the Apple provider also implements Signature. Note: the Apple provider is also maintained by Oracle now. ?Weijun > > >> D?but du message r?exp?di? : >> >> De: Wei-Jun Wang >> Objet: R?p. : Java Bug : Mutual HTTPS authentication not possible with a non-extractable private key with Apple/KeychainStore >> Date: 3 mai 2021 ? 18:11:12 UTC+2 >> ?: Jean-Yves Cronier >> >> And BTW, it?s better to write to an area-specific mail list next time when you find an issue in OpenJDK. The jdk-dev@ mail list is probably too big and people discuss more grand things there. :-) >> >> For security, it?s security-dev at openjdk.java.net. >> >> Thanks, >> Weijun >> >>>>> Le 3 mai 2021 ? 16:03, Wei-Jun Wang a ?crit : >>>>> >>>>> Hi Jean-Yves, >>>>> >>>>> On macOS there?s only native key/certificate management but no signature signing/verification. If you look at https://docs.oracle.com/javase/9/security/oracleproviders.htm, the Apple provider only implements KeyStore. If you need to use a key in client auth, it needs to extract that key and use another provider (SunRsaSign or SunEC) to use it. >>>>> >>>>> On the other hand, SunMSCAPI has implemented both KeyStore and Signature, therefore it can do both things inside the provider and the key does not need to be extracted. >>>>> >>>>> I?ve filed https://bugs.openjdk.java.net/browse/JDK-8266439. >>>>> >>>>> Thanks, >>>>> Weijun >>>>> >>>>>> On May 1, 2021, at 8:19 AM, Jean-Yves Cronier wrote: >>>>>> >>>>>> Description >>>>>> >>>>>> I have imported my personal certificate in macOS keychain with "non-extractable" option (cf. https://ss64.com/osx/security-export.html). >>>>>> Private key is now protected, and we can't export private key from macOS KeyChain >>>>>> But I am unable to establish connexion with a web-API which require client certificate for mutual authentication with Java >>>>>> It work perfectly well with curl/git, and browsers (safari/chrome) >>>>>> >>>>>> >>>>>> <>System / OS / Java Runtime Information >>>>>> >>>>>> openjdk 11.0.11 >>>>>> macOS 11.3 >>>>>> >>>>>> >>>>>> <>Steps to Reproduce >>>>>> >>>>>> 1. Add personal certificate with "non-extractable" option. Example with a personal certificate sent to me in a P12 file named "my-certificate.p12", with following command-line: >>>>>> security import my-certificate.p12 -x -P ? my-strong-password" >>>>>> 2. Connect a site require mutual authentication (for example : https://server.cryptomix.com/secure/ ) >>>>>> >>>>>> >>>>>> <>Expected Result >>>>>> >>>>>> Display content detail of selected client certificate >>>>>> >>>>>> >>>>>> <>Actual Result >>>>>> >>>>>> Error: No TLS client certificate presented >>>>>> >>>>>> >>>>>> <>Source code for an executable test case >>>>>> >>>>>> import javax.net.ssl.HttpsURLConnection; >>>>>> import java.io.IOException; >>>>>> import java.net.URL; >>>>>> import java.security.cert.X509Certificate; >>>>>> >>>>>> public class MutualAuthenticationTest { >>>>>> public static void main(String[] args) throws IOException { >>>>>> System.setProperty("javax.net.ssl.keyStoreType", "KeychainStore"); >>>>>> System.setProperty("javax.net.ssl.keyStore", "NONE"); >>>>>> System.setProperty("javax.net.ssl.keyStorePassword", "-"); >>>>>> testUrl(new URL("https://server.cryptomix.com/secure/")); >>>>>> } >>>>>> >>>>>> public static void testUrl(URL targetUrl) throws IOException { >>>>>> HttpsURLConnection con = (HttpsURLConnection) targetUrl.openConnection(); >>>>>> // Open the connection >>>>>> con.getResponseCode(); >>>>>> >>>>>> assert con.getLocalCertificates() != null && con.getLocalCertificates().length > 0 : "Must use a personnel certificate for mutual authentication"; >>>>>> X509Certificate personalCertificate = (X509Certificate) con.getLocalCertificates()[0]; >>>>>> assert personalCertificate.getSubjectDN() != null; >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> <>Workaround >>>>>> >>>>>> No possible workaround on MacOS which Apple/KeychainStore >>>>>> NB : Perfectly work on Windows/MSCAPI with personnel certificate (with non-exportable private key option) >>>> >>> >> > From valeriep at openjdk.java.net Thu May 6 01:26:53 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 6 May 2021 01:26:53 GMT Subject: RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 17:35:46 GMT, Weijun Wang wrote: > `PKCS12KeyStore` always uses a 20-byte salt in encryption but PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt used for this algorithm will be 8 bytes. > > RFC 2898 only requires the salt to be at least 8 bytes, but I don't intend to modify the `PBES1Core.java` to accept a long salt. Otherwise, a newly generated PKCS #?12 file using a long salt will not be recognized by an old JDK. > > Also, although `PBES1Core.java` also take cares of another algorithm named PBEWithMD5AndDESede but it's not usable in a PKCS #?12 keystore as we have not defined its Object Identifier anywhere. src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 811: > 809: byte[] salt = getSalt(); > 810: if (KnownOIDs.findMatch(algorithm) == KnownOIDs.PBEWithMD5AndDES) { > 811: // PBEWithMD5AndDES requires a 8-byte salt nit: maybe use "PBES1 scheme such as PBEWithMD5AndDES requires a 8-byte salt" ------------- PR: https://git.openjdk.java.net/jdk/pull/3822 From ssahoo at openjdk.java.net Thu May 6 05:53:54 2021 From: ssahoo at openjdk.java.net (Sibabrata Sahoo) Date: Thu, 6 May 2021 05:53:54 GMT Subject: Integrated: 8180568: Refactor javax/crypto shell tests to plain java tests In-Reply-To: <48tPj8EJ5WABFRBKUu5g-PLZuJA7-Eu4ltcicXgM5eM=.9b9b74f9-5fd7-4773-a43c-39e003d524eb@github.com> References: <48tPj8EJ5WABFRBKUu5g-PLZuJA7-Eu4ltcicXgM5eM=.9b9b74f9-5fd7-4773-a43c-39e003d524eb@github.com> Message-ID: <2SfH11iTDBq2KW8UMMCwkw376D83MEZAAsLzv2W1R4w=.9259d312-b969-4bff-ab79-38c12813021f@github.com> On Wed, 5 May 2021 10:00:22 GMT, Sibabrata Sahoo wrote: > This change is to remove the shell Test and convert to it's java equivalent. That is the reason the shell Tests are deleted and the equivalent Java implementation provided. > The purpose of the Test TestExemption.java is with limited crypto policy a JCE provider can supplemented additional crypto permissions through "cryptoPerms" file bundled inside the JCE signed jar. > It also need to be noticed that TestExemption.java has '@requires java.runtime.name ~= "OpenJDK.*"'. It looks the intension of this Test availability in open GIT is to run by any other JDK providers. This pull request has now been integrated. Changeset: 20ad4289 Author: Sibabrata Sahoo URL: https://git.openjdk.java.net/jdk/commit/20ad42897427483a4a62e1de7e78d4620eb9e240 Stats: 339 lines in 4 files changed: 138 ins; 183 del; 18 mod 8180568: Refactor javax/crypto shell tests to plain java tests Reviewed-by: wetmore ------------- PR: https://git.openjdk.java.net/jdk/pull/3876 From peter.firmstone at zeus.net.au Thu May 6 06:17:22 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 6 May 2021 16:17:22 +1000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <44BEE615-D56A-4790-989A-2CDAE66F28FE@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <44BEE615-D56A-4790-989A-2CDAE66F28FE@oracle.com> Message-ID: <8c5d59ad-655f-9f8b-b744-16a59753fa0e@zeus.net.au> On 21/04/2021 10:38 pm, Ron Pressler wrote: > > There is no argument that this is a powerful capability *in theory*; > the problem is that it?s difficult to correctly employ this capability > correctly *in practice*. See > this paper for an empirical study: > http://www.cs.cmu.edu/~clegoues/docs/coker15acsac.pdf > > It's a shame the authors weren't able to study an application that really ran the security manager through it's paces.? They do exist, for example Apache River isn't on the list, neither is Rio or Sorcer.?? These certainly aren't perfect, my project on github, JGDMS was created to demonstrate the security fixes for issues in Apache River, to convince users who were not receptive to addressing security problems. I've added it here since security seems to be a popular discussion point, so that I can show where SecurityManager, AccessController, Policy etc, fit into our overarching security model. Back when Apache inherited the Jini source code from Sun Microsystems, the designers had made the assumption that Java Serialization was secure, due to the sandbox.? Maybe Java Serialization and the sandbox should have been securem but like most things they were designed with flaw's.? One of the problems was that security was added in Jini 2.0, while Jini 1.0 had no security at all.? At that time security was bolted on feature and hadn't been completed when it shipped. So on the assumption that Java had a secure sandbox, the Jini developers allowed code to be downloaded dynamically, then data deserialized into it, then they would check to see if the proxy was valid using a mechanism called proxy trust, where the asked the remote end to validate the proxy.?? They did have TLS connections, and they had constraints to ensure that you didn't use an insecure connection, however the problem was, these things were applied after downloading and deserializing!?? The other problem was that the calling Subject wasn't always preserved over threads, so code using secure connections didn't work the same as insecure TCP connections. I think you can see the problem here and I think this is the problem people are talking about when they are talking about sandboxes. I have spent years refactoring this code from the ground up, while trying to maintain backward compatibility as best as possible.? If you think Java developers are fussy about backward compatibility, you haven't met a Jini or Javaspace developer, but I can't blame them because they were subject to the horrors of Java Serialization and code written prior to the Java Memory Model that shipped with Java 5. So security was broken, I took it upon myself to fix it, and the users didn't believe it was broken or insecure as they had drunk the sandbox coolaid, this is why I don't talk about sandboxing. One user even suggested that I use the broken ProxyTrust security mechanism to fix the security issues.? At that time before 2010, it wasn't common knowledge among developers that Java Serialization was insecure, there were some reports, and IBM had discussed and published information on whitelisting, or look ahead serialization. I had to redesign the system, but still allow it to run insecurely for testing or for users who used it behind firewalls and didn't want security features.? It had been originally designed to be configurable, such that it can be configured secure, or configured insecure, and it's quite obvious which is which.? It doesn't use configuration files, but instead a Java syntax or Groovy. I won't go into all the things that were required for security, but I will say that now a TLS connection is made first (with both client and server authentication), then we download the code, dynamically grant permissions to it, then de-serialize into it the ClassLoader created for it, that ClassLoader remains with the communication endpoint and makes all class resolution decisions. We don't use Java Serialization anymore either, instead we use constructors with a caller sensitive parameter, that's been discussed here previously, but it is capable of checking intra object invariants. So we don't rely on sandboxing, or the sandbox, but we authenticate, validate and limit permissions to the principle of least privilege, as part of an overarching security strategy. Here's an example of the requested permissions in downloaded code (note JRMP is only there for backward compatibility, it is deprecated). https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/services/reggie/reggie-dl/src/main/resources/META-INF/PERMISSIONS.LIST You can see from the attached file it was granted very few permissions at runtime (in case anyone is wondering the md5 checksum is deprecated, but still used in the test suite): All these permissions were granted dynamically, they didn't exist prior to the connection with the remote server, they don't exist in a policy file, policy files used don't often require editing. grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { ??? permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77", ??? principal javax.security.auth.x500.X500Principal "CN=Tester" { ??? permission javax.security.auth.AuthPermission "getSubject"; ??? permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; ??? permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; ??? permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; ??? permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; ??? permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; ??? permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; }; Prior to downloading and after authentication, a permission called DownloadPermission, which should really be called ClassLoadingPermission is granted dynamically, as well as permission to connect to the remote network endpoint as well as a URLPermission.? These aren't shown here as they are part of the ProtectionDomain's permission list.? It's a given that these will be granted dynamically when a ClassLoader is created to load the code.?? Then the permissions in the PERMISSIONS.LIST file will be granted after class loading, if the user or calling code has GrantPermission to do so.? A UI may also be included that provides a user interface for users to interact with the service. So as you can see, we don't rely on the sandbox and we don't trust Java Serialization.? We have our own serialization implementation, we haven't disabled Java serialization, but it is recommended the user do so with a global filter. It may sound complex, but it is an automated process with tools that allow it to occur. The code doesn't require many permissions to run, so it isn't given any more than needed. Once the SecurityManager has been removed, I'm assuming that the downloaded code from our trusted third party, will be able to access files and data should they want to, anything the process has access to at least.? Of course there are a lot of places in our API's where security checks occur and these would no longer restrict access. This is why I refer to SecurityManager an access control mechanism and I don't refer to it a sandbox.? It is a very good access control mechanism and it supplements type safety, class verification, object encapsulation. It is part of our overarching security infrastructure, but most certainly by itself, it is not responsible for security. Our system is dynamic, the problems mentioned regarding library changes are not an issue, these are simply updated when a new library (or a new version of Java) is deployed. I hope this helps provide an understanding. For those that aren't aware, Jini was meant to allow Java to cluster dynamically, to dynamically discover services in the network, now people then didn't get it, but it's very similar to microservices.? Javaspaces is a distributed database.?? There were problems with IPv4 and NAT (Jini requires end to end connectivity, not a publish subscribe model), security and complexity that prevented Jini from taking off.? Today all these problems are solved, you'll notice we use IPv6 for end to end connectivity. So we have all these tools built on top of Java that allow you to do security properly.? Java 1.4 Security implementations were actually changed to allow Dynamic Permission's for Jini. Sun owned the copyright, I think Oracle may still do so, it was donated under the Apache 2.0 License, I have kept the code change history going back to the original donation, I would certainly donate anything I have done to OpenJDK (and I am responsible for the majority of the security changes), should they wish to use it, it would require Oracle to donate the original code as GPL to OpenJDK. The easiest way of thinking about it, is it's the glue that ties together multiple JVM's on multiple servers to act as a single system, that discovers components dynamically as they are added and upgraded.? It is an extremely capable and well designed system, now that the major issues have been solved.? Every thing is POJO domain driven design in Java. There's a common misconception it uses RMI, it doesn't, it uses something far better. Distributed Object garbage collection works (properly without race conditions) over secure network connections and user Subjects are preserved over network calls.? RMI doesn't have that capability, it's also extensible, so it can use different communication layers, different serialization layers, different transport layers, it's all configurable and pluggable.? Using IPv6, it can also communicate and discovery globally, so a system can be spread around different part of the world and tie together into one system. It's scalable and damn fast too, while it does block waiting for network replies, it doesn't have any hotspots, the hotspot's are all Java platform code :) https://pfirmstone.github.io/JGDMS/old-static-site/images/River-internet_mahalo_randomStressTest.PNG (This old screenshot is back when we were still using Java Serialization.? I'll have to do a comparison for with secure code, this was using unsecured communication.)? Today we use the latest TLSv1.3 features and protocols. You could say it was the first IoT, but now, it is far more powerful, more secure and capable than IoT.? We've had 20 years to figure it out.? It is still under active development.?? The current focus is a public Serialization API that will work with Java's module system, without breaking Object encapsulation. Although part of this depends on SecurityManager Permissions. Once SecurityManager is removed, that is the last version of Java we will support, we will no longer be able stay with you until we figure out how to fix access control, however I fear that this functionality can only be provided at the Java platform level. This is basically a toolkit, most users are developers from large corporations who don't publicly share their implementations, but there are a few: http://river.apache.org/user-doc/success-stories.html -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. -------------- next part -------------- grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jiniharness.jar" { permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "setIO"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041751026391", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "setPolicy"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.defaultTestConfig", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "testConfiguration", "read"; permission java.util.PropertyPermission "testFailureAnalyzers", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/java.smartcardio" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "jrt:/java.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar;md5=c1233e711b1fc12d6df366839f425ebd" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test"; permission javax.security.auth.AuthPermission "doAsPrivileged"; permission javax.security.auth.AuthPermission "getLoginConfiguration"; permission javax.security.auth.AuthPermission "getSubject"; permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner"; permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission javax.security.auth.AuthPermission "setLoginConfiguration"; permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; permission java.lang.RuntimePermission "accessDeclaredMembers"; permission java.lang.RuntimePermission "accessSystemModules"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "createSecurityManager"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.lang.RuntimePermission "getStackWalkerWithClassReference"; permission java.lang.RuntimePermission "getenv.SOUL"; permission java.lang.RuntimePermission "loadLibrary.net"; permission java.lang.RuntimePermission "loadLibrary.nio"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.lang.RuntimePermission "loadLibrary.sunmscapi"; permission java.lang.RuntimePermission "loadLibrary.zip"; permission java.lang.RuntimePermission "localeServiceProvider"; permission java.lang.RuntimePermission "loggerFinder"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "readFileDescriptor"; permission java.lang.RuntimePermission "reflectionFactoryAccess"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "setIO"; permission java.lang.RuntimePermission "shutdownHooks"; permission java.lang.RuntimePermission "writeFileDescriptor"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission java.net.NetPermission "getCookieHandler"; permission java.net.NetPermission "getNetworkInformation"; permission java.net.NetPermission "getProxySelector"; permission java.net.NetPermission "getResponseCache"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13530489763375062441.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "delete"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "read"; permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache6285608515666175907.tmp", "write"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\test.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jinitests.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\soul\\soul.202105041751026391", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\spec\\lookupservice\\test_set02\\org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission java.io.FilePermission "org\\apache\\river\\test\\spec\\lookupservice\\configs\\jsse\\default.config", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.security.SecurityPermission "createAccessControlContext"; permission java.security.SecurityPermission "createPolicy.JiniPolicy"; permission java.security.SecurityPermission "getDomainCombiner"; permission java.security.SecurityPermission "getPolicy"; permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler"; permission java.security.SecurityPermission "getProperty.crypto.policy"; permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies"; permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred"; permission java.security.SecurityPermission "getProperty.jdk.serialFilter"; permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits"; permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms"; permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters"; permission java.security.SecurityPermission "getProperty.keystore.type"; permission java.security.SecurityPermission "getProperty.keystore.type.compat"; permission java.security.SecurityPermission "getProperty.login.config.url.1"; permission java.security.SecurityPermission "getProperty.login.configuration.provider"; permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty"; permission java.security.SecurityPermission "getProperty.policy.expandProperties"; permission java.security.SecurityPermission "getProperty.securerandom.drbg.config"; permission java.security.SecurityPermission "getProperty.securerandom.source"; permission java.security.SecurityPermission "getProperty.security.provider.1"; permission java.security.SecurityPermission "getProperty.security.provider.10"; permission java.security.SecurityPermission "getProperty.security.provider.11"; permission java.security.SecurityPermission "getProperty.security.provider.12"; permission java.security.SecurityPermission "getProperty.security.provider.13"; permission java.security.SecurityPermission "getProperty.security.provider.14"; permission java.security.SecurityPermission "getProperty.security.provider.2"; permission java.security.SecurityPermission "getProperty.security.provider.3"; permission java.security.SecurityPermission "getProperty.security.provider.4"; permission java.security.SecurityPermission "getProperty.security.provider.5"; permission java.security.SecurityPermission "getProperty.security.provider.6"; permission java.security.SecurityPermission "getProperty.security.provider.7"; permission java.security.SecurityPermission "getProperty.security.provider.8"; permission java.security.SecurityPermission "getProperty.security.provider.9"; permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm"; permission java.security.SecurityPermission "putProviderProperty.JdkLDAP"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; permission java.security.SecurityPermission "putProviderProperty.SUN"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; permission java.security.SecurityPermission "putProviderProperty.SunJCE"; permission java.security.SecurityPermission "putProviderProperty.SunJGSS"; permission java.security.SecurityPermission "putProviderProperty.SunJSSE"; permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI"; permission java.security.SecurityPermission "putProviderProperty.SunPCSC"; permission java.security.SecurityPermission "putProviderProperty.SunRsaSign"; permission java.security.SecurityPermission "putProviderProperty.SunSASL"; permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.security.SecurityPermission "setPolicy"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "connect,accept,resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.util.PropertyPermission "*", "read,write"; permission java.util.logging.LoggingPermission "control"; }; grant codebase "jrt:/jdk.security.jgss" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.security.SecurityPermission "putProviderProperty.JdkSASL"; }; grant codebase "httpmd://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar;md5=a28068d398d636dd8fbeace7df8faa77" { permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; }; grant codebase "jrt:/jdk.crypto.ec" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509"; permission java.lang.RuntimePermission "loadLibrary.sunec"; permission java.security.SecurityPermission "putProviderProperty.SunEC"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.io.SerializablePermission "enableSubclassImplementation"; permission java.io.SerializablePermission "enableSubstitution"; permission org.apache.river.jeri.internal.EndpointInternalsPermission "set"; permission java.lang.reflect.ReflectPermission "suppressAccessChecks"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission org.apache.river.api.io.DeSerializationPermission "ATOMIC"; permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject"; permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Tester\"", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar" { permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:"; permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission javax.security.auth.AuthPermission "getSubject"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.io.FilePermission "harness\\trust\\truststore", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/jinitests.jar" { permission java.lang.RuntimePermission "createClassLoader"; permission java.util.PropertyPermission "loader.requireDlPerm", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; }; grant codebase "jrt:/jdk.security.auth" { permission javax.security.auth.AuthPermission "modifyPrincipals"; permission javax.security.auth.AuthPermission "modifyPrivateCredentials"; permission javax.security.auth.AuthPermission "modifyPublicCredentials"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5"; permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; permission java.lang.RuntimePermission "getProtectionDomain"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read"; }; grant codebase "jrt:/jdk.crypto.cryptoki" { permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/classserver-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool"; permission java.lang.RuntimePermission "getClassLoader"; permission java.lang.RuntimePermission "modifyThread"; permission java.lang.RuntimePermission "modifyThreadGroup"; permission java.lang.RuntimePermission "setContextClassLoader"; permission java.lang.RuntimePermission "shutdownHooks"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; }; grant codebase "jrt:/jdk.localedata" { permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider"; permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources"; }; grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar", principal javax.security.auth.x500.X500Principal "CN=Tester" { permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool"; permission javax.security.auth.AuthPermission "getSubject"; permission java.lang.RuntimePermission "exitVM.0"; permission org.apache.river.api.io.DeSerializationPermission "MARSHALL"; permission java.net.NetPermission "specifyStreamHandler"; permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\java", "execute"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\dynamic-policy.properties", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\phoenix.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\truststore", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\nonactivatablegroup-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\qa1-lookupservice-dl.jar", "read"; permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\src\\org\\apache\\river\\test\\resources\\jinitest.policy", "read"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\"", "listen"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Phoenix\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept"; permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Tester\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect"; permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Tester\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\"\", \"connect\";"; permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve"; permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4506", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4509", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4510", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4526", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4529", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4530", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4531", "connect,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4532", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4533", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4555", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4580", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4596", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4604", "accept,resolve"; permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:4605", "accept,resolve"; permission java.net.SocketPermission "localhost:0", "listen,resolve"; permission java.net.SocketPermission "localhost:9080", "listen,resolve"; permission java.net.SocketPermission "localhost:9081", "listen,resolve"; permission java.net.SocketPermission "localhost:9082", "listen,resolve"; permission java.util.PropertyPermission "/", "read"; permission java.util.PropertyPermission "HOST", "read"; permission java.util.PropertyPermission "activation.jar", "read"; permission java.util.PropertyPermission "bouncy-jce.jar", "read"; permission java.util.PropertyPermission "bouncy-jsse.jar", "read"; permission java.util.PropertyPermission "classserver.jar", "read"; permission java.util.PropertyPermission "collections.jar", "read"; permission java.util.PropertyPermission "destroy.jar", "read"; permission java.util.PropertyPermission "disco.jar", "read"; permission java.util.PropertyPermission "fiddler-dl.jar", "read"; permission java.util.PropertyPermission "fiddler.jar", "read"; permission java.util.PropertyPermission "file.ext", "read"; permission java.util.PropertyPermission "globalclasspath", "read"; permission java.util.PropertyPermission "group.jar", "read"; permission java.util.PropertyPermission "high-scale-lib.jar", "read"; permission java.util.PropertyPermission "java.class.path", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "java.rmi.server.codebase", "read"; permission java.util.PropertyPermission "java.util.logging.config.file", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read"; permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read"; permission java.util.PropertyPermission "jeri.jar", "read"; permission java.util.PropertyPermission "jgdms-rmi-tls.jar", "read"; permission java.util.PropertyPermission "jiniClassServer.adminName", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.dir", "read"; permission java.util.PropertyPermission "jiniClassServer.dir.0", "read"; permission java.util.PropertyPermission "jiniClassServer.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.impl.0", "read"; permission java.util.PropertyPermission "jiniClassServer.port", "read"; permission java.util.PropertyPermission "jiniClassServer.port.0", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "jiniClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "jiniClassServer.transient.impl", "read"; permission java.util.PropertyPermission "jiniClassServer.type", "read"; permission java.util.PropertyPermission "jiniClassServer.type.0", "read"; permission java.util.PropertyPermission "jiniClassServer.type.1", "read"; permission java.util.PropertyPermission "jsk-dl.jar", "read"; permission java.util.PropertyPermission "jsk-lib.jar", "read"; permission java.util.PropertyPermission "jsk.iiop.jar", "read"; permission java.util.PropertyPermission "jsk.jrmp.jar", "read"; permission java.util.PropertyPermission "jsk.pref.jar", "read"; permission java.util.PropertyPermission "jsk.url.jar", "read"; permission java.util.PropertyPermission "loader.jar", "read"; permission java.util.PropertyPermission "mahalo-dl.jar", "read"; permission java.util.PropertyPermission "mahalo.jar", "read"; permission java.util.PropertyPermission "mercury-dl.jar", "read"; permission java.util.PropertyPermission "mercury.jar", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.adminName", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.instances", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.classpath.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.codebase.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.component.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.impl.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.integrityhash.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.log.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.membergroups.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.policyfile.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.port.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.preparername.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.running.1", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.serviceConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.starterConfiguration.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.transient.tojoin.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.0", "read"; permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.type.1", "read"; permission java.util.PropertyPermission "net.jini.discovery.announce", "read"; permission java.util.PropertyPermission "nonActivatableGroup.adminName", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.classpath.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.codebase.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.impl.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.integrityhash.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.nonactivatablegroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile", "read"; permission java.util.PropertyPermission "nonActivatableGroup.policyfile.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvm.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs", "read"; permission java.util.PropertyPermission "nonActivatableGroup.serverjvmargs.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.transient.impl", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.0", "read"; permission java.util.PropertyPermission "nonActivatableGroup.type.1", "read"; permission java.util.PropertyPermission "norm-dl.jar", "read"; permission java.util.PropertyPermission "norm.jar", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read"; permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.home", "read"; permission java.util.PropertyPermission "org.apache.river.jsk.port", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.callAutoT", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9080", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.dldir.9081", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.globalvmargs", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.integrityhash", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.nSecsWaitDestroy", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runjiniserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.runkitserver", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.securityproperties", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.serviceMode", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.shared", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.startDelay", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testClassServer", "read"; permission java.util.PropertyPermission "org.apache.river.qa.harness.testhosts", "read"; permission java.util.PropertyPermission "org.apache.river.qa.home", "read"; permission java.util.PropertyPermission "org.apache.river.qa.port", "read"; permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read"; permission java.util.PropertyPermission "org.apache.river.test.home", "read"; permission java.util.PropertyPermission "org.apache.river.test.port", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actClasspath", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.actCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTEvntNotify", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTListener", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.deltaTSrvcLeaseExp", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.nInstancesPerClass", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.outputRoot", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.policy", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.rmiCodebase", "read"; permission java.util.PropertyPermission "org.apache.river.test.spec.lookupservice.selectMethod", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "outrigger-dl.jar", "read"; permission java.util.PropertyPermission "outrigger-snaplogstore.jar", "read"; permission java.util.PropertyPermission "outrigger.jar", "read"; permission java.util.PropertyPermission "phoenix-common.jar", "read"; permission java.util.PropertyPermission "phoenix-dl.jar", "read"; permission java.util.PropertyPermission "phoenix-group.jar", "read"; permission java.util.PropertyPermission "phoenix-init.jar", "read"; permission java.util.PropertyPermission "phoenix.jar", "read"; permission java.util.PropertyPermission "platform.jar", "read"; permission java.util.PropertyPermission "policy.writer.jar", "read"; permission java.util.PropertyPermission "qaClassServer.adminName", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.dir", "read"; permission java.util.PropertyPermission "qaClassServer.dir.0", "read"; permission java.util.PropertyPermission "qaClassServer.impl", "read"; permission java.util.PropertyPermission "qaClassServer.impl.0", "read"; permission java.util.PropertyPermission "qaClassServer.port", "read"; permission java.util.PropertyPermission "qaClassServer.port.0", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "qaClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "qaClassServer.transient.impl", "read"; permission java.util.PropertyPermission "qaClassServer.type", "read"; permission java.util.PropertyPermission "qaClassServer.type.0", "read"; permission java.util.PropertyPermission "qaClassServer.type.1", "read"; permission java.util.PropertyPermission "reggie-dl.jar", "read"; permission java.util.PropertyPermission "reggie.jar", "read"; permission java.util.PropertyPermission "river.version", "read"; permission java.util.PropertyPermission "start.jar", "read"; permission java.util.PropertyPermission "testClassServer.adminName", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.classServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.classServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port", "read"; permission java.util.PropertyPermission "testClassServer.classServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.classServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.dir", "read"; permission java.util.PropertyPermission "testClassServer.dir.0", "read"; permission java.util.PropertyPermission "testClassServer.impl", "read"; permission java.util.PropertyPermission "testClassServer.impl.0", "read"; permission java.util.PropertyPermission "testClassServer.port", "read"; permission java.util.PropertyPermission "testClassServer.port.0", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs", "read"; permission java.util.PropertyPermission "testClassServer.serverjvmargs.0", "read"; permission java.util.PropertyPermission "testClassServer.transient.impl", "read"; permission java.util.PropertyPermission "testClassServer.type", "read"; permission java.util.PropertyPermission "testClassServer.type.0", "read"; permission java.util.PropertyPermission "testClassServer.type.1", "read"; permission java.util.PropertyPermission "user.dir", "read"; }; grant codebase "jrt:/java.xml.crypto" { permission java.security.SecurityPermission "putProviderProperty.XMLDSig"; permission java.util.PropertyPermission "java.specification.version", "read"; }; From peter.firmstone at zeus.net.au Thu May 6 10:26:07 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Thu, 6 May 2021 20:26:07 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> Message-ID: On 5/05/2021 10:55 pm, Sean Mullan wrote: > - >> Obviously we won't have a call stack with domains, I don't know how >> we will transfer the user Subject to other threads, for TLS and >> Kerberos connections.? No doubt something is planned. > > There is a plan for preserving the capability to transfer Subjects to > other threads. It is described in the JEP: > > https://openjdk.java.net/jeps/411#Alternate-JAAS-APIs > > --Sean Thanks for the reference Sean. > >> >> Is the recommendation simply not to upgrade Java until new access >> control API is developed? >> >> >> >>>> Please provide some examples, migration options suggestions will be >>>> appreciated. >>> I?ve jotted down some thoughts in a blog post: >>> https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ >>> >> Please read the following carefully and ask questions to clarify if needed. OpenJDK seems to have assumed that no one was using SecurityManager based on one research report. ? There's a lot of closed source java code out there, I suspect most of our users are closed source.? I don't know exactly how many compute nodes our users have, but it's 100's to 1000's, we seldom hear from them, maybe a patch here or there, then you don't hear from someone for years, and then you receive a patch.? These users don't advertise they're using our systems either. Some feedback, we preserve context within Executor threads. AccessController scalability and performance is very good, we carefully capture and re-establish security contexts in Executor threads. AccessController::getContext() is 0.5% of system load, with no scalability issues. AccessController::doPrivileged() is 2.3% of total cpu load, with no scalability issues. There are no other security? calls on the list of hotspots, unless you include Class.getProtectionDomain, which is 0.2% Like I've mentioned previously, our policy provider is highly scalable as is our SecurityManager implementation.? Our policy providers decorate functionality onto each other: https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/ConcurrentPolicyFile.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/net/jini/security/policy/DynamicPolicyProvider.java https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java It's a shame that SecurityManager is crippled on Loom's virtual threads, I was looking forward to using Loom for blocking network connections.? Oh well, scratch that Idea, we wouldn't be able to make TLS connections with them.? I was hoping Loom would reduce memory consumption, but then I haven't read enough about it.? We consume a lot of threads, one of the thread factory's at least set the thread memory to a lower value than default to save memory. Is Loom is designed to run small rapidly completing non blocking tasks? The performance assumptions made by Ron only apply to the unloved policy provider included with Java.? The Sun file policy provider implementation is a toy designed to get people started, no tooling, no dynamic permission grants, it was really only there to provide hooks for customization, applets maybe?? Sorry, I have to admit, I've never written an applet.? The second constructor added to ProtectionDomain in Java 1.4 added support for dynamic policy grants, but it was not implemented by Policy file, it was done for a reason however.? ? I mean it was designed when Sun Sparc servers had 4 to 8 CPU's, and x86 was 32 bit single cpu, unless you spent big on Unix hardware.? Sun policy file has only had some very minor updates since, it has a blocking cache, yuck! Our policy cache is immutable after publication. Mutable state is not shared among threads in our policy providers. Our dynamic grants are removed after the downloaded code is no longer required, our dynamic policies are self populating and self cleaning.? They also operate under principles of least privilege. We can also have a common policy file, or even a policy network service for policy (just decorate it on top of a minimum set of permissions required to get you started). This is far less complicated than people are making out, it's not atomic physics.? Loom seems far more complicated than SecurityManager.? Policy features are added using policy decorators.? After you look through these implementations, you will see it's not that complex. Also I'm pretty sure a cluster of compute nodes with JVM's is probably going to be called a server.? Ron, your assumptions don't apply to our use case, they apply to Sun File Policy provider. When? Ron writes that SecurityManager is disabled on the common pool and Loom's virtual threads, I hope he means that these threads have no privileges, rather than all privileges?? There is some documentation on the common pool regarding SecurityManger, but little on Loom's virtual threads.? Can someone point me to a reference to security documentation on these features please? > Security Manager is not a central component for securing trusted > server-side code, a good thing, too, because few systems use it and it > doesn?t defend against some of the most common and dangerous exploits. > In fact, the Security Manager is already crippled on the common pool > > (and on Loom?s virtual threads > ) > because setting up appropriate security contexts would defeat the > performance requirements of those constructs, and using it with > |CompletableFuture|s or any asynchronous (or ?reactive?) context > requires the developer to carefully capture and reestablish > > security contexts as operations travel from one thread to another. If we disable Java serialization, we don't use XML, we validate invariants in our constructors and design for failure atomicity, we design to encapsulate, we avoid shared mutable state as much as possible, use immutability, we check third party libraries for security vulnerabilities, we perform static code analysis and we are running code using the principle of least privilege, we use the latest available TLSv1.3 cyphers and disable earlier versions.? Do you believe we are still vulnerable to these most common and dangerous exploits? Perhaps we are still vulnerable to unknown or zero day exploits? It is my opinion that removing the principle of least privilege will not improve the security of our software, but rather degrade it.? But then Java hasn't had a good reputation for security in recent years, thanks to Serialization, granted OpenJDK has done a lot to swat bugs as they're discovered in recent years, it will take a little more time to build a good reputation.? Personally I wouldn't be removing SecurityManager, I'd be addressing the issues and cleaning it up so programs can be run with principles of least privilege, I know it's not perfect, but nothing ever is, but it should improve with time, if it's not neglected and replaced if needed. https://en.wikipedia.org/wiki/Principle_of_least_privilege Maybe Unix sockets will provide a performance boost, Sockets are our major hotspot at 42.5% https://pfirmstone.github.io/JGDMS/old-static-site/images/River-internet_mahalo_randomStressTest.PNG I guess you now have a use case for what SecurityManager is capable of. It's a shame it took SecurityManager's proposed removal for you to discover it has practical application.?? You are right on one respect, not enough people take security seriously. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pconcannon at openjdk.java.net Thu May 6 11:21:38 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 11:21:38 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v2] In-Reply-To: References: Message-ID: > 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8265426 - 8265426: Update java.security to use instanceof pattern variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3687/files - new: https://git.openjdk.java.net/jdk/pull/3687/files/d4354248..29308d6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=00-01 Stats: 499579 lines in 4003 files changed: 17611 ins; 476005 del; 5963 mod Patch: https://git.openjdk.java.net/jdk/pull/3687.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3687/head:pull/3687 PR: https://git.openjdk.java.net/jdk/pull/3687 From ron.pressler at oracle.com Thu May 6 11:46:33 2021 From: ron.pressler at oracle.com (Ron Pressler) Date: Thu, 6 May 2021 11:46:33 +0000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> Message-ID: <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com> > On 6 May 2021, at 11:26, Peter Firmstone wrote: > > OpenJDK seems to have assumed that no one was using SecurityManager based on one research report. There's a lot of closed source java code out there, I suspect most of our users are closed source. I don't know exactly how many compute nodes our users have, but it's 100's to 1000's, we seldom hear from them, maybe a patch here or there, then you don't hear from someone for years, and then you receive a patch. These users don't advertise they're using our systems either. While it is, indeed, our assumption that very few people use Security Manager, and fewer still use it for security, this assumption is not based not based just on one report, and, even then, it is a working hypothesis, and this JEP is a call for feedback. I do, however, think it is telling that so far, despite this proposal being quite well advertised, you are the only one who has stepped up and said that you?re relying on the Security Manager for security *and* find it hard to envision alternatives to an extremely complex mechanism designed for the sole purpose of running code with different permission levels in the same process, an approach that, over the last couple of decades has become disfavoured by both security experts and end-users. The marginal gain in security, if any, of giving different permissions to different portions of the same process does not justify the extra work, and even if it did, most people don?t do it. The Java ecosystem is huge, and most libraries simply don't work well with this mechanism. When the entire process has the same permissions ? in line with current practice ? there are superior sandboxes provided by the OS. > > Some feedback, we preserve context within Executor threads. > > AccessController scalability and performance is very good, we carefully capture and re-establish security contexts in Executor threads. > Most performance issues have to do with the stack walking at the core of the Security Manager?s design. > > It's a shame that SecurityManager is crippled on Loom's virtual threads, I was looking forward to using Loom for blocking network connections. Oh well, scratch that Idea, we wouldn't be able to make TLS connections with them. I was hoping Loom would reduce memory consumption, but then I haven't read enough about it. We consume a lot of threads, one of the thread factory's at least set the thread memory to a lower value than default to save memory. Is Loom is designed to run small rapidly completing non blocking tasks? It is meant to run a great many concurrent tasks performing blocking operations (although they translate to non-blocking I/O once they reach the OS). Obviously, many of those will be short-lived, as you?d be able to spawn a new thread just for the purpose of, say, doing one HTTP client call. > > This is far less complicated than people are making out, it's not atomic physics. Loom seems far more complicated than SecurityManager. Policy features are added using policy decorators. After you look through these implementations, you will see it's not that complex. 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. We know that, for reasons good or bad, very few people opt to use it, and that most who do, do it incorrectly. If, twenty five years from now, it turns out that Loom?s record is similar, I have little doubt that a similar proposal would be raised then. > > When Ron writes that SecurityManager is disabled on the common pool and Loom's virtual threads, I hope he means that these threads have no privileges, rather than all privileges? There is some documentation on the common pool regarding SecurityManger, but little on Loom's virtual threads. Can someone point me to a reference to security documentation on these features please? 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) > > It is my opinion that removing the principle of least privilege will not improve the security of our software, but rather degrade it. But then Java hasn't had a good reputation for security in recent years, thanks to Serialization, granted OpenJDK has done a lot to swat bugs as they're discovered in recent years, it will take a little more time to build a good reputation. Personally I wouldn't be removing SecurityManager, I'd be addressing the issues and cleaning it up so programs can be run with principles of least privilege, I know it's not perfect, but nothing ever is, but it should improve with time, if it's not neglected and replaced if needed. There is nothing wrong with the principle of least privilege. Experience, however, has shown that relying on different code having different permissions *in the same process* is not a good strategy. After twenty five years of Security Manager with little use and less still proper use, and with most of the ecosystem not supporting this mechanism anyway so even if improvement were justified it would take years until people could enjoy it, increasing investment in it would be, in my opinion, throwing good money after bad. > > It's a shame it took SecurityManager's proposed removal for you to discover it has practical application. You are right on one respect, not enough people take security seriously. Security and the Security Manager are not the same thing, virtually none of the security work in the JDK in the past few years took place in the Security Manager, and the fact that it could be put to good use is irrelevant. That?s been true for twenty five years, and it is an empirical fact that the *actual* benefit gained from it does not appear to justify the investment it requires. At this point, extolling the virtues of the Security Manager?s design misses the mark. We know it is a fine piece of engineering. But we are not researchers and not in the business of proving a point; we are in the business of putting whatever resources we have where they?d do the most good to our users. What matters is the benefit SM actually has in the real world. A relevant argument in favour of keeping it would look like an impressive list of organisations that rely on it and cannot switch to simpler alternatives. ? Ron From Alan.Bateman at oracle.com Thu May 6 11:48:14 2021 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 6 May 2021 12:48:14 +0100 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> Message-ID: On 06/05/2021 11:26, Peter Firmstone wrote: > > OpenJDK seems to have assumed that no one was using SecurityManager > based on one research report. > I don't think this is right. Instead I would say that many of us have rarely encountered deployments on the server-side that are using a SecurityManager to enforce security as envisaged by the Java security model. I've been at Java conferences where the sessions on this topic had less than 10 people in the room. Most of the actual usages that I've come across have been more like using the security manager as a convenient way to intercept network and file access for the purposes of logging or blocking. These usages may not have a need for protection domains, stack walks, policy files and the other complexity that comes with the security model. One thing that is missing from the discussions here is the cost and tax that supporting the SM "operating mode" brings. Many of the big features and all changes to security sensitive code must pay this tax. If there is a bug, a missing checkPermission for example, then it gets treated as security vulnerability at massive cost. Everything asynchronous brings more complexity and effort to figure out where the checks should be and whether an AccessControlContext needs to be carried around. I look forward to the day where we can be like other languages and runtimes that don't have to be concerned with this complexity and optional way of running. Finally, just to point out again that this JEP is about deprecating for removal in the future, it doesn't propose to remove the security manager now. If it moves forward then it will probably be several releases of degradation before it is removed. That gives time to properly consider the use cases where the security manager is useful today. Also if it is eventually removed, then anyone that really depends on this world can continue to use supported releases for years to come. -Alan From pconcannon at openjdk.java.net Thu May 6 11:52:15 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 11:52:15 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v3] In-Reply-To: References: Message-ID: > 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: Reverted parameter names; removed redundant parenthesis ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3687/files - new: https://git.openjdk.java.net/jdk/pull/3687/files/29308d6e..9e9f9fbd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=01-02 Stats: 33 lines in 8 files changed: 5 ins; 11 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/3687.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3687/head:pull/3687 PR: https://git.openjdk.java.net/jdk/pull/3687 From pconcannon at openjdk.java.net Thu May 6 11:52:16 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 11:52:16 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v3] In-Reply-To: References: Message-ID: <3UZ_6ZO2s7NM4sUZ8w8eEwaUFCdS1Ibp4bUkfR_cuzk=.b314aed4-beac-49da-806c-1104d6403c57@github.com> On Mon, 26 Apr 2021 18:14:21 GMT, Roger Riggs wrote: >> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265426: Reverted parameter names; removed redundant parenthesis > > src/java.base/share/classes/java/security/CodeSource.java line 174: > >> 172: // certs must match >> 173: return matchCerts(other, true); >> 174: } > > Can this (160-173) be collapsed to: > > return (obj instanceof CodeSource cs) && Objects.equals(location, other.location) && matchCerts(cs, true) Code refactored as suggested. See 9e9f9fb ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From pconcannon at openjdk.java.net Thu May 6 11:52:18 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 11:52:18 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v3] In-Reply-To: References: Message-ID: <55i5poVzMMu9K8Uk0UEY8-Lwcr0UO2KOiQo1-14QxC0=.95590be6-baa4-4ed7-a064-ef297c87ce84@github.com> On Mon, 26 Apr 2021 17:03:52 GMT, Jesper Steen M?ller wrote: >> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265426: Reverted parameter names; removed redundant parenthesis > > src/java.base/share/classes/java/security/Provider.java line 2003: > >> 2001: return true; >> 2002: } >> 2003: if (!(cap.supportsParameter)) { > > Why the extra parens? Parenthesis removed. See 9e9f9fb > src/java.base/share/classes/java/security/Provider.java line 2012: > >> 2010: ("Parameter must be instanceof Key for engine " + type); >> 2011: } >> 2012: if (!(hasKeyAttributes())) { > > Also here: Why the parens? Parenthesis removed. See 9e9f9fb ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From pconcannon at openjdk.java.net Thu May 6 11:56:51 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 11:56:51 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v3] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 23:24:41 GMT, Weijun Wang wrote: > Two comments: > > 1. Why not reuse the existing variable name (Ex: `t` in `Type t = (Type)obj`) as much as possible to avoid unnecessary renames? > > 2. I'm not sure if modifying argument name in a public API is a good idea. This leads to unnecessary javadoc changes. 1. I initially took the approach you suggested, but the general feedback from previous PRs (on similar work in other areas of `java.base`) has been to use more descriptive names for the pattern variables where possible. However, if you feel strongly about it please let me know which ones you would like me to change and we can discuss it further. 2. OK, I thought it might be an opportunity to add in some consistency for parameter names for the `equals()` methods. But, point taken. I've reverted these changes. Please see commit 9e9f9fb ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From abakhtin at openjdk.java.net Thu May 6 12:01:02 2021 From: abakhtin at openjdk.java.net (Alexey Bakhtin) Date: Thu, 6 May 2021 12:01:02 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v2] In-Reply-To: References: <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com> Message-ID: On Wed, 5 May 2021 03:41:27 GMT, Xue-Lei Andrew Fan wrote: >> Thank you for the update. >> >> I also expect the code easy to read and maintain in the future. But please go ahead for the integration if you don't want to make the update now. We could file an enhancement later on. > >> @XueleiFan , @jnimeh, thank you for your suggestions. I have updated synchronization using ReentrantLock in the Cache object. The performance test showed no issues. > > Thank you for considering use ReentrantLock, the "synchronized" keyword is something we are trying to avoid in the JSSE implementation. However, the reentrant lock introduced is not the lock in the Cache implementation. They are overlapped and could be conflict. The performance test looks good with just a few threads, but I'm not very sure of the through put impact if the threads goes up to 1M or more (there were complaints previously for large volume traffics). > > Maybe, you could keep it simple by adding a pull() method in the Cache class (find the session and remove it from the cache if found), by using the Cache class internal synchronize 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. 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. ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From org.openjdk at io7m.com Thu May 6 13:21:48 2021 From: org.openjdk at io7m.com (Mark Raynsford) Date: Thu, 6 May 2021 13:21:48 +0000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com> Message-ID: <20210506132148.3d28dfef@sunflower.int.arc7.info> On 2021-05-06T11:46:33 +0000 Ron Pressler wrote: > When the entire process has the same permissions ? in line with current practice ? there are > superior sandboxes provided by the OS. The issue with falling back to the sandboxes provided by the OS is that you then have to deal with a lot of platform-specific code in order to actually configure that sandbox. On some platforms, the application might have to run initially with a _higher_ level of privilege just in order to be able to switch to a lower level of privilege (consider setuid(), for example). Given that the JVM is conceptually supposed to be about not having to worry too much about what platform you're deploying on, having to do platform-specific work like this is always a bit unwelcome. It would be nice if there was a portable API where I could say something like "make me a new JVM with a subset of these modules, and with OS-specific limits and access control configured so that the child VM has this set of provided capabilities". The Chrome browser has rather a lot of code to handle this, including setting up seccomp policies on Linux platforms, (I believe) Capsicum policies on FreeBSD, and all kinds of things elsewhere. I may just be dreaming, but it'd be great if the successor to the security manager could give us a portable, system-independent API that could give us the desired sandbox setup on each underlying platform. :) -- Mark Raynsford | https://www.io7m.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: From weijun at openjdk.java.net Thu May 6 13:51:03 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 6 May 2021 13:51:03 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 11:52:15 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: Reverted parameter names; removed redundant parenthesis Approved. Just some tiny comments. The other suggestion from @Punikekk also looks fine. Thanks. src/java.base/share/classes/java/security/cert/CertPath.java line 185: > 183: > 184: return other instanceof CertPath that > 185: && this.type.equals(that.getType()) I know `type` should never be null but let's change as little as possible by using `that.getType().equals(this.type)`. src/java.base/share/classes/java/security/spec/EllipticCurve.java line 176: > 174: && (field.equals(other.field) > 175: && a.equals(other.a) > 176: && b.equals(other.b)); I suppose there's no need to put the last 3 checks between "(" and ")". ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3687 From rriggs at openjdk.java.net Thu May 6 13:59:53 2021 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 6 May 2021 13:59:53 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 11:52:15 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: Reverted parameter names; removed redundant parenthesis Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From mcimadamore at openjdk.java.net Thu May 6 14:23:27 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 6 May 2021 14:23:27 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v12] In-Reply-To: References: Message-ID: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/72eb9bbc..926229ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=10-11 Stats: 45 lines in 8 files changed: 0 ins; 0 del; 45 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 From pconcannon at openjdk.java.net Thu May 6 14:24:26 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 14:24:26 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v4] In-Reply-To: References: Message-ID: > 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8265426 - 8265426: Reverted parameter names; removed redundant parenthesis - Merge remote-tracking branch 'origin/master' into JDK-8265426 - 8265426: Update java.security to use instanceof pattern variable ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3687/files - new: https://git.openjdk.java.net/jdk/pull/3687/files/9e9f9fbd..bd433d6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=02-03 Stats: 349 lines in 21 files changed: 150 ins; 59 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/3687.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3687/head:pull/3687 PR: https://git.openjdk.java.net/jdk/pull/3687 From weijun at openjdk.java.net Thu May 6 14:25:13 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 6 May 2021 14:25:13 GMT Subject: RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" [v2] In-Reply-To: References: Message-ID: > `PKCS12KeyStore` always uses a 20-byte salt in encryption but PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt used for this algorithm will be 8 bytes. > > RFC 2898 only requires the salt to be at least 8 bytes, but I don't intend to modify the `PBES1Core.java` to accept a long salt. Otherwise, a newly generated PKCS #?12 file using a long salt will not be recognized by an old JDK. > > Also, although `PBES1Core.java` also take cares of another algorithm named PBEWithMD5AndDESede but it's not usable in a PKCS #?12 keystore as we have not defined its Object Identifier anywhere. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: better comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3822/files - new: https://git.openjdk.java.net/jdk/pull/3822/files/6726d0be..df1ab373 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3822&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3822&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3822.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3822/head:pull/3822 PR: https://git.openjdk.java.net/jdk/pull/3822 From weijun at openjdk.java.net Thu May 6 14:25:14 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 6 May 2021 14:25:14 GMT Subject: RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" [v2] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 01:23:40 GMT, Valerie Peng wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> better comment > > src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 811: > >> 809: byte[] salt = getSalt(); >> 810: if (KnownOIDs.findMatch(algorithm) == KnownOIDs.PBEWithMD5AndDES) { >> 811: // PBEWithMD5AndDES requires a 8-byte salt > > nit: maybe use "PBES1 scheme such as PBEWithMD5AndDES requires a 8-byte salt" Sure. Updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3822 From pconcannon at openjdk.java.net Thu May 6 14:42:20 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 14:42:20 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v5] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3687/files - new: https://git.openjdk.java.net/jdk/pull/3687/files/bd433d6d..cbf2841e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3687&range=03-04 Stats: 12 lines in 3 files changed: 0 ins; 7 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3687.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3687/head:pull/3687 PR: https://git.openjdk.java.net/jdk/pull/3687 From pconcannon at openjdk.java.net Thu May 6 14:42:21 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 14:42:21 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v5] In-Reply-To: References: Message-ID: <8rpU6iRiTP_ztRPztJ9-_BljfHQFmhIieZ1Bv7Ippk4=.71aa1bbd-1c89-4ce8-87eb-b05d2249fee4@github.com> On Tue, 27 Apr 2021 04:38:32 GMT, Punikekk wrote: >> 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 > > src/java.base/share/classes/java/security/Identity.java line 345: > >> 343: if (this.fullName().equals(other.fullName())) { >> 344: return true; >> 345: } else { > > Suggestion: Not really sure what you are suggesting here. Could you clarify? > src/java.base/share/classes/java/security/Identity.java line 349: > >> 347: } >> 348: } >> 349: return false; > > Suggestion: > > return obj instanceof Identity other > && (this.fullName().equals(other.fullName()) > || identityEquals(other)); Hi Punikekk, thanks for your comment. I've refactored as suggested. See cbf2841 ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From pconcannon at openjdk.java.net Thu May 6 14:42:23 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Thu, 6 May 2021 14:42:23 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v3] In-Reply-To: References: Message-ID: On Thu, 6 May 2021 13:41:04 GMT, Weijun Wang wrote: >> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision: >> >> 8265426: Reverted parameter names; removed redundant parenthesis > > src/java.base/share/classes/java/security/cert/CertPath.java line 185: > >> 183: >> 184: return other instanceof CertPath that >> 185: && this.type.equals(that.getType()) > > I know `type` should never be null but let's change as little as possible by using `that.getType().equals(this.type)`. Ordering swapped around. See cbf2841 > src/java.base/share/classes/java/security/spec/EllipticCurve.java line 176: > >> 174: && (field.equals(other.field) >> 175: && a.equals(other.a) >> 176: && b.equals(other.b)); > > I suppose there's no need to put the last 3 checks between "(" and ")". Parenthesis removed as suggested. See cbf2841 ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From dfuchs at openjdk.java.net Thu May 6 15:46:00 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 6 May 2021 15:46:00 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v5] In-Reply-To: References: Message-ID: 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 dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From hchao at openjdk.java.net Thu May 6 16:55:09 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 6 May 2021 16:55:09 GMT Subject: RFR: 8266225: jarsigner is using incorrect security property to show weakness of certs Message-ID: Please review the change to jarsigner so it uses certpath security property in order to properly display the weakness of the certificate algorithms. ------------- Commit messages: - 8266225:jarsigner is using incorrect security property to show weakness of certs Changes: https://git.openjdk.java.net/jdk/pull/3905/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3905&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266225 Stats: 39 lines in 2 files changed: 31 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3905.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3905/head:pull/3905 PR: https://git.openjdk.java.net/jdk/pull/3905 From valeriep at openjdk.java.net Thu May 6 17:55:52 2021 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 6 May 2021 17:55:52 GMT Subject: RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" [v2] In-Reply-To: References: Message-ID: <2wsLfNcwpe8bEJLwbp_KwgA4gB5542wUAE4vQgfcQcQ=.7a6f4452-e345-4376-a12d-995be2a77cfb@github.com> On Thu, 6 May 2021 14:25:13 GMT, Weijun Wang wrote: >> `PKCS12KeyStore` always uses a 20-byte salt in encryption but PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt used for this algorithm will be 8 bytes. >> >> RFC 2898 only requires the salt to be at least 8 bytes, but I don't intend to modify the `PBES1Core.java` to accept a long salt. Otherwise, a newly generated PKCS #?12 file using a long salt will not be recognized by an old JDK. >> >> Also, although `PBES1Core.java` also take cares of another algorithm named PBEWithMD5AndDESede but it's not usable in a PKCS #?12 keystore as we have not defined its Object Identifier anywhere. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > better comment Changes look good. ------------- Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3822 From weijun at openjdk.java.net Thu May 6 18:02:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 6 May 2021 18:02:53 GMT Subject: Integrated: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 17:35:46 GMT, Weijun Wang wrote: > `PKCS12KeyStore` always uses a 20-byte salt in encryption but PBEWithMD5AndDES only accepts 8-byte salt. With this code change, the salt used for this algorithm will be 8 bytes. > > RFC 2898 only requires the salt to be at least 8 bytes, but I don't intend to modify the `PBES1Core.java` to accept a long salt. Otherwise, a newly generated PKCS #?12 file using a long salt will not be recognized by an old JDK. > > Also, although `PBES1Core.java` also take cares of another algorithm named PBEWithMD5AndDESede but it's not usable in a PKCS #?12 keystore as we have not defined its Object Identifier anywhere. This pull request has now been integrated. Changeset: 04f71126 Author: Weijun Wang URL: https://git.openjdk.java.net/jdk/commit/04f71126479f9c39aa71e8aebe7196d72fc16796 Stats: 18 lines in 2 files changed: 15 ins; 0 del; 3 mod 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long" Reviewed-by: valeriep ------------- PR: https://git.openjdk.java.net/jdk/pull/3822 From weijun at openjdk.java.net Thu May 6 18:12:50 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 6 May 2021 18:12:50 GMT Subject: RFR: 8266225: jarsigner is using incorrect security property to show weakness of certs In-Reply-To: References: Message-ID: On Thu, 6 May 2021 16:49:33 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. test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java line 90: > 88: // key, but not for its SHA1withRSA algorithm. > 89: .shouldContain("Signature algorithm: SHA1withRSA, 1024-bit key (weak)") > 90: .shouldHaveExitValue(0); What does the test show before this fix? I don't see `Security.setProperty` called or a new `java.security` file is used. If `jdk.jar.dA` and `jdk.certpath.dA` are the same, then there's no way to find out if the new code works. ------------- PR: https://git.openjdk.java.net/jdk/pull/3905 From weijun at openjdk.java.net Thu May 6 18:16:53 2021 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 6 May 2021 18:16:53 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v5] In-Reply-To: References: Message-ID: 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 weijun (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3687 From xuelei at openjdk.java.net Thu May 6 19:17:53 2021 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 6 May 2021 19:17:53 GMT Subject: RFR: 8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93) [v2] In-Reply-To: References: <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com> Message-ID: On Thu, 6 May 2021 11:57:48 GMT, Alexey Bakhtin 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. For TLS 1.3, I think it may be safe to remove the session from the cache even if it is no rejoinable. ------------- PR: https://git.openjdk.java.net/jdk/pull/3664 From hchao at openjdk.java.net Thu May 6 20:57:13 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 6 May 2021 20:57:13 GMT Subject: RFR: 8266225: jarsigner is using incorrect security property to show weakness of certs [v2] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3905/files - new: https://git.openjdk.java.net/jdk/pull/3905/files/1d37f99e..533a7fed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3905&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3905&range=00-01 Stats: 27 lines in 1 file changed: 26 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3905.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3905/head:pull/3905 PR: https://git.openjdk.java.net/jdk/pull/3905 From hchao at openjdk.java.net Thu May 6 20:57:14 2021 From: hchao at openjdk.java.net (Hai-May Chao) Date: Thu, 6 May 2021 20:57:14 GMT Subject: RFR: 8266225: jarsigner is using incorrect security property to show weakness of certs [v2] In-Reply-To: References: Message-ID: <66ybcD8z_C04A9iHGprzCPPrQDRc_Vnmz43BVN8mt3A=.a51807e6-8514-4995-940c-9b1be711fce5@github.com> On Thu, 6 May 2021 18:08:40 GMT, Weijun Wang wrote: >> Hai-May Chao has updated the pull request incrementally with one additional commit since the last revision: >> >> Test with new java.security file > > test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java line 90: > >> 88: // key, but not for its SHA1withRSA algorithm. >> 89: .shouldContain("Signature algorithm: SHA1withRSA, 1024-bit key (weak)") >> 90: .shouldHaveExitValue(0); > > What does the test show before this fix? > > I don't see `Security.setProperty` called or a new `java.security` file is used. If `jdk.jar.dA` and `jdk.certpath.dA` are the same, then there's no way to find out if the new code works. Added test using new java.security with different disabledAlgorithms for certpath and jar. ------------- PR: https://git.openjdk.java.net/jdk/pull/3905 From peter.firmstone at zeus.net.au Fri May 7 00:25:04 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 7 May 2021 10:25:04 +1000 Subject: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> Message-ID: <5fffe2c3-99b7-c554-f52d-9925f053555c@zeus.net.au> Thanks Alan, I understand the motivation. The front line of security is authentication, privacy (encryption), verification and validation with failure atomicity. SecurityManager is unfortunately named, giving the impression that it has responsibility for security.? In truth, it's ONLY an access decision tool, rather than a controller or manager.?? It can have benefits for security, when employing the principle of least privilege, but it is not in and of itself a solution for system security, as you most rightly imply, it becomes an expensive game of whack-a-mole. I think the problem is one of perception. I would like to propose instead of deprecation, is that we simply document that security manager no longer performs it's original intended role, that it's role today is only to assist in access decisions.?? Lets remove the concept of a SecurityManager sandbox, let's put in big bold friendly letters, "THIS IS NOT A SANDBOX, NOR SHOULD IT BE RELIED UPON TO SECURE YOUR SYSTEM, IT IS ONLY SUITABLE FOR ASSISTING IN ACCESS DECISIONS FOR TRUSTED USERS AND CODE"?? And also explain why, ie the game of whack-a-mole.? Then a discussion of least privilege principles would be appropriate. In your examples below, where someone has forgotten to check a permission, or preserve context across threads, these are not exploitable until the front line of defense fails. Typically forgetting to preserve the context prevents a TLS connection from opening and it will be reported and fixed, but it is not a security risk, it just means you can't connect until it's fixed. Often the failure to check a permission is benign, because the code is trusted, but it does provide a way to manage who has access to data and to monitor it. Java Serialization shouldn't be used to process un-trusted data either, nor should it be used over an unencrypted connection, even with a whitelist, there is no guarantee of security, as it lacks validation failure atomicity. So how about we lower the bar for reporting, such that a bug in access control is treated differently than bugs that truly threaten security?? Lets make some rules around that so that when someone reports a bug, it's not escalated to a security bug if one of the front line defenses would prevent an untrusted party taking control of the jvm. Create a new bug category called ACCESS CONTROL BUGS, still fix holes in access control when reported, but don't escalate it to a level of security that no one can see, instead, publish the bug and let people submit patches.? This will reduce the maintenance burden and cost.?? We still want access control to function, but recognize its limitations. At work in your typical corporate environment, users are given access to directory's and files using Kerberos / RBAC and are typically disallowed from installing an application on their computer and have to call up the IT help desk to have software installed, this is because your average user will install anything onto their computer to get things done.? The average user isn't a hacker, that's going to hack your systems. Access control on Java should be treated similarly, I install this code, or authorize this user, on my JVM but I'm going to place some limitations on what they are allowed to do.? We are not expecting them to hack the system. I found the type of bug you are talking about myself only recently: https://github.com/pfirmstone/JGDMS/issues/125 Privileged methods and context are commonly used to establish TLS connections, so removing AccessControlContext and AccessController will break this code, when we already have the tools we need to establish TLS connections. Save the work of writing new tools to replace existing functionality, document the existing, change how we respond and devote the resources to something more important.?? That way our existing code should also remain functional, so it's win-win. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. On 6/05/2021 9:48 pm, Alan Bateman wrote: > On 06/05/2021 11:26, Peter Firmstone wrote: >> >> OpenJDK seems to have assumed that no one was using SecurityManager >> based on one research report. >> > I don't think this is right. Instead I would say that many of us have > rarely encountered deployments on the server-side that are using a > SecurityManager to enforce security as envisaged by the Java security > model. I've been at Java conferences where the sessions on this topic > had less than 10 people in the room. Most of the actual usages that > I've come across have been more like using the security manager as a > convenient way to intercept network and file access for the purposes > of logging or blocking. These usages may not have a need for > protection domains, stack walks, policy files and the other complexity > that comes with the security model. > > One thing that is missing from the discussions here is the cost and > tax that supporting the SM "operating mode" brings. Many of the big > features and all changes to security sensitive code must pay this tax. > If there is a bug, a missing checkPermission for example, then it gets > treated as security vulnerability at massive cost. Everything > asynchronous brings more complexity and effort to figure out where the > checks should be and whether an AccessControlContext needs to be > carried around. I look forward to the day where we can be like other > languages and runtimes that don't have to be concerned with this > complexity and optional way of running. > > Finally, just to point out again that this JEP is about deprecating > for removal in the future, it doesn't propose to remove the security > manager now. If it moves forward then it will probably be several > releases of degradation before it is removed. That gives time to > properly consider the use cases where the security manager is useful > today. Also if it is eventually removed, then anyone that really > depends on this world can continue to use supported releases for years > to come. > > -Alan From peter.firmstone at zeus.net.au Fri May 7 03:17:30 2021 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Fri, 7 May 2021 13:17:30 +1000 Subject: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries In-Reply-To: <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com> References: <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com> <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com> <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com> <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com> <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com> <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com> Message-ID: On 6/05/2021 9:46 pm, Ron Pressler wrote: > Most performance issues have to do with the stack walking at the core of the Security Manager?s design. I disagree, unless you can provide /evidence or context, I have not seen any evidence for this, I've done a lot of performance testing on the security infrastructure over the last 10 years. When SecurityManager is enabled, with the default policy provider, synchronization in PermissionCollection::implies checks are a huge scalability bottleneck. I have not seen any performance bottlenecks from stack walking in hot spots in my tests, unless you call 2% a hotspot.?? Although I do allow for hotspot to warm up to make optimisations.? Are you talking micro-benchmarks?? Prior to hotspot optimization? Do you have any performance tests results I can look at? >> It's a shame that SecurityManager is crippled on Loom's virtual threads, I was looking forward to using Loom for blocking network connections. Oh well, scratch that Idea, we wouldn't be able to make TLS connections with them. I was hoping Loom would reduce memory consumption, but then I haven't read enough about it. We consume a lot of threads, one of the thread factory's at least set the thread memory to a lower value than default to save memory. Is Loom is designed to run small rapidly completing non blocking tasks? > It is meant to run a great many concurrent tasks performing blocking operations (although they translate to non-blocking I/O once > they reach the OS). Obviously, many of those will be short-lived, as you?d be able to spawn a new thread just for the purpose of, > say, doing one HTTP client call. Ok, this does sound useful. >> This is far less complicated than people are making out, it's not atomic physics. Loom seems far more complicated than SecurityManager. Policy features are added using policy decorators. After you look through these implementations, you will see it's not that complex. > 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. We know that, for reasons good or bad, very few people opt to use it, and that most who do, do it > incorrectly. If, twenty five years from now, it turns out that Loom?s record is similar, I have little doubt that a similar > proposal would be raised then. That's not my concern, you made the argument it was impossible, that there were no working implementations, I think you concede now that isn't the case, therefore job done.? You have a vested interest in its removal, so you attempt to downplay the impact it will have on Java developers, I have a vested interest in reducing the maintenance burden I have too. My concern is software compatibility.?? The newly proposed API's only replaces existing functionality, and it does so in a way that is not backward compatible.? It offers no new features, it only lessens OpenJDK's maintenance burden, while causing a huge maintenance burden for downstream projects. The proposed changes not only impact those who use SecurityManager, but will also impact anyone that uses the current sign in mechanisms, and use the Subject for TLS connection authentication as well as Kerberos. Shotgun surgery and breakages go far beyond SecurityManager alone. Why not simply document it instead as I have suggested in my reply to Alan and treat the bugs differently to reduce maintenance cost? No new API's are needed then. > 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? > >> It is my opinion that removing the principle of least privilege will not improve the security of our software, but rather degrade it. But then Java hasn't had a good reputation for security in recent years, thanks to Serialization, granted OpenJDK has done a lot to swat bugs as they're discovered in recent years, it will take a little more time to build a good reputation. Personally I wouldn't be removing SecurityManager, I'd be addressing the issues and cleaning it up so programs can be run with principles of least privilege, I know it's not perfect, but nothing ever is, but it should improve with time, if it's not neglected and replaced if needed. > There is nothing wrong with the principle of least privilege. Experience, however, has shown that relying on different code > having different permissions *in the same process* is not a good strategy. After twenty five years of Security Manager with little > use and less still proper use, and with most of the ecosystem not supporting this mechanism anyway so even if improvement were justified > it would take years until people could enjoy it, increasing investment in it would be, in my opinion, throwing good money after bad. Experience with poor or incomplete implementations has shown that.? You have to admit then, that you have zero experience with a good implementation. It's just access control, you are mistakenly still thinking about sandboxes.?? In the sandbox model, the sandbox is the be all and end all of security, the sandbox is supposed to present a safe and impenetrable api, in the cheese model, access control is just one layer of cheese with holes.? Because nothing is perfect, it's better to have multiple layers of security, as it reduces the chances of things like gadget chains succeeding, rather than a be all and end all wack-a-mole whitelist approach that seems to be popular of late. https://securityandpeople.com/2017/07/human-errors-in-cyber-security-a-swiss-cheese-of-failures/ Anyone can use JGDMS to enjoy it now, little investment is required, the work is done.? It also takes the pain out of implementing TLS communications as well, including preserving the Subject across JVM's. https://github.com/pfirmstone/JGDMS It supports Maven and OSGi, so you can dynamically download libraries and automatically assign permissions.? Haven't implemented support for Java modules yet, as we still compile on Java 8, although funnily enough we use later TLSv1.3 cypher suites. Oh, that reminds me OSGi also implements SecurityManager and has dynamic permissions, it can revoke as well as grant permissions, are you aware of it?? It uses a different mechanism though, because it pre-dates Java 1.4, I don't recall the implementation. > >> It's a shame it took SecurityManager's proposed removal for you to discover it has practical application. You are right on one respect, not enough people take security seriously. > Security and the Security Manager are not the same thing, Agreed, but your statement is not relevant to the points I'm making here, you are still thinking about sandboxes, instead of access control.? Sandbox whitelists is wack-a-mole, so is white listed Serialization without atomic failure input validation. Maybe it's not that people don't take security seriously, it's that they think white lists are an appropriate form of security, without authentication and validation, they are not.? Same problem with the sandbox.? Access Control is still useful, when it's not treated as the front line of security, but a more rearward layer that is expected to have holes, because it has limitations, so we instead depend on a armory of defense layers, each with flaws, that we try to manage.? The Cyphers of the late 90's are no longer in use, and neither is the sandbox. > virtually none of the security work in the JDK in the past few years > took place in the Security Manager, Because Serialization is not failure atomic, is performed by privileged system code and developers had open network ports without authentication that an attacker could intercept and use gadget chains to take over the JVM, I don't see how this is relevant to access control for trusted code and trusted users. There were similar problems with XML.? This is why whitelists and whak-a-mole is not security either, also why I think whitelist serialization will come back to bite again, because people using whitelists think they can process data, without proper input validation.? What makes it works is it's a separate concern, it breaks object encapsulation. There should be a command line parameter to disable Serialization, in such a way that it cannot be enabled at runtime. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd. From pconcannon at openjdk.java.net Fri May 7 09:26:49 2021 From: pconcannon at openjdk.java.net (Patrick Concannon) Date: Fri, 7 May 2021 09:26:49 GMT Subject: RFR: 8265426: Update java.security to use instanceof pattern variable [v5] In-Reply-To: References: Message-ID: 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 From alanb at openjdk.java.net Fri May 7 10:07:56 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 7 May 2021 10:07:56 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v12] In-Reply-To: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> References: <8JEQ3a0tEdpDPGWsHEDFpvegIsnUtoGBQwIga55kVYY=.ac069eb8-fa51-4a13-8349-d655d19eab10@github.com> Message-ID: 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


From peter.firmstone at zeus.net.au  Fri May  7 10:17:10 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 7 May 2021 20:17:10 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
Message-ID: 


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.



From mcimadamore at openjdk.java.net  Fri May  7 11:18:21 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 7 May 2021 11:18:21 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v13]
In-Reply-To: 
References: 
Message-ID: 

> 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&pr=3699&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=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


From abakhtin at openjdk.java.net  Fri May  7 12:01:16 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 7 May 2021 12:01:16 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
In-Reply-To: 
References: 
Message-ID: 

> 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&pr=3664&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3664&range=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


From abakhtin at openjdk.java.net  Fri May  7 12:05:51 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Fri, 7 May 2021 12:05:51 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
In-Reply-To: 
References: 
 
 <-CLjtucMeRd8v3taBEHi3iZAZg-WcV4iJkuW4WxqSkU=.c5850ddb-1067-4298-99be-1d9a95e8544b@github.com>
 
 
 
 
Message-ID: 

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


From rriggs at openjdk.java.net  Fri May  7 12:58:54 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 7 May 2021 12:58:54 GMT
Subject: RFR: 8265426: Update java.security to use instanceof pattern
 variable [v5]
In-Reply-To: 
References: 
 
Message-ID: <31kEUTVTcAzweko9IkyVESlklBTPAytK0HP6PE8l7ec=.026a0a1c-4785-4512-8b59-f3cc3fb0d7c1@github.com>

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


From pconcannon at openjdk.java.net  Fri May  7 13:46:19 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 7 May 2021 13:46:19 GMT
Subject: Integrated: 8265426: Update java.security to use instanceof pattern
 variable
In-Reply-To: 
References: 
Message-ID: 

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


From coffeys at openjdk.java.net  Fri May  7 13:51:05 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Fri, 7 May 2021 13:51:05 GMT
Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v2]
In-Reply-To: 
References: 
Message-ID: 

> 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&pr=3544&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3544&range=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


From coffeys at openjdk.java.net  Fri May  7 13:52:15 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Fri, 7 May 2021 13:52:15 GMT
Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider
In-Reply-To: 
References: 
 
Message-ID: 

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


From weijun at openjdk.java.net  Fri May  7 14:13:09 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 7 May 2021 14:13:09 GMT
Subject: RFR: 8266225: jarsigner is using incorrect security property to
 show weakness of certs [v2]
In-Reply-To: 
References: 
 
Message-ID: 

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


From will.sargent at gmail.com  Fri May  7 14:53:49 2021
From: will.sargent at gmail.com (Will Sargent)
Date: Fri, 7 May 2021 07:53:49 -0700
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <3616-607a9b00-653-6086a60@136646411>
References: <20210416213735.535b26a8@sunflower.int.arc7.info>
 <3616-607a9b00-653-6086a60@136646411>
Message-ID: 

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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ron.pressler at oracle.com  Fri May  7 18:21:51 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 7 May 2021 18:21:51 +0000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
Message-ID: 

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.
> 


From peter.firmstone at zeus.net.au  Fri May  7 22:20:07 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 8 May 2021 08:20:07 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
Message-ID: <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>


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.



From ron.pressler at oracle.com  Fri May  7 22:42:50 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 7 May 2021 22:42:50 +0000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
Message-ID: 

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.
> 


From xuelei at openjdk.java.net  Sat May  8 00:26:29 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 8 May 2021 00:26:29 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
In-Reply-To: 
References: 
 
Message-ID: <6MlTuturpc_bO2reQnRDzApZyw8LmJfjpwiyPcX8APA=.d7bb2166-2db6-4b42-b41e-a38d76dceb90@github.com>

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


From peter.firmstone at zeus.net.au  Sat May  8 04:55:07 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 8 May 2021 14:55:07 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
Message-ID: 

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 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.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Sat May  8 05:11:47 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 8 May 2021 15:11:47 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
Message-ID: 


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From abakhtin at openjdk.java.net  Sat May  8 19:14:18 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Sat, 8 May 2021 19:14:18 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
In-Reply-To: <6MlTuturpc_bO2reQnRDzApZyw8LmJfjpwiyPcX8APA=.d7bb2166-2db6-4b42-b41e-a38d76dceb90@github.com>
References: 
 
 <6MlTuturpc_bO2reQnRDzApZyw8LmJfjpwiyPcX8APA=.d7bb2166-2db6-4b42-b41e-a38d76dceb90@github.com>
Message-ID: <1EaAy2ASlD6lH6lWbFSrxvh5sSIWEHGsJaaGc0NgZ0c=.12952cac-5f0d-49f5-a9f1-419a8e3c20dd@github.com>

On Sat, 8 May 2021 00:21:54 GMT, Xue-Lei Andrew Fan  wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add Cache.pull method
>
> 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.

Thank you, added comments as suggested.

> 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).

Thank you. Added braces but I'd like to keep non-null check.

> 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.

Thank you, added

> 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;
>           }

I'd like to keep my code as-is. We still need invalidate() if entry is not valid (see remove() operation).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3664


From abakhtin at openjdk.java.net  Sat May  8 19:14:16 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Sat, 8 May 2021 19:14:16 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v4]
In-Reply-To: 
References: 
Message-ID: 

> 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 comments and code cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3664/files
  - new: https://git.openjdk.java.net/jdk/pull/3664/files/73f7e8e8..4185ff6a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3664&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3664&range=02-03

  Stats: 6 lines in 3 files changed: 4 ins; 0 del; 2 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


From xuelei at openjdk.java.net  Sat May  8 19:52:10 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 8 May 2021 19:52:10 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
In-Reply-To: <1EaAy2ASlD6lH6lWbFSrxvh5sSIWEHGsJaaGc0NgZ0c=.12952cac-5f0d-49f5-a9f1-419a8e3c20dd@github.com>
References: 
 
 <6MlTuturpc_bO2reQnRDzApZyw8LmJfjpwiyPcX8APA=.d7bb2166-2db6-4b42-b41e-a38d76dceb90@github.com>
 <1EaAy2ASlD6lH6lWbFSrxvh5sSIWEHGsJaaGc0NgZ0c=.12952cac-5f0d-49f5-a9f1-419a8e3c20dd@github.com>
Message-ID: 

On Sat, 8 May 2021 19:10:50 GMT, Alexey Bakhtin  wrote:

>> 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;
>>           }
>
> I'd like to keep my code as-is. We still need invalidate() if entry is not valid (see remove() operation).

Did you notice that entry.isValid() implementation has already call invalidate() if the entry is not valid?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3664


From abakhtin at openjdk.java.net  Sat May  8 20:30:31 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Sat, 8 May 2021 20:30:31 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v5]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  Exclude duplicated operations in Cache.pull()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3664/files
  - new: https://git.openjdk.java.net/jdk/pull/3664/files/4185ff6a..3f31dc2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3664&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3664&range=03-04

  Stats: 7 lines in 1 file changed: 2 ins; 3 del; 2 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


From abakhtin at openjdk.java.net  Sat May  8 20:30:33 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Sat, 8 May 2021 20:30:33 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v3]
In-Reply-To: 
References: 
 
 <6MlTuturpc_bO2reQnRDzApZyw8LmJfjpwiyPcX8APA=.d7bb2166-2db6-4b42-b41e-a38d76dceb90@github.com>
 <1EaAy2ASlD6lH6lWbFSrxvh5sSIWEHGsJaaGc0NgZ0c=.12952cac-5f0d-49f5-a9f1-419a8e3c20dd@github.com>
 
Message-ID: 

On Sat, 8 May 2021 19:48:39 GMT, Xue-Lei Andrew Fan  wrote:

>> I'd like to keep my code as-is. We still need invalidate() if entry is not valid (see remove() operation).
>
> Did you notice that entry.isValid() implementation has already call invalidate() if the entry is not valid?

I didn't. You are right. Updated code as you suggested. Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3664


From peter.firmstone at zeus.net.au  Sat May  8 20:31:59 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 9 May 2021 06:31:59 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
Message-ID: <55ae48f1-3437-9b97-d7fa-6a140cc095da@zeus.net.au>

Ron,

Thanks for the discussion.? Although we have different opinions, I do 
appreciate that you took the time to reply.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.



From xuelei at openjdk.java.net  Sat May  8 20:54:06 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 8 May 2021 20:54:06 GMT
Subject: RFR: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93) [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Sat, 8 May 2021 20:30:31 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:
> 
>   Exclude duplicated operations in Cache.pull()

Looks good to me.  Thank you!

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3664


From peter.firmstone at zeus.net.au  Sun May  9 00:47:37 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 9 May 2021 10:47:37 +1000
Subject: JEP411: Restricting/logging library usages using a SecurityManager
In-Reply-To: 
References: 
Message-ID: <83456553-7f48-cf80-c640-1cbda3f01d3b@zeus.net.au>

Just some references regarding Roel's original argument below:

https://techbeacon.com/security/third-party-libraries-are-one-most-insecure-parts-application

https://debricked.com/blog/2021/01/02/vulnerabilities-in-dependencies/

https://www.tripwire.com/state-of-security/vulnerability-management/managing-security-risk-introduced-by-third-party-libraries/

https://www.infosecurity-magazine.com/opinions/third-party-libraries-the-swiss/

https://auth0.com/blog/third-party-assets-security-risks-management/

It will be interesting to see how OpenJDK plans to develop new ways to 
assist developers to mitigate third party library risks.

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.

On 16/04/2021 7:10 am, Roel Spilker wrote:
> Hi all,
>
> So I do get why RMI and Applets are no longer used.
>
> I also agree that the performance and usability of the current 
> implementation is suboptimal, and that configuring the security 
> manager through text files is also not that easy.
>
> But on my server application, we use libraries. And I'm very 
> interested on how they behave.
>
> I would?like to log or restrict the following actions:
> - Spawning new processes
> - Unexpected file access
> - Unexpected network traffic
>
> Currently, our application sets a custom written security?manager to 
> restrict or log those aspects.
>
> For example, we would block all XXE attacks by just having?our 
> security manager.
>
> In JEP411 I did not find a way to do those things without a security 
> manager.
>
> What does the security group think about these use cases? Does it 
> still make sense to deprecate/remove the entire security manager? 
> Would a replacement for certain concerns be in order?
>
> Kind regards,
>
> Roel Spilker



From abakhtin at openjdk.java.net  Mon May 10 09:48:16 2021
From: abakhtin at openjdk.java.net (Alexey Bakhtin)
Date: Mon, 10 May 2021 09:48:16 GMT
Subject: Integrated: 8241248: NullPointerException in
 sun.security.ssl.HKDF.extract(HKDF.java:93)
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Apr 2021 20:51:19 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

This pull request has now been integrated.

Changeset: 1603ca23
Author:    Alexey Bakhtin 
Committer: Vladimir Kempik 
URL:       https://git.openjdk.java.net/jdk/commit/1603ca23422b03157afb2bd1050524465474b60e
Stats:     45 lines in 4 files changed: 40 ins; 3 del; 2 mod

8241248: NullPointerException in sun.security.ssl.HKDF.extract(HKDF.java:93)

Reviewed-by: jnimeh, xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/3664


From jboes at openjdk.java.net  Mon May 10 11:04:04 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 10 May 2021 11:04:04 GMT
Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java
 makes not reliable time assumption [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 5 May 2021 10:08:15 GMT, Fernando Guallini  wrote:

>> test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame 
>> 
>> With this changeset, the server is checking whether the client thread has initiated handshake, and retrying if needed after waiting a short time. In addition, the test is now reusing SSLSocketTemplate to simplify sockets configuration and client/server synchronization
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   var volatile

@fguallini I'm happy to sponsor this change once it's been reviewed by someone from security.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3856


From sgehwolf at redhat.com  Mon May 10 14:12:45 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 10 May 2021 16:12:45 +0200
Subject: Ping? [8u] RFR: 8206925: Support the certificate_authorities
 extension
In-Reply-To: <3ee97cc85d184730ed4d59ebb18529852105beda.camel@redhat.com>
References: 
 <3ee97cc85d184730ed4d59ebb18529852105beda.camel@redhat.com>
Message-ID: 

Hi!

Would anyone be willing to review this?

Many thanks in advance!

Cheers,
Severin

On Thu, 2021-04-29 at 17:24 +0200, Severin Gehwolf wrote:
> Anyone?
> 
> On Tue, 2021-04-20 at 12:23 +0200, Severin Gehwolf wrote:
> > Hi,
> > 
> > Please review this OpenJDK 8u backport of the
> > certificate_authorities
> > extensionj. The OpenJDK 11u patch didn't apply cleanly after path
> > unshuffeling, but was fairly trivial to resolve. Conflicts caused
> > by:
> > 
> > 1. X509Authentication.java copyright line conflict only. Resolved
> > ?? manually.
> > 2. SSLContextTemplate.java private interface methods not allowed in
> > ?? JDK 8. It's a JDK 9+ feature via JEP 213. Changed modifier to
> > ?? default. Note: this is code used in tests only.
> > 3. TooManyCAs.java. Added -Djdk.tls.client.protocols=TLSv1.3 to the
> > ?? test invocations since JDK 8u doesn't enable TLSv1.3 on the
> > ?? client side by default. See JDK-8248721, CSR of the TLSv1.3 8u
> > ?? backport.
> > 
> > Other than that, the patch is identical to the OpenJDK 11.0.12
> > version
> > of this patch.
> > 
> > This introduces a new system property,
> > jdk.tls.client.enableCAExtension, for compatibilty reasons. CSR has
> > been reused from the Oracle JDK backport. See below.
> > 
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8206925
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8248709
> > webrev:
> > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206925/jdk8/02/webrev/
> > 
> > Testing: sun/security/ssl tests and tier1. No new regressions.
> > ???????? New tests pass.
> > 
> > Thoughts?
> > 
> > Thanks,
> > Severin
> 




From neugens at redhat.com  Mon May 10 14:39:23 2021
From: neugens at redhat.com (Mario Torre)
Date: Mon, 10 May 2021 16:39:23 +0200
Subject: Ping? [8u] RFR: 8206925: Support the certificate_authorities
 extension
In-Reply-To: 
References: 
 <3ee97cc85d184730ed4d59ebb18529852105beda.camel@redhat.com>
 
Message-ID: 

Hi Severin,

I went through the patch and it looks good to me.

Cheers,
Mario


On Mon, May 10, 2021 at 4:13 PM Severin Gehwolf  wrote:
>
> Hi!
>
> Would anyone be willing to review this?
>
> Many thanks in advance!
>
> Cheers,
> Severin
>
> On Thu, 2021-04-29 at 17:24 +0200, Severin Gehwolf wrote:
> > Anyone?
> >
> > On Tue, 2021-04-20 at 12:23 +0200, Severin Gehwolf wrote:
> > > Hi,
> > >
> > > Please review this OpenJDK 8u backport of the
> > > certificate_authorities
> > > extensionj. The OpenJDK 11u patch didn't apply cleanly after path
> > > unshuffeling, but was fairly trivial to resolve. Conflicts caused
> > > by:
> > >
> > > 1. X509Authentication.java copyright line conflict only. Resolved
> > >    manually.
> > > 2. SSLContextTemplate.java private interface methods not allowed in
> > >    JDK 8. It's a JDK 9+ feature via JEP 213. Changed modifier to
> > >    default. Note: this is code used in tests only.
> > > 3. TooManyCAs.java. Added -Djdk.tls.client.protocols=TLSv1.3 to the
> > >    test invocations since JDK 8u doesn't enable TLSv1.3 on the
> > >    client side by default. See JDK-8248721, CSR of the TLSv1.3 8u
> > >    backport.
> > >
> > > Other than that, the patch is identical to the OpenJDK 11.0.12
> > > version
> > > of this patch.
> > >
> > > This introduces a new system property,
> > > jdk.tls.client.enableCAExtension, for compatibilty reasons. CSR has
> > > been reused from the Oracle JDK backport. See below.
> > >
> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8206925
> > > CSR: https://bugs.openjdk.java.net/browse/JDK-8248709
> > > webrev:
> > > https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206925/jdk8/02/webrev/
> > >
> > > Testing: sun/security/ssl tests and tier1. No new regressions.
> > >          New tests pass.
> > >
> > > Thoughts?
> > >
> > > Thanks,
> > > Severin
> >
>
>


--
Mario Torre
Manager, Software Engineering
Red Hat GmbH 
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898



From rhalade at openjdk.java.net  Mon May 10 15:44:18 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 10 May 2021 15:44:18 GMT
Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java
 makes not reliable time assumption [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 5 May 2021 11:13:13 GMT, Daniel Fuchs  wrote:

>> Thanks, updated to be volatile.
>> 
>> SSLSocket::startHandshake internally first checks that the socket is not closed or broken and still connected, so it needs the server to close the socket after those verifications are performed to reproduce the test scenario, thus a CountDownLatch in the test before calling startHandshake would not guarantee that its internal operations are run before the server, already unblocked at that time, closes the socket
>> 
>> A CountDownLatch after startHandshake does not work either since the client keeps waiting for a server response, which is blocked waiting for the latch. That is why I think that looking at the thread stack is the best way to guarantee the scenario is properly verified
>
> OK

Can you please add this as a comment in a test file for clientThread variable? I am sure we will have (failed) try to convert it to CountDownLatch in future.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3856


From mcimadamore at openjdk.java.net  Mon May 10 17:45:24 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 17:45:24 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v14]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  Remove redundant checks for --enable-native-access

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/1ce6366a..3aaeb09f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=12-13

  Stats: 64 lines in 7 files changed: 0 ins; 63 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


From mcimadamore at openjdk.java.net  Mon May 10 18:15:01 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 18:15:01 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v15]
In-Reply-To: 
References: 
Message-ID: 

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:

 - Merge branch 'master' into JEP-412
 - Remove redundant checks for --enable-native-access
 - Fix issue in snippet in package-info
 - Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access
 - Fix message string in Reflection::ensureNativeAccess
 - Tweak comment in Module::enableNativeAccess
 - Tweak code some more
 - Use uniform naming convention for implementation metods in Module
 - Remove IllegalNativeAccessChecker
 - Remove redundant initializer in Module
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/bb4038eb...8de9da36

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/3aaeb09f..8de9da36

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=13-14

  Stats: 33173 lines in 668 files changed: 19837 ins; 7268 del; 6068 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


From mchung at openjdk.java.net  Mon May 10 19:20:27 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 10 May 2021 19:20:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v15]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 18:15:01 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:
> 
>  - Merge branch 'master' into JEP-412
>  - Remove redundant checks for --enable-native-access
>  - Fix issue in snippet in package-info
>  - Replace uses of -Djdk.foreign.restricted (useless now) with --enable-native-access
>  - Fix message string in Reflection::ensureNativeAccess
>  - Tweak comment in Module::enableNativeAccess
>  - Tweak code some more
>  - Use uniform naming convention for implementation metods in Module
>  - Remove IllegalNativeAccessChecker
>  - Remove redundant initializer in Module
>  - ... and 13 more: https://git.openjdk.java.net/jdk/compare/5a35ba03...8de9da36

The caller-sensitive cleanup change looks good.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 148:

> 146:      * @throws IllegalArgumentException in the case of a method type and function descriptor mismatch.
> 147:      * {@code --enable-native-access} is either absent, or does not mention the module name {@code M}, or
> 148:      * {@code ALL-UNNAMED} in case {@code M} is an unnamed module.

line 147-148 are leftover from ICE and they should be removed.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 209:

> 207:      * than the thread owning {@code scope}.
> 208:      * {@code --enable-native-access} is either absent, or does not mention the module name {@code M}, or
> 209:      * {@code ALL-UNNAMED} in case {@code M} is an unnamed module.

line 208-209 are also left-over from the last patch.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractCLinker.java line 44:

> 42:     @CallerSensitive
> 43:     public final MethodHandle downcallHandle(Addressable symbol, MethodType type, FunctionDescriptor function) {
> 44:         Reflection.ensureNativeAccess(Reflection.getCallerClass());

`downcallHandle` method is no longer caller-sensitive.  `@CallerSensitive` and `Reflection.ensureNativeAccess` are no longer needed.    Same for the 4-arg `downcallHandle` method.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/LibrariesHelper.java line 38:

> 36: import jdk.internal.loader.NativeLibrary;
> 37: import jdk.internal.reflect.CallerSensitive;
> 38: import jdk.internal.reflect.Reflection;

I think these 2 imports are no longer used.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/aarch64/AArch64Linker.java line 37:

> 35: import jdk.internal.foreign.abi.UpcallStubs;
> 36: import jdk.internal.reflect.CallerSensitive;
> 37: import jdk.internal.reflect.Reflection;

These 2 imports are no longer needed.  Same for other CLinker implementation classes.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3699


From mcimadamore at openjdk.java.net  Mon May 10 20:43:20 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 20:43:20 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  * Remove unused imports
  * Fix broken javadoc after removal of @throws clauses
  * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/8de9da36..6701654c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=14-15

  Stats: 24 lines in 7 files changed: 0 ins; 23 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


From mcimadamore at openjdk.java.net  Mon May 10 20:47:15 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 10 May 2021 20:47:15 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v3]
In-Reply-To: 
References: 
 
 
 
 
 
 
 
 
 
Message-ID: 

On Fri, 30 Apr 2021 17:20:21 GMT, Mandy Chung  wrote:

>>> I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration.
>> 
>> I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).
>> 
>> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?
>
>> I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module).
> 
> Thanks.
>  
>> Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing?
> 
> I create JDK-8266383 and I will look into that.

Thanks for the review @mlchung - hopefully looks better now!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From xuelei at openjdk.java.net  Tue May 11 04:30:22 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 11 May 2021 04:30:22 GMT
Subject: RFR: 8266881: Enable debug log for SSLEngineExplorerMatchedSNI.java
Message-ID: 

Hi,

May I have the following test code reviewed?

The test SSLEngineExplorerMatchedSNI.java fails intermittently.  I tried to run the test 500 times, but cannot reproduce the issue.  The cause is unknown to me now. It would could be helpful to fine the root cause to enable the JSSE debugging in the test.

Thanks & Regards,
Xuelei

-------------

Commit messages:
 - 8266881: Enable debug log for SSLEngineExplorerMatchedSNI.java

Changes: https://git.openjdk.java.net/jdk/pull/3967/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3967&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266881
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3967.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3967/head:pull/3967

PR: https://git.openjdk.java.net/jdk/pull/3967


From fguallini at openjdk.java.net  Tue May 11 13:58:28 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Tue, 11 May 2021 13:58:28 GMT
Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java
 makes not reliable time assumption [v3]
In-Reply-To: 
References: 
Message-ID: 

> test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame 
> 
> With this changeset, the server is checking whether the client thread has initiated handshake, and retrying if needed after waiting a short time. In addition, the test is now reusing SSLSocketTemplate to simplify sockets configuration and client/server synchronization

Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:

  added thread stack comment in test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3856/files
  - new: https://git.openjdk.java.net/jdk/pull/3856/files/300ac1ad..ea50ddeb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3856&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3856&range=01-02

  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3856/head:pull/3856

PR: https://git.openjdk.java.net/jdk/pull/3856


From fguallini at openjdk.java.net  Tue May 11 13:58:28 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Tue, 11 May 2021 13:58:28 GMT
Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java
 makes not reliable time assumption [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 10 May 2021 15:40:49 GMT, Rajan Halade  wrote:

>> OK
>
> Can you please add this as a comment in a test file for clientThread variable? I am sure we will have (failed) try to convert it to CountDownLatch in future.

@rhalade sure comment included

-------------

PR: https://git.openjdk.java.net/jdk/pull/3856


From mullan at openjdk.java.net  Tue May 11 18:26:55 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 11 May 2021 18:26:55 GMT
Subject: RFR: 8266225: jarsigner is using incorrect security property to
 show weakness of certs [v2]
In-Reply-To: 
References: 
 
Message-ID: 

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 mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3905


From hchao at openjdk.java.net  Tue May 11 19:37:18 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 11 May 2021 19:37:18 GMT
Subject: RFR: 8266225: jarsigner is using incorrect security property to
 show weakness of certs [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 7 May 2021 14:10:14 GMT, Weijun Wang  wrote:

>> 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).

@wangweij @seanjmullan Thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3905


From hchao at openjdk.java.net  Tue May 11 19:40:55 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 11 May 2021 19:40:55 GMT
Subject: Integrated: 8266225: jarsigner is using incorrect security property
 to show weakness of certs
In-Reply-To: 
References: 
Message-ID: 

On Thu, 6 May 2021 16:49:33 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.

This pull request has now been integrated.

Changeset: 995e9560
Author:    Hai-May Chao 
URL:       https://git.openjdk.java.net/jdk/commit/995e95603089f2571bb6778a2ff1691b147fd0ce
Stats:     65 lines in 2 files changed: 57 ins; 0 del; 8 mod

8266225: jarsigner is using incorrect security property to show weakness of certs

Reviewed-by: weijun, mullan

-------------

PR: https://git.openjdk.java.net/jdk/pull/3905


From hohensee at amazon.com  Tue May 11 22:00:24 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Tue, 11 May 2021 22:00:24 +0000
Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC
 algorithms
Message-ID: <27758308-C0F3-4D68-A5DE-03A1BA190CC4@amazon.com>

There?s an extra blank line inserted at the end of java.security. Otherwise lgtm.

I?m fine with using KnownOIDs.java from tip. One might object that now it?s in a different location and must be kept sync?ed with tip, but I don?t agree because the backported version must be updated only when a test that needs the update is backported, and if that?s needed it?ll be obvious what to do.

Thanks,
Paul

From: security-dev  on behalf of "Doerr, Martin" 
Date: Friday, April 30, 2021 at 9:35 AM
To: "jdk-updates-dev at openjdk.java.net" , security-dev 
Cc: "Langer, Christoph" 
Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms

Hi,

JDK-8153005 is backported to 11.0.12-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8153005

CSR covering 11u:
https://bugs.openjdk.java.net/browse/JDK-8228481

Original change:
https://github.com/openjdk/jdk/commit/f77a6585

11u rejected hunks:
http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/8153005_PKCS12_rej.txt

Resolution:
- Regular code is trivial to resolve, but the tests are tricky and the hunks were mostly integrated manually.
- Introduce test/lib/jdk/test/lib/KnownOIDs.java as copy from jdk head src/java.base/share/classes/sun/security/util/KnownOIDs.java with last change from Oct 2020. Put into package jdk.test.lib and using System.out as debug output stream. This should make future backports easier, too.
- DerUtils.java: ObjectIdentifier interface is diffent in 11u (different constructors).
- Hunks in GenerateAll.java were skipped because the affected code is not in 11u (JDK-8242068).

11u backport:
http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/webrev.00/

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Wed May 12 05:31:12 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 12 May 2021 15:31:12 +1000
Subject: Performance differences between Java 8,, 11, 14 and 16
Message-ID: <4c71cd5c-f4a3-c42d-cc12-9fcc64c175a0@zeus.net.au>

Just ran some performance stress tests to compare performance between 
Java 8 and Java 14 with SecurityManager enabled and using TLSv1.3 secure 
communications.

On Java 8, AccessController.getStackAccessControlContext[native]() is 
7,741ms of process CPU consumption.

On Java 11, AccessController.getStackAccessControlContext[native]() is 
7,769ms of process CPU consumption.

On Java 14, AccessController.getStackAccessControlContext[native]() is 
133,815 ms of process CPU consumption.

On Java 16, AccessController.getStackAccessControlContext[native]() is 
5,144 ms of process CPU consumption.

I wasn't expecting such a huge difference in performance.

Total time for the test on Java 8 is 97 seconds.

Total time for the test on Java 11 is 1 minute 37 seconds (same as Java 8)

Total time for the test on Java 14 is 2 minutes and 1 second.

Total time for the test on Java 16 is 1 minute and 36 seconds.

Both tests are using TLSv1.3 secure communications.

It would seem that Java 16, 8 and 11 are the performance winners in this 
case, where the above method is less than 0.5% of CPU. Java 14 is around 
15% of CPU.

Not sure why Java 14 is performing poorly in comparison to other 
versions, the results are pretty consistent to the second.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.



From xuelei.fan at oracle.com  Wed May 12 05:42:04 2021
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 12 May 2021 05:42:04 +0000
Subject: Performance differences between Java 8,, 11, 14 and 16
In-Reply-To: <4c71cd5c-f4a3-c42d-cc12-9fcc64c175a0@zeus.net.au>
References: <4c71cd5c-f4a3-c42d-cc12-9fcc64c175a0@zeus.net.au>
Message-ID: 

Hi Peter,

For further understanding, may I know more details about the test code?

Thanks,
Xuelei

> On May 11, 2021, at 10:31 PM, Peter Firmstone  wrote:
> 
> ?Just ran some performance stress tests to compare performance between Java 8 and Java 14 with SecurityManager enabled and using TLSv1.3 secure communications.
> 
> On Java 8, AccessController.getStackAccessControlContext[native]() is 7,741ms of process CPU consumption.
> 
> On Java 11, AccessController.getStackAccessControlContext[native]() is 7,769ms of process CPU consumption.
> 
> On Java 14, AccessController.getStackAccessControlContext[native]() is 133,815 ms of process CPU consumption.
> 
> On Java 16, AccessController.getStackAccessControlContext[native]() is 5,144 ms of process CPU consumption.
> 
> I wasn't expecting such a huge difference in performance.
> 
> Total time for the test on Java 8 is 97 seconds.
> 
> Total time for the test on Java 11 is 1 minute 37 seconds (same as Java 8)
> 
> Total time for the test on Java 14 is 2 minutes and 1 second.
> 
> Total time for the test on Java 16 is 1 minute and 36 seconds.
> 
> Both tests are using TLSv1.3 secure communications.
> 
> It would seem that Java 16, 8 and 11 are the performance winners in this case, where the above method is less than 0.5% of CPU. Java 14 is around 15% of CPU.
> 
> Not sure why Java 14 is performing poorly in comparison to other versions, the results are pretty consistent to the second.
> 
> -- 
> Regards,
> Peter Firmstone
> Zeus Project Services Pty Ltd.
> 

From peter.firmstone at zeus.net.au  Wed May 12 06:18:03 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 12 May 2021 16:18:03 +1000
Subject: Performance differences between Java 8,, 11, 14 and 16
In-Reply-To: 
References: <4c71cd5c-f4a3-c42d-cc12-9fcc64c175a0@zeus.net.au>
 
Message-ID: <46c118cd-959a-5d37-7e60-f0bbb13393e6@zeus.net.au>

?????, ???,

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.java

https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.td

With the follow property set to reproduce:

org.apache.river.test.impl.mahalo.RandomStressTest.seed=1620791630932

??

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.


On 12/05/2021 3:42 pm, Xuelei Fan wrote:
> Hi Peter,
>
> For further understanding, may I know more details about the test code?
>
> Thanks,
> Xuelei
>
>> On May 11, 2021, at 10:31 PM, Peter Firmstone  wrote:
>>
>> ?Just ran some performance stress tests to compare performance between Java 8 and Java 14 with SecurityManager enabled and using TLSv1.3 secure communications.
>>
>> On Java 8, AccessController.getStackAccessControlContext[native]() is 7,741ms of process CPU consumption.
>>
>> On Java 11, AccessController.getStackAccessControlContext[native]() is 7,769ms of process CPU consumption.
>>
>> On Java 14, AccessController.getStackAccessControlContext[native]() is 133,815 ms of process CPU consumption.
>>
>> On Java 16, AccessController.getStackAccessControlContext[native]() is 5,144 ms of process CPU consumption.
>>
>> I wasn't expecting such a huge difference in performance.
>>
>> Total time for the test on Java 8 is 97 seconds.
>>
>> Total time for the test on Java 11 is 1 minute 37 seconds (same as Java 8)
>>
>> Total time for the test on Java 14 is 2 minutes and 1 second.
>>
>> Total time for the test on Java 16 is 1 minute and 36 seconds.
>>
>> Both tests are using TLSv1.3 secure communications.
>>
>> It would seem that Java 16, 8 and 11 are the performance winners in this case, where the above method is less than 0.5% of CPU. Java 14 is around 15% of CPU.
>>
>> Not sure why Java 14 is performing poorly in comparison to other versions, the results are pretty consistent to the second.
>>
>> -- 
>> Regards,
>> Peter Firmstone
>> Zeus Project Services Pty Ltd.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Wed May 12 07:57:49 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 12 May 2021 17:57:49 +1000
Subject: Performance differences between Java 8,, 11, 14 and 16
In-Reply-To: <46c118cd-959a-5d37-7e60-f0bbb13393e6@zeus.net.au>
References: <4c71cd5c-f4a3-c42d-cc12-9fcc64c175a0@zeus.net.au>
 
 <46c118cd-959a-5d37-7e60-f0bbb13393e6@zeus.net.au>
Message-ID: <05c1d8bd-4562-e1f0-a226-b7988f6bd8c0@zeus.net.au>

Steps to reproduce:

Use git to checkout https://github.com/pfirmstone/JGDMS.git

Set the following path variables to your Java installation directory:

JAVA_HOME=file path to java 8

JDK_HOME=file path to jdk 8 (same as above)

Make sure the java command returns Java 8.

$java -version

Change directory into JGDMS

$mvn package

Change directory into qa: cd ../qa

Create a file called build.properties

Add the following 2 lines to build.properties (replace with your path):

river.home=C:/Users/peter/Documents/NetBeansProject/JGDMS
run.tests=org/apache/river/test/impl/mahalo/RandomStressTest.td

Then build the qa suite:

$ant build

Then edit the RandomStressTest.td file and add the following line (for 
repeatability)
org.apache.river.test.impl.mahalo.RandomStressTest.seed=1620791630932

Then change JAVA_HOME and JDK_HOME to your preferred version of java, 
and change your path to point to the java version you want to test.

Then run the test:

$ant run-tests

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.

On 12/05/2021 4:18 pm, Peter Firmstone wrote:
>
> ?????, ???,
>
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.java
>
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.td
>
> With the follow property set to reproduce:
>
> org.apache.river.test.impl.mahalo.RandomStressTest.seed=1620791630932
>
> ??
>
> -- 
> Regards,
>   
> Peter Firmstone
> Zeus Project Services Pty Ltd.
>
>
> On 12/05/2021 3:42 pm, Xuelei Fan wrote:
>> Hi Peter,
>>
>> For further understanding, may I know more details about the test code?
>>
>> Thanks,
>> Xuelei
>>
>>> On May 11, 2021, at 10:31 PM, Peter Firmstone  wrote:
>>>
>>> ?Just ran some performance stress tests to compare performance between Java 8 and Java 14 with SecurityManager enabled and using TLSv1.3 secure communications.
>>>
>>> On Java 8, AccessController.getStackAccessControlContext[native]() is 7,741ms of process CPU consumption.
>>>
>>> On Java 11, AccessController.getStackAccessControlContext[native]() is 7,769ms of process CPU consumption.
>>>
>>> On Java 14, AccessController.getStackAccessControlContext[native]() is 133,815 ms of process CPU consumption.
>>>
>>> On Java 16, AccessController.getStackAccessControlContext[native]() is 5,144 ms of process CPU consumption.
>>>
>>> I wasn't expecting such a huge difference in performance.
>>>
>>> Total time for the test on Java 8 is 97 seconds.
>>>
>>> Total time for the test on Java 11 is 1 minute 37 seconds (same as Java 8)
>>>
>>> Total time for the test on Java 14 is 2 minutes and 1 second.
>>>
>>> Total time for the test on Java 16 is 1 minute and 36 seconds.
>>>
>>> Both tests are using TLSv1.3 secure communications.
>>>
>>> It would seem that Java 16, 8 and 11 are the performance winners in this case, where the above method is less than 0.5% of CPU. Java 14 is around 15% of CPU.
>>>
>>> Not sure why Java 14 is performing poorly in comparison to other versions, the results are pretty consistent to the second.
>>>
>>> -- 
>>> Regards,
>>> Peter Firmstone
>>> Zeus Project Services Pty Ltd.
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Alan.Bateman at oracle.com  Wed May 12 08:00:41 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 12 May 2021 09:00:41 +0100
Subject: Performance differences between Java 8,, 11, 14 and 16
In-Reply-To: <46c118cd-959a-5d37-7e60-f0bbb13393e6@zeus.net.au>
References: <4c71cd5c-f4a3-c42d-cc12-9fcc64c175a0@zeus.net.au>
 
 <46c118cd-959a-5d37-7e60-f0bbb13393e6@zeus.net.au>
Message-ID: <1ec06519-b68d-d03b-e689-5aaabfcb3f8c@oracle.com>

On 12/05/2021 07:18, Peter Firmstone wrote:
>
>
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.java
>
> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.td
>
>
It would be great if there were a JMH benchmark that didn't have any 
dependency on Apache River or other libs. That would make it a bit 
easier to study/diagnose.

-Alan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Wed May 12 10:34:15 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Wed, 12 May 2021 20:34:15 +1000
Subject: Performance differences between Java 8,, 11, 14 and 16
In-Reply-To: <1ec06519-b68d-d03b-e689-5aaabfcb3f8c@oracle.com>
References: <4c71cd5c-f4a3-c42d-cc12-9fcc64c175a0@zeus.net.au>
 
 <46c118cd-959a-5d37-7e60-f0bbb13393e6@zeus.net.au>
 <1ec06519-b68d-d03b-e689-5aaabfcb3f8c@oracle.com>
Message-ID: <9c6ba9c9-0465-6e0b-d5cc-710027626b9b@zeus.net.au>

Hi Alan,

Understood, not sure if I could give AccessController that kind of 
workout using JDK classes alone, the library code is very performant.?? 
It might be possible if AllPermission is granted and ClassLoaders are 
created using only class bytes, without accessing files, to avoid using 
the Java's PolicyFile, URLClassLoader, CodeSource and URL.? To be honest 
though, it would be a reasonable size task, sorry, but I don't have 
enough time.

Mahalo is a network transaction manager service, in the test it runs 
through 1000 transactions, each with 1 to 9 network participants, each 
participant is a proxy with a unique ProtectionDomain and ClassLoader 
(represents Server identity in the client) that's making remote method 
calls over TLS connections.

By the time the test complete's it's created over 20,000 
ProtectionDomains and over 5,000 ClassLoader's, not all used at the same 
time of course, but there are a number of codebases involved, so there 
could be around 10 to 20 ProtectionDomain's in a call stack at the same 
time, these are being replaced, so it gives the AccessController quite a 
good workout.?? Note these ProtectionDomains run using the principle of 
least privilege.

Even TLSv1.3's overhead is un-noticable, it's basically only limited by 
the speed of the underlying network sockets.

Thank you to the developers who made TLSv1.3 run so well.

https://imgur.com/VcSwffC

https://imgur.com/VcSwffC

https://imgur.com/hmFPnAW

https://imgur.com/IcUXzNK

https://imgur.com/MutdNNt

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.

https://imgur.com/VcSwffC

https://imgur.com/VcSwffC

On 12/05/2021 6:00 pm, Alan Bateman wrote:
> On 12/05/2021 07:18, Peter Firmstone wrote:
>>
>>
>> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.java
>>
>> https://github.com/pfirmstone/JGDMS/blob/trunk/qa/src/org/apache/river/test/impl/mahalo/RandomStressTest.td
>>
>>
> It would be great if there were a JMH benchmark that didn't have any 
> dependency on Apache River or other libs. That would make it a bit 
> easier to study/diagnose.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Wed May 12 10:42:17 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 12 May 2021 10:42:17 +0000
Subject: AW: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC
 algorithms
In-Reply-To: <27758308-C0F3-4D68-A5DE-03A1BA190CC4@amazon.com>
References: <27758308-C0F3-4D68-A5DE-03A1BA190CC4@amazon.com>
Message-ID: 

Hi Paul,

thank you for the review!
I?ll remove the extra blank line before pushing.

Best regards,
Martin


Von: Hohensee, Paul 
Datum: Mittwoch, 12. Mai 2021 um 00:00
An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev 
Cc: Langer, Christoph 
Betreff: Re: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms
There?s an extra blank line inserted at the end of java.security. Otherwise lgtm.

I?m fine with using KnownOIDs.java from tip. One might object that now it?s in a different location and must be kept sync?ed with tip, but I don?t agree because the backported version must be updated only when a test that needs the update is backported, and if that?s needed it?ll be obvious what to do.

Thanks,
Paul

From: security-dev  on behalf of "Doerr, Martin" 
Date: Friday, April 30, 2021 at 9:35 AM
To: "jdk-updates-dev at openjdk.java.net" , security-dev 
Cc: "Langer, Christoph" 
Subject: [11u] RFR: 8153005: Upgrade the default PKCS12 encryption/MAC algorithms

Hi,

JDK-8153005 is backported to 11.0.12-oracle. I'd like to backport it for parity.
It doesn't apply cleanly.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8153005

CSR covering 11u:
https://bugs.openjdk.java.net/browse/JDK-8228481

Original change:
https://github.com/openjdk/jdk/commit/f77a6585

11u rejected hunks:
http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/8153005_PKCS12_rej.txt

Resolution:
- Regular code is trivial to resolve, but the tests are tricky and the hunks were mostly integrated manually.
- Introduce test/lib/jdk/test/lib/KnownOIDs.java as copy from jdk head src/java.base/share/classes/sun/security/util/KnownOIDs.java with last change from Oct 2020. Put into package jdk.test.lib and using System.out as debug output stream. This should make future backports easier, too.
- DerUtils.java: ObjectIdentifier interface is diffent in 11u (different constructors).
- Hunks in GenerateAll.java were skipped because the affected code is not in 11u (JDK-8242068).

11u backport:
http://cr.openjdk.java.net/~mdoerr/8153005_PKCS12_11u/webrev.00/

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vlivanov at openjdk.java.net  Wed May 12 14:08:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 14:08:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 20:43:20 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:
> 
>   * Remove unused imports
>   * Fix broken javadoc after removal of @throws clauses
>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

Overall, hotspot and java.lang.invoke changes look good.

One comment though on naming: there are multiple references to Panama in the code. Moreover, it is used inconsistently (`is_panama_entry_frame()` vs `EntryBlob` vs `OptimizedUpcallStub`). 
I suggest to get rid of any references to Panama and use `optimized`uniformly where appropriate (`is_optimized_entry_frame()`, `OptimizedEntryBlob`, `OptimizedUpcallStub`).

Some minor comments follow.

src/hotspot/share/prims/universalUpcallHandler.cpp line 122:

> 120: JNI_END
> 121: 
> 122: JVM_ENTRY(jlong, PUH_AllocateOptimzedUpcallStub(JNIEnv *env, jclass unused, jobject mh, jobject abi, jobject conv))

Typo: `PUH_AllocateOptimzedUpcallStub` -> `PUH_AllocateOptimizedUpcallStub`.

src/hotspot/share/prims/universalUpcallHandler.cpp line 137:

> 135: JVM_END
> 136: 
> 137: JVM_ENTRY(jboolean, PUH_SupportsOptimzedUpcalls(JNIEnv *env, jclass unused))

Typo: `Optimzed` -> `Optimized`

src/hotspot/share/runtime/sharedRuntime.hpp line 465:

> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
> 464: 
> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);

Please, file an RFE to move these declarations to `MacroAssembler`.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3699


From vlivanov at openjdk.java.net  Wed May 12 14:38:18 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 14:38:18 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 10 May 2021 20:43:20 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:
> 
>   * Remove unused imports
>   * Fix broken javadoc after removal of @throws clauses
>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`

src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:

> 470:   __ block_comment("} preserve_callee_saved_regs ");
> 471: 
> 472:   // TODO mxcsr

Anything left to do with mxcsr?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From jvernee at openjdk.java.net  Wed May 12 14:58:56 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 12 May 2021 14:58:56 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 14:06:46 GMT, Vladimir Ivanov  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Remove unused imports
>>   * Fix broken javadoc after removal of @throws clauses
>>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
>
> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
> 
>> 470:   __ block_comment("} preserve_callee_saved_regs ");
>> 471: 
>> 472:   // TODO mxcsr
> 
> Anything left to do with mxcsr?

I guess this slipped through with the initial PR.

JNI code loads the default value of mxcsr here and saves/restores the incoming native value: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L265-L298

However, it does nothing on Windows, while the Windows x64 ABI also defines mxcsr to have a non-volatile portion (i.e. that should be saved and restored): https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160#mxcsr

I think this made me a bit unsure about the need for saving and restoring mxcsr, and wanted to find an actual test case that causes a problem, rather than just copy-pasting the code (or at least understand it a bit better). But, at this time I haven't gotten to that yet.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From mcimadamore at openjdk.java.net  Wed May 12 15:11:51 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 12 May 2021 15:11:51 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 12 May 2021 13:57:21 GMT, Vladimir Ivanov  wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * Remove unused imports
>>   * Fix broken javadoc after removal of @throws clauses
>>   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
>
> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
> 
>> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
>> 464: 
>> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);
> 
> Please, file an RFE to move these declarations to `MacroAssembler`.

There's already an issue for that:
https://bugs.openjdk.java.net/browse/JDK-8266257

I've upgraded the description to make it reflect the proposed move a bit more precisely.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From rhalade at openjdk.java.net  Wed May 12 15:38:59 2021
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Wed, 12 May 2021 15:38:59 GMT
Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java
 makes not reliable time assumption [v3]
In-Reply-To: 
References: 
 
Message-ID: <9Vvs-zGm5IuMUZ7YlLqlNb5VGiuxrGsauy9PxoFqUGs=.3c5b7421-0231-4d16-8e3e-515122e05625@github.com>

On Tue, 11 May 2021 13:58:28 GMT, Fernando Guallini  wrote:

>> test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame 
>> 
>> With this changeset, the server is checking whether the client thread has initiated handshake, and retrying if needed after waiting a short time. In addition, the test is now reusing SSLSocketTemplate to simplify sockets configuration and client/server synchronization
>
> Fernando Guallini has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added thread stack comment in test

Marked as reviewed by rhalade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3856


From hchao at openjdk.java.net  Wed May 12 18:31:59 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 12 May 2021 18:31:59 GMT
Subject: RFR: 8266881: Enable debug log for
 SSLEngineExplorerMatchedSNI.java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 May 2021 04:22:49 GMT, Xue-Lei Andrew Fan  wrote:

> Hi,
> 
> May I have the following test code reviewed?
> 
> The test SSLEngineExplorerMatchedSNI.java fails intermittently.  I tried to run the test 500 times, but cannot reproduce the issue.  The cause is unknown to me now. It would could be helpful to fine the root cause to enable the JSSE debugging in the test.
> 
> Thanks & Regards,
> Xuelei

Marked as reviewed by hchao (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3967


From valeriep at openjdk.java.net  Wed May 12 18:55:13 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 May 2021 18:55:13 GMT
Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 May 2021 13:51:05 GMT, Sean Coffey  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
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Initial corrections from RFR

The update changes look good. Will wait for your test edit then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3544


From peter.tribble at gmail.com  Wed May 12 20:46:25 2021
From: peter.tribble at gmail.com (Peter Tribble)
Date: Wed, 12 May 2021 21:46:25 +0100
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
Message-ID: 

On Thu, May 6, 2021 at 12:48 PM Alan Bateman 
wrote:

> On 06/05/2021 11:26, Peter Firmstone wrote:
> >
> > OpenJDK seems to have assumed that no one was using SecurityManager
> > based on one research report.
> >
> I don't think this is right. Instead I would say that many of us have
> rarely encountered deployments on the server-side that are using a
> SecurityManager to enforce security as envisaged by the Java security
> model. I've been at Java conferences where the sessions on this topic
> had less than 10 people in the room. Most of the actual usages that I've
> come across have been more like using the security manager as a
> convenient way to intercept network and file access for the purposes of
> logging or blocking. These usages may not have a need for protection
> domains, stack walks, policy files and the other complexity that comes
> with the security model.
>

We're (partly, at least) in that group. We can't block the access from
outside
the JVM (and we are containerized with restricted permissions already)
because
some accesses are legitimate - something outside the JVM doesn't know when
the JVM is executing a particular piece of code, so we toggle the Security
Manager
on and off depending on context.

And here's the thing; there isn't really anything in the proposal that
addresses this
use case, or offers an alternate way forward.


> One thing that is missing from the discussions here is the cost and tax
> that supporting the SM "operating mode" brings. Many of the big features
> and all changes to security sensitive code must pay this tax. If there
> is a bug, a missing checkPermission for example, then it gets treated as
> security vulnerability at massive cost. Everything asynchronous brings
> more complexity and effort to figure out where the checks should be and
> whether an AccessControlContext needs to be carried around. I look
> forward to the day where we can be like other languages and runtimes
> that don't have to be concerned with this complexity and optional way of
> running.
>
> Finally, just to point out again that this JEP is about deprecating for
> removal in the future, it doesn't propose to remove the security manager
> now. If it moves forward then it will probably be several releases of
> degradation before it is removed. That gives time to properly consider
> the use cases where the security manager is useful today. Also if it is
> eventually removed, then anyone that really depends on this world can
> continue to use supported releases for years to come.
>

I appreciate that there will be older versions we can run; the issue is
always
that there may be some external driver why we have to update - either to
gain
a critical feature, or because something else doesn't support the old
version.

I know I would feel a lot happier with this proposal and its implications
if the
consideration of those use cases where the security manager is useful today
was more fully fleshed out.

Thanks,

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ron.pressler at oracle.com  Wed May 12 21:22:08 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 12 May 2021 21:22:08 +0000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
Message-ID: 



> On 12 May 2021, at 21:46, Peter Tribble  wrote:
> 
> We're (partly, at least) in that group. We can't block the access from outside
> the JVM (and we are containerized with restricted permissions already) because
> some accesses are legitimate - something outside the JVM doesn't know when
> the JVM is executing a particular piece of code, so we toggle the Security Manager
> on and off depending on context.
> 
> And here's the thing; there isn't really anything in the proposal that addresses this
> use case, or offers an alternate way forward.

Could you describe what your use-case is in the most precise way you can?

That there are useful applications of the Security Manager out there is certain; the same
was certainly also true for Applets. The problem is that the total good that the Security
Manager contributes does not justify the high cost of its maintenance. The more we can
understand what people use it for and how, the better we are able to judge how much we
should afford to put into some simpler replacement. Having said that, it is certainly 
possible that some of the millions of Java developers out there will be disappointed. We
try to direct our resources where they?d do the most good, and when we can, try to find
a solution for small groups that are harmed by such budgeting.

? Ron


From vlivanov at openjdk.java.net  Wed May 12 21:23:55 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 12 May 2021 21:23:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
 
Message-ID: <7uT8QeliCJCdi6fuk24JACjroSETna9Y9QxZXep8hMA=.5a392651-605e-48b9-b20f-09b2014d42da@github.com>

On Wed, 12 May 2021 14:53:39 GMT, Jorn Vernee  wrote:

>> src/hotspot/cpu/x86/universalUpcallHandler_x86_64.cpp line 472:
>> 
>>> 470:   __ block_comment("} preserve_callee_saved_regs ");
>>> 471: 
>>> 472:   // TODO mxcsr
>> 
>> Anything left to do with mxcsr?
>
> I guess this slipped through with the initial PR.
> 
> JNI code loads the default value of mxcsr here and saves/restores the incoming native value: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/stubGenerator_x86_64.cpp#L265-L298
> 
> However, it does nothing on Windows, while the Windows x64 ABI also defines mxcsr to have a non-volatile portion (i.e. that should be saved and restored): https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=msvc-160#mxcsr
> 
> I think this made me a bit unsure about the need for saving and restoring mxcsr, and wanted to find an actual test case that causes a problem, rather than just copy-pasting the code (or at least understand it a bit better). But, at this time I haven't gotten to that yet.

Thanks for the pointers. It would be safer for now to align the behavior with the call stub.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From peter.tribble at gmail.com  Wed May 12 21:41:37 2021
From: peter.tribble at gmail.com (Peter Tribble)
Date: Wed, 12 May 2021 22:41:37 +0100
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
Message-ID: 

On Wed, May 12, 2021 at 10:22 PM Ron Pressler 
wrote:

>
>
> > On 12 May 2021, at 21:46, Peter Tribble  wrote:
> >
> > We're (partly, at least) in that group. We can't block the access from
> outside
> > the JVM (and we are containerized with restricted permissions already)
> because
> > some accesses are legitimate - something outside the JVM doesn't know
> when
> > the JVM is executing a particular piece of code, so we toggle the
> Security Manager
> > on and off depending on context.
> >
> > And here's the thing; there isn't really anything in the proposal that
> addresses this
> > use case, or offers an alternate way forward.
>
> Could you describe what your use-case is in the most precise way you can?
>

Let me give a concrete example:

Parsing and rendering a PDF file that may contain references to fonts or
other resources.
We know exactly where the files are installed, so wish to allow the
rendering routine access
to the fonts it will need. But not to any other files, and not (normally)
to network resources at
all. Note that we trust the code, but not necessarily the document it's
parsing. (Although the
document itself may be perfectly well formed - document formats often allow
embedding
references to 3rd-party objects, undesirable as that may be.)

There are a range of such issues in document parsing and rendering. And
unfortunately, the
good libraries for this task are proprietary so we can't modify them to
apply the restrictions
we're after. The (server-side) application does need access to files and
network resources at
other times; it's only when it goes into the rendering step that we lock it
down, and unlock it
once done.


> That there are useful applications of the Security Manager out there is
> certain; the same
> was certainly also true for Applets. The problem is that the total good
> that the Security
> Manager contributes does not justify the high cost of its maintenance. The
> more we can
> understand what people use it for and how, the better we are able to judge
> how much we
> should afford to put into some simpler replacement. Having said that, it
> is certainly
> possible that some of the millions of Java developers out there will be
> disappointed. We
> try to direct our resources where they?d do the most good, and when we
> can, try to find
> a solution for small groups that are harmed by such budgeting.
>

I appreciate the reasoning here, and thanks for letting us try and describe
some our
use cases.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ron.pressler at oracle.com  Wed May 12 21:43:17 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 12 May 2021 21:43:17 +0000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
Message-ID: 



> On 8 May 2021, at 05:55, Peter Firmstone  wrote:
> 
> What would help in future:
> 
> 	? 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.
> 	? 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.
> 	? An annotation will let us know that we can write programs, without risk of incurring potentially significant technical debt.

OpenJDK does not have the concept of LTS, and certainly not of "LTS releases.? 
Long-term support is a general term for services that anyone is free to offer for any OpenJDK version for 
any length of time, and even retroactively. You can choose to provide LTS to JDK 10 tomorrow if you like.

OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its goal is to do exactly what 
you describe, and that policy is in effect for this JEP as it is for all other similar ones.

But please read JEP 411 carefully. It does give you time; it does talk of a gradual process.



> 	? 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.

This is the second time you?ve brought up Sun, as if it?s some disjoint group of people. People might 
have decided to change their policies due to changing circumstances, and the circumstances 15 years 
ago were certainly no identical to today.


> 
> 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.

We would like to see it removed because we believe that the total good the Security Manager does the 
Java community as a whole does not appear to justify its high cost. In other words, we?d like to see it 
removed because we believe doing so would do more good for more people than not removing it.

> 
> 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?

Removing stuff absolutely causes pain. We know that, we sympathise, and we?re trying to minimise it. 
But you have to understand that *not* removing stuff also causes pain, and not diverting resources 
elsewhere might dissuade other people from using Java because *their* needs aren?t addressed. We would 
have loved to please everyone but it?s impossible, so we have to make decisions, and whatever decision 
we make, someone will experience pain in the form of more work they have to do. We have to consider the 
total pain vs. total good over the entire Java ecosystem. Please also understand our perspective: you?re
asking us to pay for hours of work to maintain something that few use, hours that could go into work more
people could enjoy.

? Ron

From ron.pressler at oracle.com  Wed May 12 21:49:27 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 12 May 2021 21:49:27 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
Message-ID: <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>



> On 12 May 2021, at 22:41, Peter Tribble  wrote:
> 
> 
> Let me give a concrete example:
> 
> Parsing and rendering a PDF file that may contain references to fonts or other resources.
> We know exactly where the files are installed, so wish to allow the rendering routine access
> to the fonts it will need. But not to any other files, and not (normally) to network resources at
> all. Note that we trust the code, but not necessarily the document it's parsing. (Although the
> document itself may be perfectly well formed - document formats often allow embedding
> references to 3rd-party objects, undesirable as that may be.)
> 

Thank you. Let me ask you this, then:

1. Would allowing access to certain files and no network for the *entire* application be
sufficient? Consider that you can run some code in a separate Java process with OS protections.
If not, why not?

2. Would turning such access on and off for the entire application through some Java process
be sufficient?

3. Would controlling such access on a per-thread basis be sufficient?

Please don?t read 2 or 3 as some concrete proposals; I?m just trying to understand the requirements.

? Ron


From ron.pressler at oracle.com  Wed May 12 21:50:59 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 12 May 2021 21:50:59 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
Message-ID: 

P.S.

Sorry, I just realised I used the word ?process? in 1 and 2 with different meanings. In 1 I meant an 
OS process running Java; in 2 I merely meant a Java mechanism (as opposed to an OS mechanism).

> On 12 May 2021, at 22:49, Ron Pressler  wrote:
> 
> 
> 
>> On 12 May 2021, at 22:41, Peter Tribble  wrote:
>> 
>> 
>> Let me give a concrete example:
>> 
>> Parsing and rendering a PDF file that may contain references to fonts or other resources.
>> We know exactly where the files are installed, so wish to allow the rendering routine access
>> to the fonts it will need. But not to any other files, and not (normally) to network resources at
>> all. Note that we trust the code, but not necessarily the document it's parsing. (Although the
>> document itself may be perfectly well formed - document formats often allow embedding
>> references to 3rd-party objects, undesirable as that may be.)
>> 
> 
> Thank you. Let me ask you this, then:
> 
> 1. Would allowing access to certain files and no network for the *entire* application be
> sufficient? Consider that you can run some code in a separate Java process with OS protections.
> If not, why not?
> 
> 2. Would turning such access on and off for the entire application through some Java process
> be sufficient?
> 
> 3. Would controlling such access on a per-thread basis be sufficient?
> 
> Please don?t read 2 or 3 as some concrete proposals; I?m just trying to understand the requirements.
> 
> ? Ron
> 


From valeriep at openjdk.java.net  Wed May 12 21:58:13 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 12 May 2021 21:58:13 GMT
Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native
 implementation [v2]
In-Reply-To: 
References: 
Message-ID: 

> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos, e.g. funktion, lsit, functin.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3709/files
  - new: https://git.openjdk.java.net/jdk/pull/3709/files/a08ce8bd..285196b4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3709&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3709&range=00-01

  Stats: 26 lines in 1 file changed: 0 ins; 0 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3709/head:pull/3709

PR: https://git.openjdk.java.net/jdk/pull/3709


From peter.firmstone at zeus.net.au  Thu May 13 00:44:03 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 13 May 2021 10:44:03 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
 
Message-ID: 

Ron,

Can JEP 411 be targeted against Java 18 please?

I realize long term support is not OpenJDK's concern, however other's 
are planning Java 17 to be a long term support release and that will 
impact us.

Thank you,

Peter Firmstone
Zeus Project Services Pty Ltd.

On 13/05/2021 7:43 am, Ron Pressler wrote:
>
>> On 8 May 2021, at 05:55, Peter Firmstone  wrote:
>>
>> What would help in future:
>>
>> 	? 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.
>> 	? 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.
>> 	? An annotation will let us know that we can write programs, without risk of incurring potentially significant technical debt.
> OpenJDK does not have the concept of LTS, and certainly not of "LTS releases.?
> Long-term support is a general term for services that anyone is free to offer for any OpenJDK version for
> any length of time, and even retroactively. You can choose to provide LTS to JDK 10 tomorrow if you like.
>
> OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its goal is to do exactly what
> you describe, and that policy is in effect for this JEP as it is for all other similar ones.
>
> But please read JEP 411 carefully. It does give you time; it does talk of a gradual process.
>
>
>
>> 	? 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.
> This is the second time you?ve brought up Sun, as if it?s some disjoint group of people. People might
> have decided to change their policies due to changing circumstances, and the circumstances 15 years
> ago were certainly no identical to today.
>
>
>> 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.
> We would like to see it removed because we believe that the total good the Security Manager does the
> Java community as a whole does not appear to justify its high cost. In other words, we?d like to see it
> removed because we believe doing so would do more good for more people than not removing it.
>
>> 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?
> Removing stuff absolutely causes pain. We know that, we sympathise, and we?re trying to minimise it.
> But you have to understand that *not* removing stuff also causes pain, and not diverting resources
> elsewhere might dissuade other people from using Java because *their* needs aren?t addressed. We would
> have loved to please everyone but it?s impossible, so we have to make decisions, and whatever decision
> we make, someone will experience pain in the form of more work they have to do. We have to consider the
> total pain vs. total good over the entire Java ecosystem. Please also understand our perspective: you?re
> asking us to pay for hours of work to maintain something that few use, hours that could go into work more
> people could enjoy.
>
> ? Ron



From dblack at atlassian.com  Thu May 13 02:11:42 2021
From: dblack at atlassian.com (David Black)
Date: Thu, 13 May 2021 12:11:42 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
Message-ID: 

Hi,
I hope it is okay if I provide another
example/use case & view here.

On Thu, 13 May 2021 at 07:49, Ron Pressler  wrote:

>
>
> > On 12 May 2021, at 22:41, Peter Tribble  wrote:
> >
> >
> > Let me give a concrete example:
> >
> > Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> > We know exactly where the files are installed, so wish to allow the
> rendering routine access
> > to the fonts it will need. But not to any other files, and not
> (normally) to network resources at
> > all. Note that we trust the code, but not necessarily the document it's
> parsing. (Although the
> > document itself may be perfectly well formed - document formats often
> allow embedding
> > references to 3rd-party objects, undesirable as that may be.)
> >
>
> Thank you. Let me ask you this, then:
>
> 1. Would allowing access to certain files and no network for the *entire*
> application be
> sufficient? Consider that you can run some code in a separate Java process
> with OS protections.
> If not, why not?
>

It wouldn't be ideal but that is theoretically possible, but that will
likely come at a performance cost & require re-architecting applications.


>
> 2. Would turning such access on and off for the entire application through
> some Java process
> be sufficient?
>

No as this is similar to 1.


>
> 3. Would controlling such access on a per-thread basis be sufficient?
>
> Please don?t read 2 or 3 as some concrete proposals; I?m just trying to
> understand the requirements.
>
>
This seems somewhat more useful than 1 & 2 but imho it would be better to
be able to perform checks/grant access on a call stack basis. Atlassian
currently makes use of a security manager to prevent access to cloud
metadata services that do not have an amazon sdk related class on the call
stack. This helps to mitigate the impact of SSRF in applications running in
a cloud environment (
https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager
).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vlivanov at openjdk.java.net  Thu May 13 06:04:00 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 06:04:00 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v16]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Wed, 12 May 2021 15:07:37 GMT, Maurizio Cimadamore  wrote:

>> src/hotspot/share/runtime/sharedRuntime.hpp line 465:
>> 
>>> 463:   static void restore_native_result(MacroAssembler *_masm, BasicType ret_type, int frame_slots);
>>> 464: 
>>> 465:   static void   move32_64(MacroAssembler* masm, VMRegPair src, VMRegPair dst);
>> 
>> Please, file an RFE to move these declarations to `MacroAssembler`.
>
> There's already an issue for that:
> https://bugs.openjdk.java.net/browse/JDK-8266257
> 
> I've upgraded the description to make it reflect the proposed move a bit more precisely.

Got it. I was confused by the bug synopsis.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From peter.tribble at gmail.com  Thu May 13 07:25:25 2021
From: peter.tribble at gmail.com (Peter Tribble)
Date: Thu, 13 May 2021 08:25:25 +0100
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
Message-ID: 

On Wed, May 12, 2021 at 10:49 PM Ron Pressler 
wrote:

>
> > On 12 May 2021, at 22:41, Peter Tribble  wrote:
> >
> > Let me give a concrete example:
> >
> > Parsing and rendering a PDF file that may contain references to fonts or
> other resources.
> > We know exactly where the files are installed, so wish to allow the
> rendering routine access
> > to the fonts it will need. But not to any other files, and not
> (normally) to network resources at
> > all. Note that we trust the code, but not necessarily the document it's
> parsing. (Although the
> > document itself may be perfectly well formed - document formats often
> allow embedding
> > references to 3rd-party objects, undesirable as that may be.)
> >
>
> Thank you. Let me ask you this, then:
>
> 1. Would allowing access to certain files and no network for the *entire*
> application be
> sufficient? Consider that you can run some code in a separate Java process
> with OS protections.
> If not, why not?
>

Unfortunately not. We're already running this in a separate sandboxed Java
process to provide a
basic level of isolation. But that process has to interact with the outside
world - it has to get the
file in the first place, and put the result somewhere (which may be to a
filesystem or to a networked
system such as S3). Generally, the permitted level of access will vary
depending on where we are
in the rendering process.


> 2. Would turning such access on and off for the entire application through
> some Java process
> be sufficient?
>

That's effectively what we're doing right now. Essentially we do:

doRender() {
  installSecurityManager();
  do3rdPartyRender();
  uninstallSecurityManager();
}

which is fine because we are in a dedicated sandbox and can be sure that we
aren't doing anything else
at the time.


> 3. Would controlling such access on a per-thread basis be sufficient?
>

In a way, that would be more flexible, as we wouldn't need the
stop-the-world blanket restriction.
It does, however, rely on the assumption that once you've applied the
restriction to a thread then
the do3rdPartyRender() and anything it calls is also restricted to that
thread.

In our specific use case, because we have separate processes already, we
would probably aim for 2
rather than 3. But I can certainly see why 3 is attractive in general - it
allows you to tie a restriction to
a given execution context.


> Please don?t read 2 or 3 as some concrete proposals; I?m just trying to
> understand the requirements.
>
> ? Ron
>
>
Thanks,

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ron.pressler at oracle.com  Thu May 13 08:21:53 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Thu, 13 May 2021 08:21:53 +0000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
 
 
Message-ID: 

Whatever version JEP 411 targets, it will *not* remove the Security Manager. Even
if 411 targets 17, the Security Manager will still be in 17, precisely because
of the deprecation policy intended to give people time to adjust.

? Ron


> On 13 May 2021, at 01:44, Peter Firmstone  wrote:
> 
> Ron,
> 
> Can JEP 411 be targeted against Java 18 please?
> 
> I realize long term support is not OpenJDK's concern, however other's are planning Java 17 to be a long term support release and that will impact us.
> 
> Thank you,
> 
> Peter Firmstone
> Zeus Project Services Pty Ltd.
> 
> On 13/05/2021 7:43 am, Ron Pressler wrote:
>> 
>>> On 8 May 2021, at 05:55, Peter Firmstone  wrote:
>>> 
>>> What would help in future:
>>> 
>>> 	? 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.
>>> 	? 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.
>>> 	? An annotation will let us know that we can write programs, without risk of incurring potentially significant technical debt.
>> OpenJDK does not have the concept of LTS, and certainly not of "LTS releases.?
>> Long-term support is a general term for services that anyone is free to offer for any OpenJDK version for
>> any length of time, and even retroactively. You can choose to provide LTS to JDK 10 tomorrow if you like.
>> 
>> OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its goal is to do exactly what
>> you describe, and that policy is in effect for this JEP as it is for all other similar ones.
>> 
>> But please read JEP 411 carefully. It does give you time; it does talk of a gradual process.
>> 
>> 
>> 
>>> 	? 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.
>> This is the second time you?ve brought up Sun, as if it?s some disjoint group of people. People might
>> have decided to change their policies due to changing circumstances, and the circumstances 15 years
>> ago were certainly no identical to today.
>> 
>> 
>>> 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.
>> We would like to see it removed because we believe that the total good the Security Manager does the
>> Java community as a whole does not appear to justify its high cost. In other words, we?d like to see it
>> removed because we believe doing so would do more good for more people than not removing it.
>> 
>>> 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?
>> Removing stuff absolutely causes pain. We know that, we sympathise, and we?re trying to minimise it.
>> But you have to understand that *not* removing stuff also causes pain, and not diverting resources
>> elsewhere might dissuade other people from using Java because *their* needs aren?t addressed. We would
>> have loved to please everyone but it?s impossible, so we have to make decisions, and whatever decision
>> we make, someone will experience pain in the form of more work they have to do. We have to consider the
>> total pain vs. total good over the entire Java ecosystem. Please also understand our perspective: you?re
>> asking us to pay for hours of work to maintain something that few use, hours that could go into work more
>> people could enjoy.
>> 
>> ? Ron
> 


From mcimadamore at openjdk.java.net  Thu May 13 09:28:27 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 09:28:27 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v17]
In-Reply-To: 
References: 
Message-ID: <2Cgk9O0DjEwy44iJXmyVW_n_Q7mb0XABnlx_G8RYH0E=.f849d10a-2c74-48bc-b092-b43e37ae9574@github.com>

> 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:

  Address CSR comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/6701654c..03662920

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=15-16

  Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 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


From peter.firmstone at zeus.net.au  Thu May 13 09:32:54 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 13 May 2021 19:32:54 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
 
 
 
Message-ID: <0e8ff9a2-26d1-600e-3d33-5e721fe44bf5@zeus.net.au>

So it targets 17.

Java 8 has planned support to 2030, longer than 17, it seems unlikely 
the SecurityManager will still be present in an LTS release later than 
17, given that 11 was the last, maybe 23 will be the next LTS version.? 
Of course these aren't OpenJDK considerations, maybe someone will decide 
to support a version of Java that has it longer, or maybe they wont.

It would be nice to have certainty about which release it will be 
removed from, for planning purposes.?? Again it would seem that this 
isn't a consideration of OpenJDK.

Is there an OpenJDK community project group that maintains older Java 
versions I can join?

Regards,

Peter.


On 13/05/2021 6:21 pm, Ron Pressler wrote:
> Whatever version JEP 411 targets, it will *not* remove the Security Manager. Even
> if 411 targets 17, the Security Manager will still be in 17, precisely because
> of the deprecation policy intended to give people time to adjust.
>
> ? Ron
>
>
>> On 13 May 2021, at 01:44, Peter Firmstone  wrote:
>>
>> Ron,
>>
>> Can JEP 411 be targeted against Java 18 please?
>>
>> I realize long term support is not OpenJDK's concern, however other's are planning Java 17 to be a long term support release and that will impact us.
>>
>> Thank you,
>>
>> Peter Firmstone
>> Zeus Project Services Pty Ltd.
>>
>> On 13/05/2021 7:43 am, Ron Pressler wrote:
>>>> On 8 May 2021, at 05:55, Peter Firmstone  wrote:
>>>>
>>>> What would help in future:
>>>>
>>>> 	? 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.
>>>> 	? 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.
>>>> 	? An annotation will let us know that we can write programs, without risk of incurring potentially significant technical debt.
>>> OpenJDK does not have the concept of LTS, and certainly not of "LTS releases.?
>>> Long-term support is a general term for services that anyone is free to offer for any OpenJDK version for
>>> any length of time, and even retroactively. You can choose to provide LTS to JDK 10 tomorrow if you like.
>>>
>>> OpenJDK does have a removal policy: https://openjdk.java.net/jeps/277. Its goal is to do exactly what
>>> you describe, and that policy is in effect for this JEP as it is for all other similar ones.
>>>
>>> But please read JEP 411 carefully. It does give you time; it does talk of a gradual process.
>>>
>>>
>>>
>>>> 	? 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.
>>> This is the second time you?ve brought up Sun, as if it?s some disjoint group of people. People might
>>> have decided to change their policies due to changing circumstances, and the circumstances 15 years
>>> ago were certainly no identical to today.
>>>
>>>
>>>> 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.
>>> We would like to see it removed because we believe that the total good the Security Manager does the
>>> Java community as a whole does not appear to justify its high cost. In other words, we?d like to see it
>>> removed because we believe doing so would do more good for more people than not removing it.
>>>
>>>> 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?
>>> Removing stuff absolutely causes pain. We know that, we sympathise, and we?re trying to minimise it.
>>> But you have to understand that *not* removing stuff also causes pain, and not diverting resources
>>> elsewhere might dissuade other people from using Java because *their* needs aren?t addressed. We would
>>> have loved to please everyone but it?s impossible, so we have to make decisions, and whatever decision
>>> we make, someone will experience pain in the form of more work they have to do. We have to consider the
>>> total pain vs. total good over the entire Java ecosystem. Please also understand our perspective: you?re
>>> asking us to pay for hours of work to maintain something that few use, hours that could go into work more
>>> people could enjoy.
>>>
>>> ? Ron

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.



From fguallini at openjdk.java.net  Thu May 13 09:33:22 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Thu, 13 May 2021 09:33:22 GMT
Subject: RFR: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java
 makes not reliable time assumption [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 10 May 2021 11:00:34 GMT, Julia Boes  wrote:

> @fguallini I'm happy to sponsor this change once it's been reviewed by someone from security.
Thank you for sponsoring!. Rajan has reviewed the PR, it should be ready for integration.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3856


From ron.pressler at oracle.com  Thu May 13 10:00:28 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Thu, 13 May 2021 10:00:28 +0000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <0e8ff9a2-26d1-600e-3d33-5e721fe44bf5@zeus.net.au>
References: 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
 
 
 
 <0e8ff9a2-26d1-600e-3d33-5e721fe44bf5@zeus.net.au>
Message-ID: <6342F6FB-7A85-4276-91BB-648248415B6A@oracle.com>



> On 13 May 2021, at 10:32, Peter Firmstone  wrote:
> 
> So it targets 17.

I don?t know. I think that?s still TBD, but perhaps others know more.

> 
> It would be nice to have certainty about which release it will be removed from, for planning purposes.   Again it would seem that this isn't a consideration of OpenJDK.

It very much is, which is why we have the deprecation and removal policy. Please
read the JEP carefully. In addition to deprecation and removal, this JEP also proposes
an interim step of degradation prior to removal. Removal, as the JEP says, will only 
be done once it no longer poses a big compatibility threat. At the fastest pace possible
removal is more than a year away, though it will likely be longer than that.

> 
> Is there an OpenJDK community project group that maintains older Java versions I can join?
> 

Yes, that would be the Updates Project.

? Ron

From ron.pressler at oracle.com  Thu May 13 10:22:01 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Thu, 13 May 2021 10:22:01 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
Message-ID: <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>



> On 13 May 2021, at 03:11, David Black  wrote:
> 
> 
> This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.

This is an important point we?re trying to get across. The very reason the Security Manager was made this
way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
experience have shown us that *in practice* this is not the case, certainly not when you look at the 
ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
the job done, but actually use it incorrectly, providing the illusion of security without actual security.

> Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager).


We?re talking about a situation where *all* the classes running in your application are trusted,
i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
Can you explain why you believe this mechanism, that treats different classes differently is the best
way to improve security?

? Ron

From mcimadamore at openjdk.java.net  Thu May 13 10:24:57 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 10:24:57 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v18]
In-Reply-To: 
References: 
Message-ID: 

> 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 two additional commits since the last revision:

 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/03662920..3f99cccf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=16-17

  Stats: 45 lines in 15 files changed: 1 ins; 1 del; 43 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


From fguallini at openjdk.java.net  Thu May 13 10:52:55 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Thu, 13 May 2021 10:52:55 GMT
Subject: Integrated: 8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java
 makes not reliable time assumption
In-Reply-To: 
References: 
Message-ID: 

On Tue, 4 May 2021 15:12:39 GMT, Fernando Guallini  wrote:

> test sun/security/ssl/SSLSocketImpl/CloseSocket.java verifies the behavior when a server closes the socket connection during a handshake. The server was waiting a fixed 100ms before closing it, but there was no guarantee that the client started the handshake before or during that time frame 
> 
> With this changeset, the server is checking whether the client thread has initiated handshake, and retrying if needed after waiting a short time. In addition, the test is now reusing SSLSocketTemplate to simplify sockets configuration and client/server synchronization

This pull request has now been integrated.

Changeset: 347d41df
Author:    Fernando Guallini 
Committer: Julia Boes 
URL:       https://git.openjdk.java.net/jdk/commit/347d41df909f5762c5e066ab70d0fe7ea500ffaf
Stats:     114 lines in 1 file changed: 50 ins; 50 del; 14 mod

8164804: sun/security/ssl/SSLSocketImpl/CloseSocket.java makes not reliable time assumption

Reviewed-by: dfuchs, rhalade

-------------

PR: https://git.openjdk.java.net/jdk/pull/3856


From vlivanov at openjdk.java.net  Thu May 13 10:55:42 2021
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 13 May 2021 10:55:42 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v19]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 May 2021 10:52:35 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:
> 
>   Rename is_entry_blob to is_optimized_entry_blob
>   Rename as_entry_blob to as_optimized_entry_blob
>   Fix misc typos and indentation issues

Marked as reviewed by vlivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From mcimadamore at openjdk.java.net  Thu May 13 10:55:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 13 May 2021 10:55:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v19]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  Rename is_entry_blob to is_optimized_entry_blob
  Rename as_entry_blob to as_optimized_entry_blob
  Fix misc typos and indentation issues

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/3f99cccf..352c287f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=17-18

  Stats: 12 lines in 7 files changed: 0 ins; 0 del; 12 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


From sean.mullan at oracle.com  Thu May 13 12:59:02 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 13 May 2021 08:59:02 -0400
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <6342F6FB-7A85-4276-91BB-648248415B6A@oracle.com>
References: 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
 
 
 
 <0e8ff9a2-26d1-600e-3d33-5e721fe44bf5@zeus.net.au>
 <6342F6FB-7A85-4276-91BB-648248415B6A@oracle.com>
Message-ID: <892a4568-9902-5a5f-5069-a489767a7e9f@oracle.com>



On 5/13/21 6:00 AM, Ron Pressler wrote:
> 
> 
>> On 13 May 2021, at 10:32, Peter Firmstone  wrote:
>>
>> So it targets 17.
> 
> I don?t know. I think that?s still TBD, but perhaps others know more.

At this point, yes, we are planning to target the JEP to JDK 17.

>> It would be nice to have certainty about which release it will be removed from, for planning purposes.   Again it would seem that this isn't a consideration of OpenJDK.
> 
> It very much is, which is why we have the deprecation and removal policy. Please
> read the JEP carefully. In addition to deprecation and removal, this JEP also proposes
> an interim step of degradation prior to removal. Removal, as the JEP says, will only
> be done once it no longer poses a big compatibility threat. At the fastest pace possible
> removal is more than a year away, though it will likely be longer than that.

The JEP does have a section on this:

"In future JDK releases, we may degrade the Security Manager APIs so 
that they remain in place but have limited or no functionality. For 
example, we may revise AccessController::doPrivileged simply to run the 
given action, or revise System::getSecurityManager always to return 
null. This would allow libraries that support the Security Manager and 
were compiled against previous Java releases to continue to work without 
change or even recompilation. Once the compatibility risk has declined 
to an acceptable level, we expect to remove the APIs."

So, if the JEP is targeted to 17, then the Security Manager will be 
deprecated for removal but will still be fully functional and supported 
in 17.

*Disclaimer: The next part is forward thinking, and subject to change.*

Once we start degrading the APIs, the functionality of the Security 
Manager may not fully work as before, so in that sense you might 
consider it "removed". We don't yet have a definitive timeline for that, 
it may occur in the next release, or it may not, but it will probably 
occur within a few releases after the release it is targeted to.

--Sean

> 
>>
>> Is there an OpenJDK community project group that maintains older Java versions I can join?
>>
> 
> Yes, that would be the Updates Project.
> 
> ? Ron
> 


From ecki at zusammenkunft.net  Thu May 13 14:03:47 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 13 May 2021 14:03:47 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>,
 
Message-ID: 

Just to add another point to this. Today it is quite hard to use operating system facilities like chroot/jails, security tokens, seteuid, dropping priveledges or switching Security tokens which would allow to limit or escalate priveledges in an OS enforced manor. If we would have a bit more support of that, some sandbox mechanisms might actually be able to replace a security manager and/or open new features like processing workload with actual user accounts, etc.

I am however not sure what mechanism would be needed (and possible given the complete runtime) for that and how to make it able to support multiple OS with that. Maybe it would be an os specific optional facility? Something like SAPs shared memory with multiple processes maybe as an option for easy spawning of contained worklads?


--
http://bernd.eckenfels.net
________________________________
Von: security-dev  im Auftrag von Peter Tribble 
Gesendet: Thursday, May 13, 2021 9:25:25 AM
An: Ron Pressler 
Cc: Alan Bateman ; Peter Firmstone ; security-dev at openjdk.java.net 
Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On Wed, May 12, 2021 at 10:49 PM Ron Pressler > wrote:

> On 12 May 2021, at 22:41, Peter Tribble > wrote:
>
> Let me give a concrete example:
>
> Parsing and rendering a PDF file that may contain references to fonts or other resources.
> We know exactly where the files are installed, so wish to allow the rendering routine access
> to the fonts it will need. But not to any other files, and not (normally) to network resources at
> all. Note that we trust the code, but not necessarily the document it's parsing. (Although the
> document itself may be perfectly well formed - document formats often allow embedding
> references to 3rd-party objects, undesirable as that may be.)
>

Thank you. Let me ask you this, then:

1. Would allowing access to certain files and no network for the *entire* application be
sufficient? Consider that you can run some code in a separate Java process with OS protections.
If not, why not?

Unfortunately not. We're already running this in a separate sandboxed Java process to provide a
basic level of isolation. But that process has to interact with the outside world - it has to get the
file in the first place, and put the result somewhere (which may be to a filesystem or to a networked
system such as S3). Generally, the permitted level of access will vary depending on where we are
in the rendering process.

2. Would turning such access on and off for the entire application through some Java process
be sufficient?

That's effectively what we're doing right now. Essentially we do:

doRender() {
  installSecurityManager();
  do3rdPartyRender();
  uninstallSecurityManager();
}

which is fine because we are in a dedicated sandbox and can be sure that we aren't doing anything else
at the time.

3. Would controlling such access on a per-thread basis be sufficient?

In a way, that would be more flexible, as we wouldn't need the stop-the-world blanket restriction.
It does, however, rely on the assumption that once you've applied the restriction to a thread then
the do3rdPartyRender() and anything it calls is also restricted to that thread.

In our specific use case, because we have separate processes already, we would probably aim for 2
rather than 3. But I can certainly see why 3 is attractive in general - it allows you to tie a restriction to
a given execution context.

Please don?t read 2 or 3 as some concrete proposals; I?m just trying to understand the requirements.

? Ron


Thanks,

--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sean.mullan at oracle.com  Thu May 13 16:15:06 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 13 May 2021 12:15:06 -0400
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
Message-ID: <47e81190-506a-92c9-0e8a-359995d7978d@oracle.com>



On 5/12/21 5:41 PM, Peter Tribble wrote:
> Let me give a concrete example:
> 
> Parsing and rendering a PDF file that may contain references to fonts or 
> other resources.
> We know exactly where the files are installed, so wish to allow the 
> rendering routine access
> to the fonts it will need. But not to any other files, and not 
> (normally) to network resources at
> all. Note that we trust the code, but not necessarily the document it's 
> parsing. (Although the
> document itself may be perfectly well formed - document formats often 
> allow embedding
> references to 3rd-party objects, undesirable as that may be.)
> 
> There are a range of such issues in document parsing and rendering. And 
> unfortunately, the
> good libraries for this task are proprietary so we can't modify them to 
> apply the restrictions
> we're after. The (server-side) application does need access to files and 
> network resources at
> other times; it's only when it goes into the rendering step that we lock 
> it down, and unlock it
> once done.

I know very little about this area, but I would think a good PDF 
rendering library would include security features which prevent 
arbitrary file/network access from untrusted documents by default or at 
least give you the ability to control that.

--Sean


From valeriep at openjdk.java.net  Thu May 13 18:29:40 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 May 2021 18:29:40 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v6]
In-Reply-To: 
References: 
Message-ID: 

> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
> 
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
> 
> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Minor update to address review comments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2404/files
  - new: https://git.openjdk.java.net/jdk/pull/2404/files/eec0dab6..e4421a8d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=04-05

  Stats: 71 lines in 2 files changed: 48 ins; 1 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404

PR: https://git.openjdk.java.net/jdk/pull/2404


From mullan at openjdk.java.net  Thu May 13 18:48:58 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 13 May 2021 18:48:58 GMT
Subject: RFR: 8266881: Enable debug log for
 SSLEngineExplorerMatchedSNI.java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 May 2021 04:22:49 GMT, Xue-Lei Andrew Fan  wrote:

> Hi,
> 
> May I have the following test code reviewed?
> 
> The test SSLEngineExplorerMatchedSNI.java fails intermittently.  I tried to run the test 500 times, but cannot reproduce the issue.  The cause is unknown to me now. It would could be helpful to fine the root cause to enable the JSSE debugging in the test.
> 
> Thanks & Regards,
> Xuelei

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3967


From xuelei at openjdk.java.net  Thu May 13 18:56:53 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 13 May 2021 18:56:53 GMT
Subject: Integrated: 8266881: Enable debug log for
 SSLEngineExplorerMatchedSNI.java
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 May 2021 04:22:49 GMT, Xue-Lei Andrew Fan  wrote:

> Hi,
> 
> May I have the following test code reviewed?
> 
> The test SSLEngineExplorerMatchedSNI.java fails intermittently.  I tried to run the test 500 times, but cannot reproduce the issue.  The cause is unknown to me now. It would could be helpful to fine the root cause to enable the JSSE debugging in the test.
> 
> Thanks & Regards,
> Xuelei

This pull request has now been integrated.

Changeset: 26670245
Author:    Xue-Lei Andrew Fan 
URL:       https://git.openjdk.java.net/jdk/commit/266702451db57c4f006f22601288174cc0613339
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8266881: Enable debug log for SSLEngineExplorerMatchedSNI.java

Reviewed-by: hchao, mullan

-------------

PR: https://git.openjdk.java.net/jdk/pull/3967


From xuelei at openjdk.java.net  Thu May 13 21:20:12 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Thu, 13 May 2021 21:20:12 GMT
Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native
 implementation [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 May 2021 21:58:13 GMT, Valerie Peng  wrote:

>> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos, e.g. funktion, lsit, functin.

Looks good to me except a few trivial comments.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 193:

> 191:         register("CKR_TOKEN_RESOURCE_EXCEEDED", 0x00000201L);
> 192:         register("CKR_OPERATION_CANCEL_FAILED", 0x00000202L);
> 193:         register("CKR_VENDOR_DEFINED", 0x80000000L);

See below comment, I may have the hash map unmodifiable after the registration.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 197:

> 195: 
> 196:     private static void register(String name, long errorCode) {
> 197:         errorMap.put(errorCode, name);

I may check the put() return value and throw error for duplicated items, just in case duplicated copy-and-past register.

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 205:

> 203:         if (res == null) {
> 204:             res = "0x" + Functions.toFullHexString((int)errorCode);
> 205:             errorMap.put(errorCode, res);

It would be nice if the errorMap is immutable once the known error codes get registered.

-------------

Marked as reviewed by xuelei (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3709


From peter.firmstone at zeus.net.au  Thu May 13 23:36:09 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 14 May 2021 09:36:09 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <47e81190-506a-92c9-0e8a-359995d7978d@oracle.com>
References: 
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <47e81190-506a-92c9-0e8a-359995d7978d@oracle.com>
Message-ID: <8d5435a7-b10f-8e82-9f2f-9c94281c1f2f@zeus.net.au>

I also think good developers will add these security features.

The problem is that Permissions are currently used to regulate access 
control because this is how we've been told it should be done for over 
20 years.

Now maybe people aren't using the Java FilePolicy provider (for reasons 
stated previously), but as has been discovered, they often will override 
SecurityManager and implement some form of access control on trusted 3rd 
party code.

Trusted code - Developed by people with good intentions - includes third 
party library code, we check it for known vulnerabilities at build time 
using OWASP, but we don't audit it ourselves as this requires 
understanding how the internals work and we are using it like a black 
box.? If we have concerns we might perform static analysis, but we don't 
do that for dynamic code, eg maven dependencies and then we are 
powerless to do anything about it, other than report the bug, so access 
control can be used to mitigate until it's fixed, or we can use the 
principle of least privilege so we are not impacted by it.

Java Serialization is also a form of parsing information, just like PDF 
documents and other file formats, problems with the Sandbox; there was 
no Permission to limit which classes could be deserialized, and JVM code 
always has AllPermission, so we couldn't restrict it either.? 
Additionally there was no ProtectionDomain to represent the data being 
deserialized, and whether it was trusted or untrusted, these security 
features wouldn't have been difficult to add, however we rely on the 
platform developers to see the benefits.? We are all only human.

In JGDMS there are constraints we apply to services which require 
authentication and encryption, which must be met before deserialization 
or any downloads can proceed.

In our re-implementation of Atomic Java Serialization, we use a 
DeserizablePermission, to limit which libraries can perform 
de-serialization.?? This is in addition to the use of failure atomic 
constructors, so we don't break object encapsulation.

We also perform static analysis at build time and fix these bugs too.

SecurityManager has much influence in access decisions in our software, 
we won't have the resources to upgrade, there's a massive amount of 
security auditing required before we could even consider it.?? Our only 
option is to participate in the maintenance of existing Java versions.?? 
Java will be our COBOL. We will be capable of using Java 1.8 to 1.17, 
but not Java 2.0 (after disablement occurs).

Obviously removing SecurityManager infrastructure from OpenJDK is a 
significant undertaking requiring significant resources to audit the 
impacts of removal of Permission checks, unfortunately we don't have 
these resources and the alternative methods of putting alternative 
access controls in place isn't obvious and will require research, as you 
state below, I know very little about how this can be done without using 
existing Java access controls.

I think during this transition period, while developers are 
reestablishing what constitutes secure programming, there will be many 
new bugs exposed that SecurityManager was obscuring.

Personally, I will be observing from the sidelines to learn new security 
features and best practices I'm not yet aware of.? It's always best to 
wait and see the outcome of experiments before diving in.

The problem with Security is many developers don't like it, or want it 
to be someone else's problem, so we will always have reasons to remove 
whatever Security API's are added to Java because of limited use.

Perhaps I'm conflating security with access control again?

-- 
Regards,
  
Peter

On 14/05/2021 2:15 am, Sean Mullan wrote:
>
>
> On 5/12/21 5:41 PM, Peter Tribble wrote:
>> Let me give a concrete example:
>>
>> Parsing and rendering a PDF file that may contain references to fonts 
>> or other resources.
>> We know exactly where the files are installed, so wish to allow the 
>> rendering routine access
>> to the fonts it will need. But not to any other files, and not 
>> (normally) to network resources at
>> all. Note that we trust the code, but not necessarily the document 
>> it's parsing. (Although the
>> document itself may be perfectly well formed - document formats often 
>> allow embedding
>> references to 3rd-party objects, undesirable as that may be.)
>>
>> There are a range of such issues in document parsing and rendering. 
>> And unfortunately, the
>> good libraries for this task are proprietary so we can't modify them 
>> to apply the restrictions
>> we're after. The (server-side) application does need access to files 
>> and network resources at
>> other times; it's only when it goes into the rendering step that we 
>> lock it down, and unlock it
>> once done.
>
> I know very little about this area, but I would think a good PDF 
> rendering library would include security features which prevent 
> arbitrary file/network access from untrusted documents by default or 
> at least give you the ability to control that.
>
> --Sean



From valeriep at openjdk.java.net  Thu May 13 23:53:18 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Thu, 13 May 2021 23:53:18 GMT
Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native
 implementation [v3]
In-Reply-To: 
References: 
Message-ID: 

> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  PKCS11Exception class refactoring - use enum instead of HashMap

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3709/files
  - new: https://git.openjdk.java.net/jdk/pull/3709/files/285196b4..c08f62f7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3709&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3709&range=01-02

  Stats: 244 lines in 1 file changed: 117 ins; 102 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3709/head:pull/3709

PR: https://git.openjdk.java.net/jdk/pull/3709


From xuelei at openjdk.java.net  Fri May 14 00:17:37 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 14 May 2021 00:17:37 GMT
Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native
 implementation [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 13 May 2021 23:53:18 GMT, Valerie Peng  wrote:

>> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   PKCS11Exception class refactoring - use enum instead of HashMap

src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 212:

> 210:         long value() {
> 211:             return value;
> 212:         }

I guess it is safe to use the 'value' variable directly for enum.  The value() method may be not necessary.  Just a personal preference, ignore it if you like the current way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3709


From valeriep at openjdk.java.net  Fri May 14 00:33:12 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 14 May 2021 00:33:12 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: 
References: 
Message-ID: <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>

> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
> 
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
> 
> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge master into JDK-8248268
 - Minor update to address review comments.
 - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
   KWParameters and KWPParameters.
 - Refactor code to reduce code duplication
   Address review comments
   Add more test vectors
 - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
   AES/KWP/NoPadding
 - Restored Iv algorithm parameters impl.
 - 8248268: Support KWP in addition to KW
   
   Updated existing AESWrap support with AES/KW/NoPadding cipher
   transformation. Added support for AES/KWP/NoPadding and
   AES/KW/PKCS5Padding support to SunJCE provider.

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2404/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=06
  Stats: 2592 lines in 16 files changed: 1930 ins; 555 del; 107 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404

PR: https://git.openjdk.java.net/jdk/pull/2404


From svkamath at openjdk.java.net  Fri May 14 02:13:58 2021
From: svkamath at openjdk.java.net (Smita Kamath)
Date: Fri, 14 May 2021 02:13:58 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved implementation
 using AVX512 + VAES instructions
Message-ID: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>

I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
Performance gain of ~1.5x - 2x for message sizes 8k and above.

-------------

Commit messages:
 - Merge master
 - JDK-8267125: AES Galois CounterMode (GCM) interleaved implementation using AVX512 + VAES instructions

Changes: https://git.openjdk.java.net/jdk/pull/4019/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4019&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267125
  Stats: 1017 lines in 21 files changed: 983 ins; 11 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4019/head:pull/4019

PR: https://git.openjdk.java.net/jdk/pull/4019


From peter.firmstone at zeus.net.au  Fri May 14 07:49:14 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 14 May 2021 17:49:14 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <892a4568-9902-5a5f-5069-a489767a7e9f@oracle.com>
References: 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
 
 
 
 <0e8ff9a2-26d1-600e-3d33-5e721fe44bf5@zeus.net.au>
 <6342F6FB-7A85-4276-91BB-648248415B6A@oracle.com>
 <892a4568-9902-5a5f-5069-a489767a7e9f@oracle.com>
Message-ID: <307db1e3-022a-79cd-2813-b4e53962404a@zeus.net.au>

Thanks for confirming.

Cheers,

Peter.

On 13/05/2021 10:59 pm, Sean Mullan wrote:
>
>
> On 5/13/21 6:00 AM, Ron Pressler wrote:
>>
>>
>>> On 13 May 2021, at 10:32, Peter Firmstone 
>>>  wrote:
>>>
>>> So it targets 17.
>>
>> I don?t know. I think that?s still TBD, but perhaps others know more.
>
> At this point, yes, we are planning to target the JEP to JDK 17.
>
>>> It would be nice to have certainty about which release it will be 
>>> removed from, for planning purposes.?? Again it would seem that this 
>>> isn't a consideration of OpenJDK.
>>
>> It very much is, which is why we have the deprecation and removal 
>> policy. Please
>> read the JEP carefully. In addition to deprecation and removal, this 
>> JEP also proposes
>> an interim step of degradation prior to removal. Removal, as the JEP 
>> says, will only
>> be done once it no longer poses a big compatibility threat. At the 
>> fastest pace possible
>> removal is more than a year away, though it will likely be longer 
>> than that.
>
> The JEP does have a section on this:
>
> "In future JDK releases, we may degrade the Security Manager APIs so 
> that they remain in place but have limited or no functionality. For 
> example, we may revise AccessController::doPrivileged simply to run 
> the given action, or revise System::getSecurityManager always to 
> return null. This would allow libraries that support the Security 
> Manager and were compiled against previous Java releases to continue 
> to work without change or even recompilation. Once the compatibility 
> risk has declined to an acceptable level, we expect to remove the APIs."
>
> So, if the JEP is targeted to 17, then the Security Manager will be 
> deprecated for removal but will still be fully functional and 
> supported in 17.
>
> *Disclaimer: The next part is forward thinking, and subject to change.*
>
> Once we start degrading the APIs, the functionality of the Security 
> Manager may not fully work as before, so in that sense you might 
> consider it "removed". We don't yet have a definitive timeline for 
> that, it may occur in the next release, or it may not, but it will 
> probably occur within a few releases after the release it is targeted to.
>
> --Sean
>
>>
>>>
>>> Is there an OpenJDK community project group that maintains older 
>>> Java versions I can join?
>>>
>>
>> Yes, that would be the Updates Project.
>>
>> ? Ron
>>


From valeriep at openjdk.java.net  Fri May 14 19:46:20 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 14 May 2021 19:46:20 GMT
Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native
 implementation [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 14 May 2021 00:15:09 GMT, Xue-Lei Andrew Fan  wrote:

>> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PKCS11Exception class refactoring - use enum instead of HashMap
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 212:
> 
>> 210:         long value() {
>> 211:             return value;
>> 212:         }
> 
> I guess it is safe to use the 'value' variable directly for enum.  The value() method may be not necessary.  Just a personal preference, ignore it if you like the current way.

Sure, I like it too. Will update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3709


From valeriep at openjdk.java.net  Fri May 14 20:18:08 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 14 May 2021 20:18:08 GMT
Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native
 implementation [v4]
In-Reply-To: 
References: 
Message-ID: 

> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Use the final field "value" directly and remove value() method.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3709/files
  - new: https://git.openjdk.java.net/jdk/pull/3709/files/c08f62f7..057c3dfc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3709&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3709&range=02-03

  Stats: 19 lines in 1 file changed: 0 ins; 3 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3709.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3709/head:pull/3709

PR: https://git.openjdk.java.net/jdk/pull/3709


From xuelei at openjdk.java.net  Fri May 14 21:17:59 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 14 May 2021 21:17:59 GMT
Subject: RFR: JDK-6676643: Improve current C_GetAttributeValue native
 implementation [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: <8QdHX4O93odLZzSHGb7WMtNzHYMlGDp8psO41T2xF8s=.d02ed17f-8259-415d-9b8e-e7fa40b9c338@github.com>

On Fri, 14 May 2021 19:42:26 GMT, Valerie Peng  wrote:

>> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java line 212:
>> 
>>> 210:         long value() {
>>> 211:             return value;
>>> 212:         }
>> 
>> I guess it is safe to use the 'value' variable directly for enum.  The value() method may be not necessary.  Just a personal preference, ignore it if you like the current way.
>
> Sure, I like it too. Will update.

Thank you.  I have no more comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3709


From valeriep at openjdk.java.net  Fri May 14 23:07:58 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 14 May 2021 23:07:58 GMT
Subject: Integrated: JDK-6676643: Improve current C_GetAttributeValue native
 implementation
In-Reply-To: 
References: 
Message-ID: 

On Tue, 27 Apr 2021 02:41:12 GMT, Valerie Peng  wrote:

> Anyone can help review this somewhat trivial fix? The main change is inside src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_objmgmt.c. This is to help better troubleshooting by reporting the type of unavailable attributes in PKCS11 exception message when C_GetAttributeValue(...) call failed. The java file changes are just cleanup for consolidating the CKR_* constants definition into PKCS11Exception class.
> 
> Thanks,
> Valerie

This pull request has now been integrated.

Changeset: 7ab6dc83
Author:    Valerie Peng 
URL:       https://git.openjdk.java.net/jdk/commit/7ab6dc83df2e19a57ff0dcdc87598c54cd949a7c
Stats:     456 lines in 14 files changed: 68 ins; 198 del; 190 mod

6676643: Improve current C_GetAttributeValue native implementation

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/3709


From peter.firmstone at zeus.net.au  Fri May 14 23:57:45 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 15 May 2021 09:57:45 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <892a4568-9902-5a5f-5069-a489767a7e9f@oracle.com>
References: 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 <2B143A98-117B-4E7B-B640-250FF4D1B8E2@oracle.com>
 
 
 <280453a9-3e81-5a2b-00ca-d817f45533d4@zeus.net.au>
 
 
 
 
 
 <0e8ff9a2-26d1-600e-3d33-5e721fe44bf5@zeus.net.au>
 <6342F6FB-7A85-4276-91BB-648248415B6A@oracle.com>
 <892a4568-9902-5a5f-5069-a489767a7e9f@oracle.com>
Message-ID: 


On 13/05/2021 10:59 pm, Sean Mullan wrote:
>
> The JEP does have a section on this:
>
> "In future JDK releases, we may degrade the Security Manager APIs so 
> that they remain in place but have limited or no functionality. For 
> example, we may revise AccessController::doPrivileged simply to run 
> the given action, or revise System::getSecurityManager always to 
> return null. This would allow libraries that support the Security 
> Manager and were compiled against previous Java releases to continue 
> to work without change or even recompilation. Once the compatibility 
> risk has declined to an acceptable level, we expect to remove the APIs."
>
> So, if the JEP is targeted to 17, then the Security Manager will be 
> deprecated for removal but will still be fully functional and 
> supported in 17.
>
> *Disclaimer: The next part is forward thinking, and subject to change.*
>
> Once we start degrading the APIs, the functionality of the Security 
> Manager may not fully work as before, so in that sense you might 
> consider it "removed". We don't yet have a definitive timeline for 
> that, it may occur in the next release, or it may not, but it will 
> probably occur within a few releases after the release it is targeted to.
>
> --Sean
>
It will be important for existing JAAS login mechanisms and 
AccessControlContext's for Subject's are still functional and preserved 
so that TLS clients and servers can authenticate.?? The 
AccessControlContext would only need to contain an array with only one 
ProtectionDomain, containing the Subject.


-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.



From peter.firmstone at zeus.net.au  Sat May 15 12:01:47 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 15 May 2021 22:01:47 +1000
Subject: JEP 411: Why the last version to support SecurityManager is likely to
 be the most powerful version of Java.
Message-ID: <55db6868-fe28-d460-206b-28dc866d312b@zeus.net.au>

A disclaimer: I accept SecurityManager will be removed, but I feel a few 
words are in order before it's passing.

A little history:

> Pre-1994, Bill Joy presented a proposal to Sun Labs where he
> presented three main concepts:
> 1) a language that would run on all platforms,
> 2) a virtual machine to run this language, and
> 3) a networked system to allow the distributed virtual machines
> to work as a singular system.
> In 1995, the language and virtual machine were introduced to
> the market as the Java Programming language and Java Virtual
> Machine. The system context, however, was kept in the Sun R&D
> for continued research and development. This system context
> is Jini.
Reference: http://di002.edv.uniovi.es/~falvarez/whatisjini.pdf

This fit into Sun's vision: "The network is the computer."

The components of item 3 above, have presented significant technical 
challenges, progress having been made at various times during Java's 
history.? Only in recent years have all the pieces of the puzzle come to 
together to realize the original goal.

So it appears that Java 1.17 will remain an important version for many 
years to come.

There are two types of scalability, vertical and horizontal.

Various OS platforms that support different CPU and GPU architectures, 
clearly the vector API is an important component as are other recent 
improvements.

IPv6 enables end to end connectivity, rather than IPv4's publish 
subscribe, server client model and issues with NAT.? Web services are 
based on the publish subscribe model, with message passing. The Web 
services push API gives web applications the ability to listen to 
events. https://developer.mozilla.org/en-US/docs/Web/API/Push_API?? But 
there remain issues with cross site request forgery's.

The glue is important too (which is what Jini is).

What are the key components:

 1. JVM's installed on each node.
 2. Dynamic class loading, with verification and type safety.
 3. Network end to end connectivity (IPv6 adoption is currently 32%)
 4. Privacy, Authentication and Identity.
 5. Object Serialization protocols (Java Serialization is flawed).
 6. Jini Extensible Remote Invocation (RMI isn't suitable due to class
    resolution issues and limited extensibility).
 7. Service architecture based on Interfaces.
 8. Dynamic network discovery (IPv6 global discovery only recently added
    https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml).
 9. Ability to "join" specific groups on the network.
10. Lookup services (multiple, it's a common misconception there is only
    one), to find services, as well as listeners to be notified when
    services are added, removed or changed.
11. Network Transaction Service.
12. A powerful Configuration, that uses Groovy.

Why wasn't Jini a huge success when it was released in 1998?

 1. It had some initial success, but class resolution was a big problem
    http://sorcersoft.org/resources/jini/smli_tr-2006-149.pdf as
    ClassLoader's added complexity that wasn't originally envisioned.?
    To solve this problem, instead of using RMIClassLoading for class
    resolution and visibility, ClassLoader's? are assigned at each
    Endpoint and are completely responsible for class visibility and
    resolution, so it works with non-hierarchical class loading systems
    like OSGi.
 2. Security wasn't added until 2002, combined with IPv4, it relegated
    Jini to private trusted networks, in the age of the internet,
    limiting it's appeal.? This is no longer the case.
 3. When Security was added, it had been assumed the Java Sandbox and
    Java Serialization were secure, so authentication of services was
    performed after class loading and de-serialization, ouch!
 4. The security model, added unnecessary complexity in the form of
    ProxyTrust? (This isn't used today).? We just authenticate first
    now, ensure the connection is private and validate the code, then
    let the code validate the input, to fail atomically, and this is
    handled for the user, all the user need do is configure their
    services to use TLS, and ensure their services runs with the login
    Subject.
 5. Objects were exported remotely via their constructors allowing
    "this" to escape, prior to the Java 1.5 JMM, this was changed, an
    interface called Startable allows services to be started after
    construction, the same thing happens with Activation (Phoenix, not
    RMI), which is basically a watchdog for services.

Sun later released Jini as open source under the Apache 2.0 license in 
2007 and donated it to Apache who renamed it to River.

Remaining issues have taken about 12 years to resolve, all up it's 
probably had 25 years of development.

http://nighthacks.com/jag/res/Fallacies.html

https://github.com/pfirmstone/JGDMS

If JAAS continues to function in later versions of Java, we will be able 
to support them as server side services, but not as clients, without 
SecurityManager, so it will always depend on the last version of Java 
that contains a fully functional SecurityManager.? Otherwise we fail the 
6th Fallacy of distributed computing.

Still have a couple of things left to do, such as support pack200 for 
smaller proxy code download sizes and update it to support Java 1.17 
bytecode as well as other support other object serialization protocols 
using the atomic Serialization API, it will be a configuration concern.

The original vision, it was visionary, but now it works, well it's more 
than that, it works really well.

-- 
Regards,
  
Peter.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dblack at atlassian.com  Mon May 17 02:11:26 2021
From: dblack at atlassian.com (David Black)
Date: Mon, 17 May 2021 12:11:26 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
Message-ID: 

Hi Ron

On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
>
>
>
> > On 13 May 2021, at 03:11, David Black  wrote:
> >
> >
> > This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
>
> This is an important point we?re trying to get across. The very reason the Security Manager was made this
> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
> experience have shown us that *in practice* this is not the case, certainly not when you look at the
> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
> the job done, but actually use it incorrectly, providing the illusion of security without actual security.

Agreed, but if you don't have this level of introspection/detail how
do you propose to, at least partially, mitigating bug classes such as
SSRF?

> > Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager).
>
>
> We?re talking about a situation where *all* the classes running in your application are trusted,
> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
> Can you explain why you believe this mechanism, that treats different classes differently is the best
> way to improve security?

Because it allows for restrictions to be placed upon "trusted"[0]
classes so as to offer some mitigation against classes of bugs such as
SSRF. You can also use a security manager to monitor for potential
policy implementation issues & make adjustments. Specifically for
SSRF, if you want to mitigate the issue you need to ensure that
network connections being made respect proxy settings but also allow
support for certain code paths bypassing proxy settings to access
potentially sensitive network locations (e.g. cloud metadata
resources) this can result in mistakes in configuration occurring and
or finding libraries/classes that ignore proxy configuration. You may
be thinking "oh but surely no library/class would have proxy
problems?" well that answer is "yes they can and do". For example,
https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
9 but has not yet been fixed in java 8[2]. In a similar fashion,
OkHttp before version 3.5.0 could also fallback back to a direct
connection[3]. So having a "belt and braces", prox(y|ies) and a
security manager, approach is valuable.


[0] "Trusted" classes are not immune to security issues
[1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
[2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
&  https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1180
[3] https://square.github.io/okhttp/changelog_3x/#version-350


From peter.firmstone at zeus.net.au  Mon May 17 05:19:56 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Mon, 17 May 2021 15:19:56 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
Message-ID: 

Although JGDMS is a different type of system, this is one of the 
functions of SecurityManager in our system also.

We have methods equivalent to Subject.doAs, which instead of injecting 
the privileges of the user into all ProtectionDomain's, instead prepends 
a ProtectionDomain that represents the user's Subject onto the call 
stack.? When used in this way, it changes policy file permission 
grant's, it actually simplifies them, because you can grant 
AllPermission to trusted code, if you want to, and then limit user 
permissions and it will restrict only the user, however this doesn't 
fully explain why we do this.

https://pfirmstone.github.io/JGDMS/jgdms-platform/apidocs/net/jini/security/Security.html#doAs-javax.security.auth.Subject-java.security.PrivilegedAction- 


To explain this, requires briefly revisiting the 8 fallacy's of 
distributed computing, that is, item 6, there is only one administrator.

So for your single JVM server, or many instances of JVM's operating 
independently, yes, there is only one administrator, but this is not the 
case for a distributed system.

The reason we prepend a ProtectionDomain representing the user, is that 
there are ProtectionDomain's on the stack that represent Services other 
administrators are responsible for, it just happens to be proxy "code" 
that implements an interface, or interfaces, used for method calls 
between the two systems.? These proxy's are assigned a ClassLoader based 
on the Server's security constraints, the server Endpoint address (by 
the proxy's InvocationHandler implementation) and the codebase annotation.

So it's not really about the code, it's about the Service's identity and 
keeping the identities of different services separated from each other 
(even those using the same proxy code, with different server identity, 
eg for lookup services from different entities) and users, to avoid 
granting those Services all the users permissions while also allowing 
the user to authenticate with the service and also run as a logged in 
subject in threads on the remote node as well.

As previously explained, the permission's required for Service proxy's 
are negotiated dynamically at runtime, between the two parties.? We 
don't grant all the permissions the user has to the remote service 
provider, only those that have been negotiated, when a secure connection 
was first established, so the user allows the service provider to 
utilise some of the users permissions. The service provider cannot 
currently obtain more permission than the user has.

In versions of Java, without a security manager, the third party service 
provider will have AllPermission, and the user will have restricted 
permissions (if we still have some form of user Permission based access 
control).?? So basically we might as well remove all access control 
completely and say that all users and all code is completely trusted, 
the system will be much more user friendly and easier to use, but 
legally that can present problems.

It does appear that a side effect of JEP 411, perhaps even an unintended 
consequence, will be to limit Java to trusted networks with one 
administrator.? It is most certainly appears to be a single JVM focused 
change, or a system controlled by one administrator.

Newer versions of Java will of course be less secure without access 
controls and unsuitable for use in a distributed system that involves 
more than one administrator.

In a way, it's ironic, IPv4 limited us to local networks, but now it 
looks like later versions of Java will now be the limiting factor.

I realize less utilized platform features like access controls aren't 
the concern of OpenJDK developers, but it doesn't appear to be doing any 
harm talking about them, at least so the consequences of the decision 
can be better understood.?? I realize this is probably a business and 
marketing based decision.? I guess Java has more of an enterprise 
history, and it's giving that up to become leaner and more developer 
friendly (less things to learn or understand).

Cheers,

Peter.

On 17/05/2021 12:11 pm, David Black wrote:
> Hi Ron
>
> On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
>>
>>
>>> On 13 May 2021, at 03:11, David Black  wrote:
>>>
>>>
>>> This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
>> This is an important point we?re trying to get across. The very reason the Security Manager was made this
>> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
>> experience have shown us that *in practice* this is not the case, certainly not when you look at the
>> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
>> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
>> the job done, but actually use it incorrectly, providing the illusion of security without actual security.
> Agreed, but if you don't have this level of introspection/detail how
> do you propose to, at least partially, mitigating bug classes such as
> SSRF?
>
>>> Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager).
>>
>> We?re talking about a situation where *all* the classes running in your application are trusted,
>> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
>> Can you explain why you believe this mechanism, that treats different classes differently is the best
>> way to improve security?
> Because it allows for restrictions to be placed upon "trusted"[0]
> classes so as to offer some mitigation against classes of bugs such as
> SSRF. You can also use a security manager to monitor for potential
> policy implementation issues & make adjustments. Specifically for
> SSRF, if you want to mitigate the issue you need to ensure that
> network connections being made respect proxy settings but also allow
> support for certain code paths bypassing proxy settings to access
> potentially sensitive network locations (e.g. cloud metadata
> resources) this can result in mistakes in configuration occurring and
> or finding libraries/classes that ignore proxy configuration. You may
> be thinking "oh but surely no library/class would have proxy
> problems?" well that answer is "yes they can and do". For example,
> https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
> 9 but has not yet been fixed in java 8[2]. In a similar fashion,
> OkHttp before version 3.5.0 could also fallback back to a direct
> connection[3]. So having a "belt and braces", prox(y|ies) and a
> security manager, approach is valuable.
>
>
> [0] "Trusted" classes are not immune to security issues
> [1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
> [2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
> &  https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#L1180
> [3] https://square.github.io/okhttp/changelog_3x/#version-350



From ron.pressler at oracle.com  Mon May 17 11:29:19 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Mon, 17 May 2021 11:29:19 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
Message-ID: 



> On 17 May 2021, at 06:19, Peter Firmstone  wrote:
> 
> 
> In versions of Java, without a security manager, the third party service provider will have AllPermission, and the user will have restricted permissions (if we still have some form of user Permission based access control).  

Follow this issue: https://bugs.openjdk.java.net/browse/JDK-8266592


> So basically we might as well remove all access control completely and say that all users and all code is completely trusted, 

All users ? no, and at this point I?m starting to think that, rather than trying to understand
the direction proposed here, which is ultimately meant to help make Java *more* secure, you?re
trying to intentionally misunderstand and/or misrepresent it.


> 
> It does appear that a side effect of JEP 411, perhaps even an unintended consequence, will be to limit Java to trusted networks with one administrator.  It is most certainly appears to be a single JVM focused change, or a system controlled by one administrator.

Absolutely not. 99.99% of secure distributed systems in the world, written in Java or not,
do not use Java?s Security Manager, and a great many of them mix of Java and other runtimes.

You might have a point, though, that the current direction does not try to tailor a specific
solution to distributed systems made *only* of JVMs, and, because systems are not controlled by 
one administrator, and because many are polyglot, mixing services running on different runtimes, 
this is very much the right direction to go. You, on the other hand, seem to be focused on
?Java only? systems.


> 
> Newer versions of Java will of course be less secure without access controls and unsuitable for use in a distributed system that involves more than one administrator.

Of course not.

I realise you?re trying to paint a picture as if the removal of Security Manager, a barely used 
component, would adversely affects Java security ? contrary to the opinion of security experts ? b
ut the fact is that the vast majority of Java systems today already use other security 
measures, including sandboxes. I don?t know if you actually believe this, in which case you
misunderstand the proposal, or don?t believe it but think that such claims would sound convincing
to others.

It is true that we?re saying to those few remaining people who still depend on Java?s internal 
sandbox to do what most other people have already done and rely on other security measures, and so
*if they do not* their systems will be less secure, but, of course, this is not what?s being
recommended. All this JEP is saying that the JDK itself will not, in the long term, provide this
particular fine-grained sandbox, and that remaining users should switch to other sandboxes available
to Java applications.


? Ron

From ron.pressler at oracle.com  Mon May 17 11:38:44 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Mon, 17 May 2021 11:38:44 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <8B8EF161-3C47-4B88-AB03-3EF0DE332E85@oracle.com>
 
 <5DB9F79D-F8D9-4B1D-842F-99E12FD96C2F@oracle.com>
 
 
 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
Message-ID: <8549C33E-2C39-4E80-9705-83A5ACDD6BC0@oracle.com>

I would say that trying to mitigate attacks on vulnerabilities in trusted code based on specific code paths is 
not recommended. You?re trying to preemptively defend agains something complex ? a security bug ? with 
another complex mechanism. Even if you do happen to defend against a particular attack attempt due to a bug
that happens to be in the ?less trusted? code rather than in the more trusted code, the cost/benefit to this 
approach is not very attractive, in my opinion.

I think it is easier and simpler (and so more secure) to not differentiate codepaths in the same process, grant
whatever minimal privileges are required to the entire process with more watertight mechanisms than the SM, 
and then actively monitor it ? say, with streaming JFR events, which will be made richer, and already do
expose the stack trace ? for suspicious activity. If a bug is found ? fix it.

If your application clearly has more trusted/less exposed components and less trusted/less exposed ones,
and you feel that they must be separated for security reasons, consider running them in different processes. 
Process isolation is a more secure, better studied, and better supported security mechanism than the Security Manager.

? Ron

> On 17 May 2021, at 03:11, David Black  wrote:
> 
> Hi Ron
> 
> On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
>> 
>> 
>> 
>>> On 13 May 2021, at 03:11, David Black  wrote:
>>> 
>>> 
>>> This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
>> 
>> This is an important point we?re trying to get across. The very reason the Security Manager was made this
>> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
>> experience have shown us that *in practice* this is not the case, certainly not when you look at the
>> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
>> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
>> the job done, but actually use it incorrectly, providing the illusion of security without actual security.
> 
> Agreed, but if you don't have this level of introspection/detail how
> do you propose to, at least partially, mitigating bug classes such as
> SSRF?
> 
>>> Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://urldefense.com/v3/__https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager__;!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PHR4-37A$ ).
>> 
>> 
>> We?re talking about a situation where *all* the classes running in your application are trusted,
>> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
>> Can you explain why you believe this mechanism, that treats different classes differently is the best
>> way to improve security?
> 
> Because it allows for restrictions to be placed upon "trusted"[0]
> classes so as to offer some mitigation against classes of bugs such as
> SSRF. You can also use a security manager to monitor for potential
> policy implementation issues & make adjustments. Specifically for
> SSRF, if you want to mitigate the issue you need to ensure that
> network connections being made respect proxy settings but also allow
> support for certain code paths bypassing proxy settings to access
> potentially sensitive network locations (e.g. cloud metadata
> resources) this can result in mistakes in configuration occurring and
> or finding libraries/classes that ignore proxy configuration. You may
> be thinking "oh but surely no library/class would have proxy
> problems?" well that answer is "yes they can and do". For example,
> https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
> 9 but has not yet been fixed in java 8[2]. In a similar fashion,
> OkHttp before version 3.5.0 could also fallback back to a direct
> connection[3]. So having a "belt and braces", prox(y|ies) and a
> security manager, approach is valuable.
> 
> 
> [0] "Trusted" classes are not immune to security issues
> [1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
> [2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
> &  https://urldefense.com/v3/__https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java*L1180__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PCT2HmkQ$ 
> [3] https://urldefense.com/v3/__https://square.github.io/okhttp/changelog_3x/*version-350__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_OyQxtDiw$ 


From github.com+4312191+fmeum at openjdk.java.net  Mon May 17 12:41:04 2021
From: github.com+4312191+fmeum at openjdk.java.net (Fabian Meumertzheim)
Date: Mon, 17 May 2021 12:41:04 GMT
Subject: RFR: 8267086: Fix ArrayIndexOutOfBoundsException in
 DerIndefLenConverter
Message-ID: 

`sun.security.util.DerIndefLenConverter#convertBytes` does not perform sufficient checks after calling `#parseValue`, which can overflow `dataPos` or make it exceed `dataSize`. This can lead to an `ArrayIndexOutOfBoundsException`.

The fix is to ensure `dataPos` is in the valid range `[0,dataSize]` after the call to `parseValue`.

-------------

Commit messages:
 - 8267086: Fix ArrayIndexOutOfBoundsException in DerIndefLenConverter

Changes: https://git.openjdk.java.net/jdk/pull/4058/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4058&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267086
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4058.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4058/head:pull/4058

PR: https://git.openjdk.java.net/jdk/pull/4058


From peter.firmstone at zeus.net.au  Mon May 17 12:47:53 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Mon, 17 May 2021 22:47:53 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
Message-ID: 

Some quick clarifications, I'll try to reply properly in the next few days.

On 17/05/2021 9:29 pm, Ron Pressler wrote:
>
>> On 17 May 2021, at 06:19, Peter Firmstone  wrote:
>>
>>
>> In versions of Java, without a security manager, the third party service provider will have AllPermission, and the user will have restricted permissions (if we still have some form of user Permission based access control).
> Follow this issue: https://bugs.openjdk.java.net/browse/JDK-8266592


Thanks for the link, I am aware of it.

>
>
>> So basically we might as well remove all access control completely and say that all users and all code is completely trusted,
> All users ? no, and at this point I?m starting to think that, rather than trying to understand
> the direction proposed here, which is ultimately meant to help make Java *more* secure, you?re
> trying to intentionally misunderstand and/or misrepresent it.

I understand the direction and the reasons for the decision, however we 
still need to consider how it will impact those who utilise it, and I'm 
sure more examples will come to light in time.

In my case, yes of course it will be less secure, because I'm using the 
stack context to manage access decisions for remote service identity.?? 
These service proxy's now have some very limited permissions, in future 
their access will be completely unrestricted.?? It is a foundational 
feature, it has a significant impact on those who adopted it.


>
>
>> It does appear that a side effect of JEP 411, perhaps even an unintended consequence, will be to limit Java to trusted networks with one administrator.  It is most certainly appears to be a single JVM focused change, or a system controlled by one administrator.
> Absolutely not. 99.99% of secure distributed systems in the world, written in Java or not,
> do not use Java?s Security Manager, and a great many of them mix of Java and other runtimes.
>
> You might have a point, though, that the current direction does not try to tailor a specific
> solution to distributed systems made *only* of JVMs, and, because systems are not controlled by
> one administrator, and because many are polyglot, mixing services running on different runtimes,
> this is very much the right direction to go. You, on the other hand, seem to be focused on
> ?Java only? systems.

This is an existing system, your arguments are not relevant as the cost 
of rewriting millions of lines of code is prohibitively expensive.

Services written in other languages may be providers of services, 
however other language runtimes may not be consumers of services because 
most lack dynamic class loading or dynamic fine grained access 
control.?? The JVM is required to allow services to be agglomerated into 
a system.

My point is that there will be no restriction on the services themselves 
in the JVM consuming and using the services.? Currently service proxy's 
are only allowed to contact their originating server and negotiate a few 
required permissions for their operation.? In future versions of Java 
without a SecurityManager, they will have no restrictions at all.


>
>
>> Newer versions of Java will of course be less secure without access controls and unsuitable for use in a distributed system that involves more than one administrator.
> Of course not.

Yes, it is the case for software that was designed to use the 
SecurityManager.?? We need to be honest about the impact, yes I 
understand SecurityManager will be removed, however telling developers 
their EXISTING software is no less secure is inaccurate.


>
> I realise you?re trying to paint a picture as if the removal of Security Manager, a barely used
> component, would adversely affects Java security ? contrary to the opinion of security experts ? b
> ut the fact is that the vast majority of Java systems today already use other security
> measures, including sandboxes. I don?t know if you actually believe this, in which case you
> misunderstand the proposal, or don?t believe it but think that such claims would sound convincing
> to others.
>
> It is true that we?re saying to those few remaining people who still depend on Java?s internal
> sandbox to do what most other people have already done and rely on other security measures, and so
> *if they do not* their systems will be less secure, but, of course, this is not what?s being
> recommended. All this JEP is saying that the JDK itself will not, in the long term, provide this
> particular fine-grained sandbox, and that remaining users should switch to other sandboxes available
> to Java applications.


Barely used or not, it is only fair to acknowledge the impact on those 
who do use it.

Are you a security expert?? Is this your opinion as a security expert?

I don't need a sandbox, I need access control.

Your proposal is quite plain and simple, I don't see how it can be 
misunderstood, you propose to remove the ability to make stack based 
domain, access control decisions.

These sandboxes you talk of, I have not seen any practical workable 
solutions, I'm assuming your talking about Intel architecture based 
Virtual Machines that host an OS, they don't provide dynamic access 
decisions for Java?? Yes I acknowledge they can do static, but not 
dynamic performant access decisions.

I suspect either you don't understand what I'm talking about, or you 
simply don't want to acknowledge it.? I have provided links to fully 
functional software that utilises SecurityManager.

We should just say, that there is no future migration path for existing 
Java applications that require fine grained access control.

It's quite simple really, just be honest.

I've accepted OpenJDK is doing this, I just want you to acknowledge that 
Java in future will be less capable in this respect than the Java of 
today, so that people who might be impacted take it seriously.

What I intend to do about it, is contribute to existing versions of Java 
to prolong their life.

I'm looking for acknowledgement, so that the importance of maintaining 
Java 17 for a long time is understood for existing applications that use 
fine grained access control, which have no other alternatives can 
continue to remain functional and secure, up to date secure.

Hand waving brush off comments don't provide practical workable solutions.

I think for starters we should discourage those who require fine grained 
access control from using newer versions of Java that don't implement 
it.?? Then it would be nice for those who would like to help maintain an 
existing version of Java that does support fine grained access control 
to do so as a part of the OpenJDK project.

I don't understand why this is so objectionable?

It really doesn't matter what 99.99% of other people are doing for the 
0.01% that use it.? You conveniently plucked these figures out of thin 
air, a word of advice, it lessens the credibility of your arguments.

>
>
> ? Ron

-- 
Regards,
  
Peter Firmstone



From github.com+4312191+fmeum at openjdk.java.net  Mon May 17 12:49:50 2021
From: github.com+4312191+fmeum at openjdk.java.net (Fabian Meumertzheim)
Date: Mon, 17 May 2021 12:49:50 GMT
Subject: RFR: 8267086: Fix ArrayIndexOutOfBoundsException in
 DerIndefLenConverter
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 May 2021 12:33:53 GMT, Fabian Meumertzheim  wrote:

> `sun.security.util.DerIndefLenConverter#convertBytes` does not perform sufficient checks after calling `#parseValue`, which can overflow `dataPos` or make it exceed `dataSize`. This can lead to an `ArrayIndexOutOfBoundsException`.
> 
> The fix is to ensure `dataPos` is in the valid range `[0,dataSize]` after the call to `parseValue`.

The referenced bug is https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8267086, but for some reason the reference is shown as not valid.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4058


From meumertzheim at code-intelligence.com  Mon May 17 13:09:38 2021
From: meumertzheim at code-intelligence.com (Fabian Meumertzheim)
Date: Mon, 17 May 2021 15:09:38 +0200
Subject: Fuzzing for java.security.* (and other libraries)
Message-ID: 

(Crosspost from core-libs-dev@:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077483.html)

I'm one of the maintainers of Jazzer (
https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
fuzzer for the JVM platform. Jazzer has recently been integrated into
Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free
continuous fuzzing of important open-source Java projects. Jazzer has
already found over a hundred bugs and eight security issues in libraries
such as Apache Commons, PDFBox and the OWASP json-sanitizer.

Jazzer finds unexpected exceptions and infinite loops by default, but can
also be used to check domain-specific properties such as
decrypt(encrypt(data)) == data. Since it tracks the coverage it achieves
using instrumentation applied by a Java agent, it can synthesize
interesting test data from scratch.

If there is interest from your side, I could set up the Java core libraries
themselves for fuzzing in OSS-Fuzz. Especially the parts that are
frequently applied to untrusted input, such as java.security.* and
javax.imageio.*, would benefit from fuzz tests. I have prepared basic fuzz
tests for some of the classes in these packages at
https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk,
which has already resulted in a few bug reports by running it locally
(JDK-8267086 is one of them affecting java.security.*).

All I would need from you is:

* a list of email addresses to which the fuzzer findings should be sent
(ideally associated with Google accounts for authentication to full reports
on oss-fuzz.com),
* ideas for additional fuzz tests, in particular those where there are
interesting properties to verify.

The technical questions about setting up the OpenJDK in OSS-Fuzz have
already been resolved (see also
https://github.com/google/oss-fuzz/issues/5757).

If you need more information on OSS-Fuzz or fuzzing in general, I am happy
to help.

Fabian (@fmeum on GitHub)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ron.pressler at oracle.com  Mon May 17 14:25:57 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Mon, 17 May 2021 14:25:57 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <8845FC81-E5C6-4FF7-B732-E1C05B2009EC@oracle.com>
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
Message-ID: 



> On 17 May 2021, at 13:47, Peter Firmstone  wrote:
> 
> It is a foundational feature, it has a significant impact on those who adopted it.

True. But the problem is that it also has a significant impact on those who didn?t.

> 
> 
> This is an existing system, your arguments are not relevant as the cost of rewriting millions of lines of code is prohibitively expensive.

I don?t think we?re talking about rewriting millions of lines of code, and the cost of keeping
Security Manager is far greater, anyway. We want to shift the high cost of maintaining the
SM, or something like it, from those who *don?t* want it to those who do, and I think that?s more
than fair.

> 
> My point is that there will be no restriction on the services themselves in the JVM consuming and using the services.  Currently service proxy's are only allowed to contact their originating server and negotiate a few required permissions for their operation.  In future versions of Java without a SecurityManager, they will have no restrictions at all.

I don?t understand this statement. Which JDK-implemented ?service proxies? are you referring to that
today implement such a restriction in the JDK?

> 
> Yes, it is the case for software that was designed to use the SecurityManager.   We need to be honest about the impact, yes I understand SecurityManager will be removed, however telling developers their EXISTING software is no less secure is inaccurate.
> 

It is accurate, because if existing software picks a new runtime, then it will have to be modified
in order to run at all, if only to acknowledge it is depending on a deprecated, and later, degraded
feature. This JEP is proposing a responsible mechanism precisely to prevent situations like applications
that do depend on SM for security suddenly become less secure without their knowledge.

> 
> Are you a security expert?  Is this your opinion as a security expert?

I am absolutely not a security expert, which is why I talk to security experts who tell me
they do not recommend the Security Manager as a central security measure.


> 
> Your proposal is quite plain and simple, I don't see how it can be misunderstood, you propose to remove the ability to make stack based domain, access control decisions.

Not the ability, but the built-in implementation.

> 
> These sandboxes you talk of, I have not seen any practical workable solutions, I'm assuming your talking about Intel architecture based Virtual Machines that host an OS, they don't provide dynamic access decisions for Java?  Yes I acknowledge they can do static, but not dynamic performant access decisions.

Depends what you mean by ?dynamic.? They do not attempt to provide different access to JDK capabilities
to different code-paths within the same Java process, which is why they are preferable.

> 
> We should just say, that there is no future migration path for existing Java applications that require fine grained access control.

But that is untrue. First, let?s clarify that by ?fine-grained access control? you don?t mean the
ability of an application to allow or disallow application-level operations on as fine a level as they?d
like based on, say, user credentials, but on the JDK blocking *JDK-level* operations based on the code
paths that invoke them. Second, while the JEP does not offer a built-in replacement for such a mechanism,
because few people want it and we believe it is not a good path for security for Java these days, 
if you absolutely want such a mechanism, you can inject instrumentation to replace the built-in one
using the Java Agent mechanism, so there is a migration path even for this use case.

That taking this particular migration path rather than opting for other security measures is not trivial
only demonstrates why the Security Manager needs to be removed, as the people paying for that work now
are those who *don?t* want it.

> 
> I think for starters we should discourage those who require fine grained access control from using newer versions of Java that don't implement it.   Then it would be nice for those who would like to help maintain an existing version of Java that does support fine grained access control to do so as a part of the OpenJDK project.
> 
> I don't understand why this is so objectionable?

Because your very specific and FAR from universal definition of ?fine-grained access control? does
all the work in this statement. It is not objectionable to say that Java will not provide a built-in
mechanism that filters certain JDK operations based on the code-paths in which they are accessed.

> 
> It really doesn't matter what 99.99% of other people are doing for the 0.01% that use it.  You conveniently plucked these figures out of thin air, a word of advice, it lessens the credibility of your arguments.

It is not my intention to convince you personally that the proposal is justified. If you?d like to see the
proposal amended or withdrawn, it is *your* duty to convince those who made it that it should be. If you
think that their assessment of the current value the SM brings to Java users is incorrect, then it is 
up to *you* to support that. I?m carrying on this discussion in the hope that it might uncover some specific 
point that we?ve missed ? precisely because we take it very seriously and don?t wish to brush off anything or
anyone -- not in order to get you to concede anything. For example, you mentioned something about service proxies,
and it would be great if you could explain precisely what you mean.

Sometimes two opposing opinions can be equally reasonable, perhaps based on different values, and yet only one 
can be made. It is never our intention to get universal consensus for every decision concerning such a large 
ecosystem, or we?d never get anything done.

? Ron


From mcimadamore at openjdk.java.net  Mon May 17 16:03:32 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 16:03:32 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v20]
In-Reply-To: 
References: 
Message-ID: 

> 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 with bounded arena allocator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/352c287f..0c464221

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=18-19

  Stats: 112 lines in 3 files changed: 61 ins; 37 del; 14 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


From mcimadamore at openjdk.java.net  Mon May 17 16:08:17 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 17 May 2021 16:08:17 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v21]
In-Reply-To: 
References: 
Message-ID: 

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:

 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob
 - Address CSR comments
 - * Remove unused imports
   * Fix broken javadoc after removal of @throws clauses
   * Remove other `@CallerSensitive` annotations from `AbstractCLinker`
 - Merge branch 'master' into JEP-412
 - Remove redundant checks for --enable-native-access
 - Fix issue in snippet in package-info
 - ... and 20 more: https://git.openjdk.java.net/jdk/compare/893e2ec1...9eb61a46

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/0c464221..9eb61a46

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=19-20

  Stats: 23427 lines in 753 files changed: 8549 ins; 9558 del; 5320 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


From ascarpino at openjdk.java.net  Mon May 17 18:22:28 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 17 May 2021 18:22:28 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore
Message-ID: 

Hi,

I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.

Thanks

Tony

-------------

Commit messages:
 - Update
 - Update, passing tests
 - Re-add missing intrinsic trigger methods
 - update flush
 - reverting
 - reverting
 - Revert "direct bytebuffer GHASH intrinsic"
 - Revert "Splitting perfghash and perfphase1"
 - undo debugging
 - remove intrinsic from GHASH
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/794cefe8...f52d57d6

Changes: https://git.openjdk.java.net/jdk/pull/4072/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255557
  Stats: 2793 lines in 15 files changed: 1403 ins; 695 del; 695 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Mon May 17 18:52:39 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 17 May 2021 18:52:39 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 May 2021 18:13:46 GMT, Anthony Scarpino  wrote:

> Hi,
> 
> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
> 
> Thanks
> 
> Tony

I will take a look. Thanks~

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Mon May 17 20:39:41 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 17 May 2021 20:39:41 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 May 2021 18:13:46 GMT, Anthony Scarpino  wrote:

> Hi,
> 
> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
> 
> Thanks
> 
> Tony

Here are some comments, will continue looking at the rest of changes.
Thanks,
Valerie

src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 155:

> 153:             super(32, new AESCrypt());
> 154:         }
> 155:     }

These should be removed since SunJCE registers com.sun.crypto.provider.GaloisCounterMode$AES128/AES192/AES256 instead of these?

src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java line 128:

> 126:     private static final int CTS_MODE = 6;
> 127: 
> 128:     private byte[] lastEncKey = null;

lastEncKey is also used only by GCM and should be removed with 'requireReinit' and 'lastEncIv'

src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java line 495:

> 493:             String algorithm = key.getAlgorithm();
> 494:             cipher.init(decrypting, algorithm, keyBytes, ivBytes);
> 495:             // skip checking key+iv from now on until after doFinal()

Outdated comment, remove?

src/java.base/share/classes/com/sun/crypto/provider/FeedbackCipher.java line 213:

> 211:      */
> 212:     int getBufferedLength() {
> 213:         return 0;

Since you are removing all GCM related things from FeedbackCipher, why not remove this method as well. Based on the current change, this method is not called at all, right?

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 238:

> 236: 
> 237: //        ps("Cipher", "GCM",
> 238: //            "com.sun.crypto.provider.GaloisCounterMode$AESGCM", null, attrs);

Clean these two lines up?

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 240:

> 238: //            "com.sun.crypto.provider.GaloisCounterMode$AESGCM", null, attrs);
> 239:         ps("Cipher", "AES/GCM/NoPadding",
> 240:             "com.sun.crypto.provider.GaloisCounterMode$AESGCM", null, attrs);

Why this one uses AESGCM but the rest uses AES128, AES192, AES256? Maybe just AES?

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 249:

> 247:         psA("Cipher", "AES_256/GCM/NoPadding",
> 248:             "com.sun.crypto.provider.GaloisCounterMode$AES256",
> 249:             attrs);

Can we please follow the same indentation style for consistency sake? This would also eliminate the unnecessary change such as the one to DESedeWrap and AESWrap cipher registration below.

src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 221:

> 219: 
> 220:         store("AES/GCM", KnownOIDs.AES_128$GCM$NoPadding,
> 221:             "AES/GCM/NoPadding");

In SunJCE class, the registration is done using "AES/GCM/NoPadding" instead of "AES/GCM". I am not sure why is this store() call using AES/GCM is necessary?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Mon May 17 20:39:42 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 17 May 2021 20:39:42 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 17 May 2021 20:24:51 GMT, Valerie Peng  wrote:

>> Hi,
>> 
>> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
>> 
>> Thanks
>> 
>> Tony
>
> src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 155:
> 
>> 153:             super(32, new AESCrypt());
>> 154:         }
>> 155:     }
> 
> These should be removed since SunJCE registers com.sun.crypto.provider.GaloisCounterMode$AES128/AES192/AES256 instead of these?

In addition, the private boolean field "updateCalled" of this class and its relevant assignments can also be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From peter.firmstone at zeus.net.au  Mon May 17 20:46:30 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 18 May 2021 06:46:30 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
Message-ID: <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>


On 18/05/2021 12:25 am, Ron Pressler wrote:
>
>> On 17 May 2021, at 13:47, Peter Firmstone  wrote:
>>
>> It is a foundational feature, it has a significant impact on those who adopted it.
> True. But the problem is that it also has a significant impact on those who didn?t.


Yes, you are talking about those who maintain and develop OpenJDK, but 
this is only a small proportion of the overall Java developer 
ecosystem.??? But I understand that this isn't insignificant either, 
just like the features removal isn't insignificant to those affected by it.

Out of curiosity, was anyone here impacted by the oil pipeline shutting 
down??? Impacts can be direct and indirect.


>
>>
>> This is an existing system, your arguments are not relevant as the cost of rewriting millions of lines of code is prohibitively expensive.
> I don?t think we?re talking about rewriting millions of lines of code, and the cost of keeping
> Security Manager is far greater, anyway. We want to shift the high cost of maintaining the
> SM, or something like it, from those who *don?t* want it to those who do, and I think that?s more
> than fair.


No, it's not practical, but there's no viable upgrade path, so our only 
option is indefinite maintenance of Java 17.


>
>> My point is that there will be no restriction on the services themselves in the JVM consuming and using the services.  Currently service proxy's are only allowed to contact their originating server and negotiate a few required permissions for their operation.  In future versions of Java without a SecurityManager, they will have no restrictions at all.
> I don?t understand this statement. Which JDK-implemented ?service proxies? are you referring to that
> today implement such a restriction in the JDK?


In a distributed system that uses POJO's and Remote Method Invocation, a 
proxy is used to invoke methods on an object in a remote JVM or any 
other language for that matter, operating in another node or process.?? 
The proxy implementation is not known, nor necessarily are it's 
communication methods until runtime.? It is loaded dynamically.

The proxy is trusted code (each implementation has different bytecode), 
but we wish to run it with principles of least privilege, rather than an 
anything goes approach.

https://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS


>
>> Yes, it is the case for software that was designed to use the SecurityManager.   We need to be honest about the impact, yes I understand SecurityManager will be removed, however telling developers their EXISTING software is no less secure is inaccurate.
>>
> It is accurate, because if existing software picks a new runtime, then it will have to be modified
> in order to run at all, if only to acknowledge it is depending on a deprecated, and later, degraded
> feature. This JEP is proposing a responsible mechanism precisely to prevent situations like applications
> that do depend on SM for security suddenly become less secure without their knowledge.


If the application needs access control, but the Java platform doesn't 
provide it, and you must remove it for the application to run, then yes, 
the software will be less secure as a result.? This shouldn't be 
difficult to understand.

So you could say, that the application has become less secure, with 
their knowledge, because it has a task to perform and it will be made so 
that it will continue to perform that task, even at the expense of less 
security, because security has become the obstacle to operation, which 
is the primary purpose, so security becomes a secondary concern.? No one 
will switch it off if it's insecure, at least not until after they're 
hacked, then they'll look for bolt on security solutions and they may 
get approval to rewrite the system at that stage.


>
>> Are you a security expert?  Is this your opinion as a security expert?
> I am absolutely not a security expert, which is why I talk to security experts who tell me
> they do not recommend the Security Manager as a central security measure.


No, but it is a useful security layer to control access.

Security should be seen as a layered approach, rather than one solution 
fits everything.?? Each layer has it's role to play.

The use of SecurityManager as a central security measure is not the intent.

https://www.upguard.com/blog/principle-of-least-privilege

Yes the Java Permission model is flawed, one cannot disallow an insecure 
network connection, while allowing a secure TLS authenticated 
connection, however we've created other ways of doing that, but it does 
rely on the Permission model to limit privilege.


>
>
>> Your proposal is quite plain and simple, I don't see how it can be misunderstood, you propose to remove the ability to make stack based domain, access control decisions.
> Not the ability, but the built-in implementation.


It is not possible to implement fine grained access control in Java, or 
as a library, this feature is low level JVM code.

Developers who wish to develop new applications that require access 
control should do so using another platform, those who have existing 
software deployments, need to stay on Java 17 for example, indefinitely 
until EOL.

New developments that require access control might consider the 
Microsoft CLR for example, however I'm no expert, there may be better 
alternatives. 
https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/


>
>> These sandboxes you talk of, I have not seen any practical workable solutions, I'm assuming your talking about Intel architecture based Virtual Machines that host an OS, they don't provide dynamic access decisions for Java?  Yes I acknowledge they can do static, but not dynamic performant access decisions.
> Depends what you mean by ?dynamic.? They do not attempt to provide different access to JDK capabilities
> to different code-paths within the same Java process, which is why they are preferable.


Dynamic means at runtime, not compile time or installation time.

We did look at using a separate process to sandbox untrusted code, but 
it just didn't seem like a good idea to allow untrusted code to run at 
all, at least not dynamically, one should run static analysis on it 
first, but if it's a black box, you can only inspect bytecode, not 
source and it can be obfuscated.

This is why authentication is still important, but even that can be 
circumvented by a good attacker and shouldn't be relied upon as the only 
defense.


>
>> We should just say, that there is no future migration path for existing Java applications that require fine grained access control.
> But that is untrue. First, let?s clarify that by ?fine-grained access control? you don?t mean the
> ability of an application to allow or disallow application-level operations on as fine a level as they?d
> like based on, say, user credentials, but on the JDK blocking *JDK-level* operations based on the code
> paths that invoke them. Second, while the JEP does not offer a built-in replacement for such a mechanism,
> because few people want it and we believe it is not a good path for security for Java these days,
> if you absolutely want such a mechanism, you can inject instrumentation to replace the built-in one
> using the Java Agent mechanism, so there is a migration path even for this use case.
>
> That taking this particular migration path rather than opting for other security measures is not trivial
> only demonstrates why the Security Manager needs to be removed, as the people paying for that work now
> are those who *don?t* want it.


To restrict operations to the principle of least privilege.

https://us-cert.cisa.gov/bsi/articles/knowledge/principles/least-privilege

https://www.upguard.com/blog/principle-of-least-privilege

It would have been better if we could have assigned principles of least 
privilege to Java library's too.

The code is not known at compile time, it is dynamic, such that it is 
only known at runtime, this means that to use the Java Agent mechanism, 
one must intercept every network and file system access, then try to 
determine where the call originates, to see whether it can be allowed or 
disallowed.

There is no feature in Java past release 17 that would interest me 
enough to perform this amount of work on an existing application, nor 
would it even be a viable option if I wanted to. So I can't pay for it 
even if I want to, as it is unaffordium.

Besides we know what runs now is very performant, high scaling and 
concurrent.?? It? also runs with the principles of least privilege, so 
if someone makes a coding mistake, it will be more difficult for an 
attacker to take advantage of.



>
>> I think for starters we should discourage those who require fine grained access control from using newer versions of Java that don't implement it.   Then it would be nice for those who would like to help maintain an existing version of Java that does support fine grained access control to do so as a part of the OpenJDK project.
>>
>> I don't understand why this is so objectionable?
> Because your very specific and FAR from universal definition of ?fine-grained access control? does
> all the work in this statement. It is not objectionable to say that Java will not provide a built-in
> mechanism that filters certain JDK operations based on the code-paths in which they are accessed.


As you say, it's a small segment of the development base that needs this 
feature, we should advise them to use a platform that supports it, 
rather than try to get Java to do such things by bolting it on as an 
afterthought.?? Security added later doesn't work, it needs to be 
considered at the design stage.

https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/


>
>> It really doesn't matter what 99.99% of other people are doing for the 0.01% that use it.  You conveniently plucked these figures out of thin air, a word of advice, it lessens the credibility of your arguments.
> It is not my intention to convince you personally that the proposal is justified. If you?d like to see the
> proposal amended or withdrawn, it is *your* duty to convince those who made it that it should be. If you
> think that their assessment of the current value the SM brings to Java users is incorrect, then it is
> up to *you* to support that. I?m carrying on this discussion in the hope that it might uncover some specific
> point that we?ve missed ? precisely because we take it very seriously and don?t wish to brush off anything or
> anyone -- not in order to get you to concede anything. For example, you mentioned something about service proxies,
> and it would be great if you could explain precisely what you mean.
>
> Sometimes two opposing opinions can be equally reasonable, perhaps based on different values, and yet only one
> can be made. It is never our intention to get universal consensus for every decision concerning such a large
> ecosystem, or we?d never get anything done.
>
> ? Ron


I'm looking at how to support existing deployments that utilise existing 
Java access control features.

Your world sounds more of a static compile time, everything is known up 
front environment, mine is dynamic and flexible and unknown until after 
a process has been running for some time. The bytecode we wish to manage 
access control of, may be written years after an existing deployment has 
been running, we don't need to shutdown that deployment, or forklift 
upgrade it, we simply add the new components, or nodes and they are 
discovered dynamically at runtime and become an integral part of the 
system automatically.

However I suspect that you haven't got JEP 411 over the line yet and you 
are worried that open discussion of the issues it causes may stop it, 
because it impacts something you are trying to implement.?? I apologize 
if this discussion inconveniences you, but it's still relevant and we 
should be looking at maintaining a version of Java that supports access 
control for a very long time, not 8 years. ? As part of this JEP or make 
removal of the SecurityManager and associated components dependent on 
another JEP that proposes maintaining a version of Java 17 for the 
foreseeable future.?? This would be community supported version by those 
who require it, maybe we can backport some things in later versions. 
Simply because access control cannot be implemented as a library feature 
or bolted onto the JVM as an agent instrumenting unknown bytecodes.

The only other alternatives is either a complete rewrite in another 
language, or forking Java, but neither seem viable.

I wouldn't recommend a new development that requires access control to 
consider using the Java platform at this time.? As you say, it is only a 
small number of developments, but they should look elsewhere.

I'm unable at this time to advise where people should look as I'm still 
in the investigation stage myself.?? If someone does know of other 
platforms that do access control well, please inform me.

-- 
Regards,
  
Peter Firmstone



From ascarpino at openjdk.java.net  Mon May 17 21:12:15 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 17 May 2021 21:12:15 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 17 May 2021 20:29:37 GMT, Valerie Peng  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 155:
>> 
>>> 153:             super(32, new AESCrypt());
>>> 154:         }
>>> 155:     }
>> 
>> These should be removed since SunJCE registers com.sun.crypto.provider.GaloisCounterMode$AES128/AES192/AES256 instead of these?
>
> In addition, the private boolean field "updateCalled" of this class and its relevant assignments can also be removed.

Good catch on some of these older files that I changed.. I hadn't even thought about going back to check on them

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Mon May 17 21:36:42 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 17 May 2021 21:36:42 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 17 May 2021 19:28:04 GMT, Valerie Peng  wrote:

>> Hi,
>> 
>> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
>> 
>> Thanks
>> 
>> Tony
>
> src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 240:
> 
>> 238: //            "com.sun.crypto.provider.GaloisCounterMode$AESGCM", null, attrs);
>> 239:         ps("Cipher", "AES/GCM/NoPadding",
>> 240:             "com.sun.crypto.provider.GaloisCounterMode$AESGCM", null, attrs);
> 
> Why this one uses AESGCM but the rest uses AES128, AES192, AES256? Maybe just AES?

It's part of the getInstance() provider selection.  in AESCipher it does the same thing with CBC, ECB, etc, but the AESCipher.General is used.  Because this is the only AES mode specified that is not using General and outside AESCipher, it had to be implemented separately

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Mon May 17 21:41:37 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 17 May 2021 21:41:37 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
> 
> Thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision:

 - review comment updates
 - Fixed the lack of overlap detection with GCMEncrypt.update()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4072/files
  - new: https://git.openjdk.java.net/jdk/pull/4072/files/f52d57d6..b21c2723

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=00-01

  Stats: 42 lines in 4 files changed: 10 ins; 23 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072

PR: https://git.openjdk.java.net/jdk/pull/4072


From weijun at openjdk.java.net  Mon May 17 22:01:49 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:49 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
Message-ID: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>

Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).

With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).

To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:

1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.

Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.

Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.

Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.

There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).

3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).

2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:

rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
 ```

The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

-------------

Commit messages:
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - test for nio
 - test for hotspot-runtime
 - test for security
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/79b39445...900c28c0

Changes: https://git.openjdk.java.net/jdk/pull/4071/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267184
  Stats: 1024 lines in 852 files changed: 249 ins; 8 del; 767 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071


From weijun at openjdk.java.net  Mon May 17 22:01:52 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:52 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for
 Removal
Message-ID: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>

Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).

The code change is divided into 3 commits. Please review them one by one.

1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal

The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.

Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.

Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

-------------

Commit messages:
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266459
  Stats: 2018 lines in 826 files changed: 1884 ins; 9 del; 125 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Mon May 17 22:01:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 17 May 2021 22:01:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The 3rd commit is the biggest one but it's all generated programmatically. All changes are simply adding `@SupressWarnings("removal")` to a declaration.

Precisely, of all the diff hunks (leading whitespaces ignored), there are 1607 

+ @SuppressWarnings("removal")


There are also 7 cases where an existing annotation is updated

================= 2 ====================
- @SuppressWarnings("deprecation")
+ @SuppressWarnings({"removal","deprecation"})
================= 1 ====================
- @SuppressWarnings("Convert2Lambda")
+ @SuppressWarnings({"removal","Convert2Lambda"})
================= 1 ====================
- @SuppressWarnings({"unchecked", "CloneDeclaresCloneNotSupported"})
+ @SuppressWarnings({"removal","unchecked", "CloneDeclaresCloneNotSupported"})
================= 1 ====================
- @SuppressWarnings("deprecation") // Use of RMISecurityManager
+ @SuppressWarnings({"removal","deprecation"}) // Use of RMISecurityManager
================= 1 ====================
- @SuppressWarnings("unchecked")     /*To suppress warning from line 1374*/
+ @SuppressWarnings({"removal","unchecked"})     /*To suppress warning from line 1374*/
================= 1 ====================
- @SuppressWarnings("fallthrough")
+ @SuppressWarnings({"removal","fallthrough"})


All other cases are new annotation embedded inline:

================= 7 ====================
- AccessControlContext acc) {
+ @SuppressWarnings("removal") AccessControlContext acc) {
================= 4 ====================
- AccessControlContext acc,
+ @SuppressWarnings("removal") AccessControlContext acc,
================= 3 ====================
- AccessControlContext context,
+ @SuppressWarnings("removal") AccessControlContext context,
================= 3 ====================
- AccessControlContext acc)
+ @SuppressWarnings("removal") AccessControlContext acc)
================= 2 ====================
- try (InputStream stream = AccessController.doPrivileged(pa)) {
+ try (@SuppressWarnings("removal") InputStream stream = AccessController.doPrivileged(pa)) {
================= 2 ====================
- AccessControlContext context, Permission... perms) {
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
================= 2 ====================
- } catch (java.security.AccessControlException e) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException e) {
================= 2 ====================
- } catch (AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") AccessControlException ace) {
================= 2 ====================
- AccessControlContext context)
+ @SuppressWarnings("removal") AccessControlContext context)
================= 2 ====================
- AccessControlContext acc) throws LoginException {
+ @SuppressWarnings("removal") AccessControlContext acc) throws LoginException {
================= 2 ====================
- } catch (AccessControlException e) {
+ } catch (@SuppressWarnings("removal") AccessControlException e) {
================= 1 ====================
- public static void addHook(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ public static void addHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- DomainCombiner combiner,
+ @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- } catch (java.security.AccessControlException ace) {
+ } catch (@SuppressWarnings("removal") java.security.AccessControlException ace) {
================= 1 ====================
- private static File checkFile(File f, SecurityManager sm) {
+ private static File checkFile(File f, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static File checkFile(File file, SecurityManager sm) {
+ private static File checkFile(File file, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm,
+ private static void checkPackageAccessForPermittedSubclasses(@SuppressWarnings("removal") SecurityManager sm,
================= 1 ====================
- ProtectionDomain[] getProtectDomains(AccessControlContext context);
+ ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- SecureCallbackHandler(java.security.AccessControlContext acc,
+ SecureCallbackHandler(@SuppressWarnings("removal") java.security.AccessControlContext acc,
================= 1 ====================
- private static void addHookInternal(AccessControlContext acc, PlatformEventType type, Runnable hook) {
+ private static void addHookInternal(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType type, Runnable hook) {
================= 1 ====================
- private void checkMemberAccess(SecurityManager sm, int which,
+ private void checkMemberAccess(@SuppressWarnings("removal") SecurityManager sm, int which,
================= 1 ====================
- private static File[] checkFiles(Stream filesStream, SecurityManager sm) {
+ private static File[] checkFiles(Stream filesStream, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- Thread(Runnable target, AccessControlContext acc) {
+ Thread(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public ProtectionDomain[] getProtectDomains(AccessControlContext context) {
+ public ProtectionDomain[] getProtectDomains(@SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext stack,
- AccessControlContext context);
+ @SuppressWarnings("removal") AccessControlContext stack,
+ @SuppressWarnings("removal") AccessControlContext context);
================= 1 ====================
- AccessControlContext(ProtectionDomain caller, DomainCombiner combiner,
+ AccessControlContext(ProtectionDomain caller, @SuppressWarnings("removal") DomainCombiner combiner,
================= 1 ====================
- public URLClassPath(URL[] urls, AccessControlContext acc) {
+ public URLClassPath(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- URLClassLoader(URL[] urls, AccessControlContext acc) {
+ URLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- public static void setSecurityManager(SecurityManager sm) {
+ public static void setSecurityManager(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- try (DataInputStream dis = new DataInputStream(new InflaterInputStream(
+ try (@SuppressWarnings("removal") DataInputStream dis = new DataInputStream(new InflaterInputStream(
================= 1 ====================
- try (FileInputStream fis = AccessController.doPrivileged(
+ try (@SuppressWarnings("removal") FileInputStream fis = AccessController.doPrivileged(
================= 1 ====================
- FactoryURLClassLoader(URL[] urls, AccessControlContext acc) {
+ FactoryURLClassLoader(URL[] urls, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- Thread newThreadWithAcc(Runnable target, AccessControlContext acc);
+ Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc);
================= 1 ====================
- SecureRecorderListener(AccessControlContext context, FlightRecorderListener changeListener) {
+ SecureRecorderListener(@SuppressWarnings("removal") AccessControlContext context, FlightRecorderListener changeListener) {
================= 1 ====================
- private PolicyDelegate(PolicySpi spi, Provider p,
+ private PolicyDelegate(@SuppressWarnings("removal") PolicySpi spi, Provider p,
================= 1 ====================
- DomainCombiner combiner) {
+ @SuppressWarnings("removal") DomainCombiner combiner) {
================= 1 ====================
- PrivilegedRunnable(Runnable r, AccessControlContext acc) {
+ PrivilegedRunnable(Runnable r, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private static File[] checkFiles(Stream fs, SecurityManager sm) {
+ private static File[] checkFiles(Stream fs, @SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- private void checkSpecifyHandler(SecurityManager sm) {
+ private void checkSpecifyHandler(@SuppressWarnings("removal") SecurityManager sm) {
================= 1 ====================
- String serverPrincipal, AccessControlContext acc)
+ String serverPrincipal, @SuppressWarnings("removal") AccessControlContext acc)
================= 1 ====================
- public Thread newThreadWithAcc(Runnable target, AccessControlContext acc) {
+ public Thread newThreadWithAcc(Runnable target, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- try (InputStream is = AccessController.doPrivileged(new PrivilegedAction() {
+ try (@SuppressWarnings("removal") InputStream is = AccessController.doPrivileged(new PrivilegedAction() {
================= 1 ====================
- public EventFileStream(AccessControlContext acc, Path path) throws IOException {
+ public EventFileStream(@SuppressWarnings("removal") AccessControlContext acc, Path path) throws IOException {
================= 1 ====================
- AccessControlContext context, Permission... perms)
+ @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
================= 1 ====================
- private static void privateCheckPackageAccess(SecurityManager s, Class clazz) {
+ private static void privateCheckPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) {
================= 1 ====================
- AbstractEventStream(AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException {
+ AbstractEventStream(@SuppressWarnings("removal") AccessControlContext acc, PlatformRecording recording, List configurations) throws IOException {
================= 1 ====================
- private void checkPackageAccess(SecurityManager sm, final ClassLoader ccl,
+ private void checkPackageAccess(@SuppressWarnings("removal") SecurityManager sm, final ClassLoader ccl,
================= 1 ====================
- AccessControlContext context) {
+ @SuppressWarnings("removal") AccessControlContext context) {
================= 1 ====================
- public PrivilegedExecutor(Executor executor, AccessControlContext acc) {
+ public PrivilegedExecutor(Executor executor, @SuppressWarnings("removal") AccessControlContext acc) {
================= 1 ====================
- private RequestHook(AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
+ private RequestHook(@SuppressWarnings("removal") AccessControlContext acc, PlatformEventType eventType, Runnable hook) {
================= 1 ====================
- try (BufferedReader bufferedReader =
+ try (@SuppressWarnings("removal") BufferedReader bufferedReader =
================= 1 ====================
- private static void privateCheckProxyPackageAccess(SecurityManager s, Class clazz) {
+ private static void privateCheckProxyPackageAccess(@SuppressWarnings("removal") SecurityManager s, Class clazz) {


**That's all**.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From ron.pressler at oracle.com  Mon May 17 22:16:48 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Mon, 17 May 2021 22:16:48 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
References: 
 <690FFD42-1D05-4487-8CB5-D1A6586E215D@oracle.com>
 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
Message-ID: <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>



> On 17 May 2021, at 21:46, Peter Firmstone  wrote:
> 
> 
> Yes, you are talking about those who maintain and develop OpenJDK, but this is only a small proportion of the overall Java developer ecosystem.   

Not at all. I?m talking about the millions of developers who don?t get what they need sooner because the
OpenJDK?s resources are invested in maintaining components that add little value to the ecosystem.

> 
> No, it's not practical, but there's no viable upgrade path, so our only option is indefinite maintenance of Java 17.

I?m not going to tell you where to put your money, but writing a Java agent is orders of magnitude cheaper
than maintaining an eight-million-line codebase indefinitely.

> 
> In a distributed system that uses POJO's and Remote Method Invocation, a proxy is used to invoke methods on an object in a remote JVM or any other language for that matter, operating in another node or process.   The proxy implementation is not known, nor necessarily are it's communication methods until runtime.  It is loaded dynamically.
> 
> The proxy is trusted code (each implementation has different bytecode), but we wish to run it with principles of least privilege, rather than an anything goes approach.
> 
> https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEEqMlozJA$ 

I?m not sure I understand. If you?re not talking about a JDK mechanism, you can change that mechanism
to not use the Security Manager, just as JAAS will be changed.

> 
> If the application needs access control, but the Java platform doesn't provide it, and you must remove it for the application to run, then yes, the software will be less secure as a result.  This shouldn't be difficult to understand.

I understand but disagree.

> 
> No, but it is a useful security layer to control access.

The utility of *this particular mechanism* does not justify the cost of maintaining it.
The question isn?t if such a mechanism could be useful or not, but is this the best use of resources to improve security?
In other words, the choice isn?t between this and nothing, but between this and everything else.

> 
> It is not possible to implement fine grained access control in Java, or as a library, this feature is low level JVM code.

Again, when you say fine-grained level access control you don?t mean fine-grained level access control but the
particular features provided by the Security Manager; and those features ? at least those you sound most interested
in ? are not low-level JVM code, and can be implemented in Java with a Java agent, at least as an additional, albeit
imperfect layer of security, if you think this is a worthwhile and cost-effective approach.

> 
> Developers who wish to develop new applications that require access control should do so using another platform, those who have existing software deployments, need to stay on Java 17 for example, indefinitely until EOL.

I strongly disagree; the Security Manager is not the only ? and I would say it?s not even the best ? way to 
offer access control. This JEP proposes removing Security Manager. That that implies giving up on access control 
is entirely your insistence on identifying the two. And if the only way you can think of implementing access 
control is with a call-stack code-sourcing mechanism, then I?m afraid other platforms are not going to offer it, 
because they also don?t share the view that this is the best, let alone the only, way to do this. 

> 
> New developments that require access control might consider the Microsoft CLR for example, however I'm no expert, there may be better alternatives. https://urldefense.com/v3/__https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEF_yAtVXw$ 

.NET have also dropped their analogous mechanism; they, too, have become convinced that different permissions 
to different code *in the same process* is not a the best approach to security today in cost/benefit. 
Erlang, another platform with a strong emphasis on distributed systems also does not provide this mechanism. I am not
aware of any platform that does.

> 
> To restrict operations to the principle of least privilege.

The principles are known, but not every additional layer is worth it at any cost. 

> 
> The code is not known at compile time, it is dynamic, such that it is only known at runtime, this means that to use the Java Agent mechanism, one must intercept every network and file system access, then try to determine where the call originates, to see whether it can be allowed or disallowed.

The Java agent can insert the same instrumentation points as the Security Manager in JDK code, and the equivalent
of protection domains will be determined by the framework and stored and manipulated as ThreadLocals. StackWalker
provides what you need for determining caller classes.

> 
> There is no feature in Java past release 17 that would interest me enough to perform this amount of work on an existing application, nor would it even be a viable option if I wanted to. So I can't pay for it even if I want to, as it is unaffordium.
> 

I am sorry, but asking the majority of Java developers who prefer other approaches to pay for it is even less fair.

> I'm looking at how to support existing deployments that utilise existing Java access control features.
> 
> Your world sounds more of a static compile time, everything is known up front environment, mine is dynamic and flexible and unknown until after a process has been running for some time.

I think that instead of working on finding alternatives that would make the cost structure of something
few people want, you?ve decided that the existing mechanism is the only way to do it.

> 
> However I suspect that you haven't got JEP 411 over the line yet and you are worried that open discussion of the issues it causes may stop it, because it impacts something you are trying to implement.   I apologize if this discussion inconveniences you, but it's still relevant and we should be looking at maintaining a version of Java that supports access control for a very long time, not 8 years.  

You have to convince the relevant maintainers, and this discussion does not inconveniences me because I?m just trying to 
see if there?s something we missed. The Security Manager does not harm the development of any one particular feature 
because new features have already largely overlooked it with few people even noticing. It does, however, take a 
significant toll on resources that could be put to better use elsewhere, including features that improve security in 
a more cost-effective way.

> 
> The only other alternatives is either a complete rewrite in another language, or forking Java, but neither seem viable.

I don?t think this is the only other alternative at all, and repeating this claim is not something that, I think, will 
help delay this JEP. Evidence that thousands of companies rely on the Security Manager for security might, but short of
that I think your time would be better spent on trying to suggest alternatives to some critical pieces that might be
acceptable cost-wise.

> 
> I wouldn't recommend a new development that requires access control to consider using the Java platform at this time.

OK.

> 
> I'm unable at this time to advise where people should look as I'm still in the investigation stage myself.   If someone does know of other platforms that do access control well, please inform me.
> 

If by ?well? you mean the way that you currently do it and you?re not willing to even consider alternative approaches, 
I think you might be disappointed.

? Ron

From erikj at openjdk.java.net  Mon May 17 22:30:56 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 17 May 2021 22:30:56 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Makefile change looks ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073


From dblack at atlassian.com  Tue May 18 00:02:12 2021
From: dblack at atlassian.com (David Black)
Date: Tue, 18 May 2021 10:02:12 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
Message-ID: 

Hi Ron,

On Mon, 17 May 2021 at 21:38, Ron Pressler  wrote:
>
> I would say that trying to mitigate attacks on vulnerabilities in trusted code based on specific code paths is
> not recommended. You?re trying to preemptively defend agains something complex ? a security bug ? with
> another complex mechanism. Even if you do happen to defend against a particular attack attempt due to a bug
> that happens to be in the ?less trusted? code rather than in the more trusted code, the cost/benefit to this
> approach is not very attractive, in my opinion.

That is your opinion and I will note that your reply didn't reference
my references that noted that there are & have been bugs in libraries
and java itself which make mitigating SSRF attacks difficult.
With regards to mitigating SSRF "something complex", I'd argue that it
isn't complex in itself but mitigating SSRF can be, with another
complex mechanism - I will note that implementing the mechanism is
rather simple so long as you are not using the built in java security
manager.

> I think it is easier and simpler (and so more secure) to not differentiate codepaths in the same process, grant
> whatever minimal privileges are required to the entire process with more watertight mechanisms than the SM,
> and then actively monitor it ? say, with streaming JFR events, which will be made richer, and already do
> expose the stack trace ? for suspicious activity. If a bug is found ? fix it.

I am not familiar with the Java Flight recorder but the documentation
for it seems to suggest that it is only for diagnostic purposes.

>
> If your application clearly has more trusted/less exposed components and less trusted/less exposed ones,
> and you feel that they must be separated for security reasons, consider running them in different processes.
> Process isolation is a more secure, better studied, and better supported security mechanism than the Security Manager.

My reading of your proposed solution is that it requires
re-architecting applications to ensure that any potential security
issues occur inside of an isolated and monitored component/process.
However, we do not get to pick where security issues can develop. It
is true we can mitigate the risk of security issues by using isolated
processes but I think you may have missed my main point which is
effectively "something that lets us examine $X, e.g. a network
connection, before the action is performed let's us at least partially
mitigate security vulnerabilities and while it might be ideal to have
software that contains 0 security vulnerabilities in it that often
isn't realistic." From my prior email - "So having a "belt and
braces", prox(y|ies) and a security manager, approach is valuable."
Perhaps a different but I would argue more complex solution would be
to use a java agent to rewrite java classes so as to be able to
implement class based checks at run time or to have java provide event
hooks where decisions can be made (but ... that sounds rather similar
to the current situation with the security manager).

I would like to apologise for the system we use at my place of work
messing with the email subject. But I would appreciate it if you
didn't top post to reply to my email as you have left out some
concerns such as that Java 8 seemingly is still affected by
https://bugs.openjdk.java.net/browse/JDK-8161016.


> ? Ron
>
> > On 17 May 2021, at 03:11, David Black  wrote:
> >
> > Hi Ron
> >
> > On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
> >>
> >>
> >>
> >>> On 13 May 2021, at 03:11, David Black  wrote:
> >>>
> >>>
> >>> This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
> >>
> >> This is an important point we?re trying to get across. The very reason the Security Manager was made this
> >> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
> >> experience have shown us that *in practice* this is not the case, certainly not when you look at the
> >> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
> >> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
> >> the job done, but actually use it incorrectly, providing the illusion of security without actual security.
> >
> > Agreed, but if you don't have this level of introspection/detail how
> > do you propose to, at least partially, mitigating bug classes such as
> > SSRF?
> >
> >>> Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://urldefense.com/v3/__https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager__;!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PHR4-37A$ ).
> >>
> >>
> >> We?re talking about a situation where *all* the classes running in your application are trusted,
> >> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
> >> Can you explain why you believe this mechanism, that treats different classes differently is the best
> >> way to improve security?
> >
> > Because it allows for restrictions to be placed upon "trusted"[0]
> > classes so as to offer some mitigation against classes of bugs such as
> > SSRF. You can also use a security manager to monitor for potential
> > policy implementation issues & make adjustments. Specifically for
> > SSRF, if you want to mitigate the issue you need to ensure that
> > network connections being made respect proxy settings but also allow
> > support for certain code paths bypassing proxy settings to access
> > potentially sensitive network locations (e.g. cloud metadata
> > resources) this can result in mistakes in configuration occurring and
> > or finding libraries/classes that ignore proxy configuration. You may
> > be thinking "oh but surely no library/class would have proxy
> > problems?" well that answer is "yes they can and do". For example,
> > https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
> > 9 but has not yet been fixed in java 8[2]. In a similar fashion,
> > OkHttp before version 3.5.0 could also fallback back to a direct
> > connection[3]. So having a "belt and braces", prox(y|ies) and a
> > security manager, approach is valuable.
> >
> >
> > [0] "Trusted" classes are not immune to security issues
> > [1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
> > [2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
> > &  https://urldefense.com/v3/__https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java*L1180__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PCT2HmkQ$
> > [3] https://urldefense.com/v3/__https://square.github.io/okhttp/changelog_3x/*version-350__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_OyQxtDiw$
>


--
David Black / Security Engineer.


From peter.firmstone at zeus.net.au  Tue May 18 00:11:50 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 18 May 2021 10:11:50 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
References: 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
Message-ID: <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>

Your ideas are great in theory, in practice, the problem with your Agent 
proposal is every JVM release needs to be reviewed, and we have to 
review Java's internal implementation code, and understand it in order 
to instrument it.? But I do appreciate you took the time to do your 
homework to make the suggestion.

Maybe if you put hooks (annotations?) into the JVM code, so it was 
easier for agents to know which calls need to be controlled for access 
decisions??? But then if not many people are using it, it will suffer 
neglect.

To answer your use case question below, we use a ClassLoader and 
ProtectionDomain, to represent the remote server Subject, this is not 
for authentication, just for access control.? JAAS is used for 
authentication of TLS endpoints.?? For services, the calling Subject is 
run in the context of the thread on the remote machine for access 
decisions also.

It's your existing userbase with over 50% still using Java 8 that need 
convincing, who will be ultimate judge of the success or failure of this 
decision.

Thanks for your time.

-- 
Regards,
  
Peter Firmstone

On 18/05/2021 8:16 am, Ron Pressler wrote:
>
>> On 17 May 2021, at 21:46, Peter Firmstone  wrote:
>>
>>
>> Yes, you are talking about those who maintain and develop OpenJDK, but this is only a small proportion of the overall Java developer ecosystem.
> Not at all. I?m talking about the millions of developers who don?t get what they need sooner because the
> OpenJDK?s resources are invested in maintaining components that add little value to the ecosystem.
>
>> No, it's not practical, but there's no viable upgrade path, so our only option is indefinite maintenance of Java 17.
> I?m not going to tell you where to put your money, but writing a Java agent is orders of magnitude cheaper
> than maintaining an eight-million-line codebase indefinitely.
>
>> In a distributed system that uses POJO's and Remote Method Invocation, a proxy is used to invoke methods on an object in a remote JVM or any other language for that matter, operating in another node or process.   The proxy implementation is not known, nor necessarily are it's communication methods until runtime.  It is loaded dynamically.
>>
>> The proxy is trusted code (each implementation has different bytecode), but we wish to run it with principles of least privilege, rather than an anything goes approach.
>>
>> https://urldefense.com/v3/__https://github.com/pfirmstone/JGDMS/wiki/OSGi-and-JGDMS__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEEqMlozJA$
> I?m not sure I understand. If you?re not talking about a JDK mechanism, you can change that mechanism
> to not use the Security Manager, just as JAAS will be changed.
>
>> If the application needs access control, but the Java platform doesn't provide it, and you must remove it for the application to run, then yes, the software will be less secure as a result.  This shouldn't be difficult to understand.
> I understand but disagree.
>
>> No, but it is a useful security layer to control access.
> The utility of *this particular mechanism* does not justify the cost of maintaining it.
> The question isn?t if such a mechanism could be useful or not, but is this the best use of resources to improve security?
> In other words, the choice isn?t between this and nothing, but between this and everything else.
>
>> It is not possible to implement fine grained access control in Java, or as a library, this feature is low level JVM code.
> Again, when you say fine-grained level access control you don?t mean fine-grained level access control but the
> particular features provided by the Security Manager; and those features ? at least those you sound most interested
> in ? are not low-level JVM code, and can be implemented in Java with a Java agent, at least as an additional, albeit
> imperfect layer of security, if you think this is a worthwhile and cost-effective approach.
>
>> Developers who wish to develop new applications that require access control should do so using another platform, those who have existing software deployments, need to stay on Java 17 for example, indefinitely until EOL.
> I strongly disagree; the Security Manager is not the only ? and I would say it?s not even the best ? way to
> offer access control. This JEP proposes removing Security Manager. That that implies giving up on access control
> is entirely your insistence on identifying the two. And if the only way you can think of implementing access
> control is with a call-stack code-sourcing mechanism, then I?m afraid other platforms are not going to offer it,
> because they also don?t share the view that this is the best, let alone the only, way to do this.
>
>> New developments that require access control might consider the Microsoft CLR for example, however I'm no expert, there may be better alternatives. https://urldefense.com/v3/__https://www.c-sharpcorner.com/UploadFile/84c85b/net-code-access-security-cas/__;!!GqivPVa7Brio!PAF0JUFBtHO0VgRqhSDtRI3p3J-zPmJvmwVDF7p7eXyLj3MoMOHjQfCKUEF_yAtVXw$
> .NET have also dropped their analogous mechanism; they, too, have become convinced that different permissions
> to different code *in the same process* is not a the best approach to security today in cost/benefit.
> Erlang, another platform with a strong emphasis on distributed systems also does not provide this mechanism. I am not
> aware of any platform that does.
>
>> To restrict operations to the principle of least privilege.
> The principles are known, but not every additional layer is worth it at any cost.
>
>> The code is not known at compile time, it is dynamic, such that it is only known at runtime, this means that to use the Java Agent mechanism, one must intercept every network and file system access, then try to determine where the call originates, to see whether it can be allowed or disallowed.
> The Java agent can insert the same instrumentation points as the Security Manager in JDK code, and the equivalent
> of protection domains will be determined by the framework and stored and manipulated as ThreadLocals. StackWalker
> provides what you need for determining caller classes.
>
>> There is no feature in Java past release 17 that would interest me enough to perform this amount of work on an existing application, nor would it even be a viable option if I wanted to. So I can't pay for it even if I want to, as it is unaffordium.
>>
> I am sorry, but asking the majority of Java developers who prefer other approaches to pay for it is even less fair.
>
>> I'm looking at how to support existing deployments that utilise existing Java access control features.
>>
>> Your world sounds more of a static compile time, everything is known up front environment, mine is dynamic and flexible and unknown until after a process has been running for some time.
> I think that instead of working on finding alternatives that would make the cost structure of something
> few people want, you?ve decided that the existing mechanism is the only way to do it.
>
>> However I suspect that you haven't got JEP 411 over the line yet and you are worried that open discussion of the issues it causes may stop it, because it impacts something you are trying to implement.   I apologize if this discussion inconveniences you, but it's still relevant and we should be looking at maintaining a version of Java that supports access control for a very long time, not 8 years.
> You have to convince the relevant maintainers, and this discussion does not inconveniences me because I?m just trying to
> see if there?s something we missed. The Security Manager does not harm the development of any one particular feature
> because new features have already largely overlooked it with few people even noticing. It does, however, take a
> significant toll on resources that could be put to better use elsewhere, including features that improve security in
> a more cost-effective way.
>
>> The only other alternatives is either a complete rewrite in another language, or forking Java, but neither seem viable.
> I don?t think this is the only other alternative at all, and repeating this claim is not something that, I think, will
> help delay this JEP. Evidence that thousands of companies rely on the Security Manager for security might, but short of
> that I think your time would be better spent on trying to suggest alternatives to some critical pieces that might be
> acceptable cost-wise.
>
>> I wouldn't recommend a new development that requires access control to consider using the Java platform at this time.
> OK.
>
>> I'm unable at this time to advise where people should look as I'm still in the investigation stage myself.   If someone does know of other platforms that do access control well, please inform me.
>>
> If by ?well? you mean the way that you currently do it and you?re not willing to even consider alternative approaches,
> I think you might be disappointed.
>
> ? Ron

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.



From ron.pressler at oracle.com  Tue May 18 00:13:42 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 18 May 2021 00:13:42 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
Message-ID: <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>

We can call any mechanism that might impose restrictions a mitigation, but that
doesn?t mean that any mechanism is worth its cost. I believe that the evidence
gathered over the past few decades shows that attempting to assign different 
permissions to code of different origin in the same process is not a particularly
effective way of increasing security compared to the alternatives, which is why
the only other mainstream platform to employ such a mechanism other than Java has
dropped it some years ago, and no other such platform has adopted it since.

I don?t think rearchitecting is required. What?s required is a reexamination of 
security-per-hour-effort gained by trying to assign different permissions to 
different code sources.

? Ron

> On 18 May 2021, at 01:02, David Black  wrote:
> 
> Hi Ron,
> 
> On Mon, 17 May 2021 at 21:38, Ron Pressler  wrote:
>> 
>> I would say that trying to mitigate attacks on vulnerabilities in trusted code based on specific code paths is
>> not recommended. You?re trying to preemptively defend agains something complex ? a security bug ? with
>> another complex mechanism. Even if you do happen to defend against a particular attack attempt due to a bug
>> that happens to be in the ?less trusted? code rather than in the more trusted code, the cost/benefit to this
>> approach is not very attractive, in my opinion.
> 
> That is your opinion and I will note that your reply didn't reference
> my references that noted that there are & have been bugs in libraries
> and java itself which make mitigating SSRF attacks difficult.
> With regards to mitigating SSRF "something complex", I'd argue that it
> isn't complex in itself but mitigating SSRF can be, with another
> complex mechanism - I will note that implementing the mechanism is
> rather simple so long as you are not using the built in java security
> manager.
> 
>> I think it is easier and simpler (and so more secure) to not differentiate codepaths in the same process, grant
>> whatever minimal privileges are required to the entire process with more watertight mechanisms than the SM,
>> and then actively monitor it ? say, with streaming JFR events, which will be made richer, and already do
>> expose the stack trace ? for suspicious activity. If a bug is found ? fix it.
> 
> I am not familiar with the Java Flight recorder but the documentation
> for it seems to suggest that it is only for diagnostic purposes.
> 
>> 
>> If your application clearly has more trusted/less exposed components and less trusted/less exposed ones,
>> and you feel that they must be separated for security reasons, consider running them in different processes.
>> Process isolation is a more secure, better studied, and better supported security mechanism than the Security Manager.
> 
> My reading of your proposed solution is that it requires
> re-architecting applications to ensure that any potential security
> issues occur inside of an isolated and monitored component/process.
> However, we do not get to pick where security issues can develop. It
> is true we can mitigate the risk of security issues by using isolated
> processes but I think you may have missed my main point which is
> effectively "something that lets us examine $X, e.g. a network
> connection, before the action is performed let's us at least partially
> mitigate security vulnerabilities and while it might be ideal to have
> software that contains 0 security vulnerabilities in it that often
> isn't realistic." From my prior email - "So having a "belt and
> braces", prox(y|ies) and a security manager, approach is valuable."
> Perhaps a different but I would argue more complex solution would be
> to use a java agent to rewrite java classes so as to be able to
> implement class based checks at run time or to have java provide event
> hooks where decisions can be made (but ... that sounds rather similar
> to the current situation with the security manager).
> 
> I would like to apologise for the system we use at my place of work
> messing with the email subject. But I would appreciate it if you
> didn't top post to reply to my email as you have left out some
> concerns such as that Java 8 seemingly is still affected by
> https://bugs.openjdk.java.net/browse/JDK-8161016.
> 
> 
>> ? Ron
>> 
>>> On 17 May 2021, at 03:11, David Black  wrote:
>>> 
>>> Hi Ron
>>> 
>>> On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 13 May 2021, at 03:11, David Black  wrote:
>>>>> 
>>>>> 
>>>>> This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
>>>> 
>>>> This is an important point we?re trying to get across. The very reason the Security Manager was made this
>>>> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
>>>> experience have shown us that *in practice* this is not the case, certainly not when you look at the
>>>> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
>>>> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
>>>> the job done, but actually use it incorrectly, providing the illusion of security without actual security.
>>> 
>>> Agreed, but if you don't have this level of introspection/detail how
>>> do you propose to, at least partially, mitigating bug classes such as
>>> SSRF?
>>> 
>>>>> Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://urldefense.com/v3/__https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager__;!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PHR4-37A$ ).
>>>> 
>>>> 
>>>> We?re talking about a situation where *all* the classes running in your application are trusted,
>>>> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
>>>> Can you explain why you believe this mechanism, that treats different classes differently is the best
>>>> way to improve security?
>>> 
>>> Because it allows for restrictions to be placed upon "trusted"[0]
>>> classes so as to offer some mitigation against classes of bugs such as
>>> SSRF. You can also use a security manager to monitor for potential
>>> policy implementation issues & make adjustments. Specifically for
>>> SSRF, if you want to mitigate the issue you need to ensure that
>>> network connections being made respect proxy settings but also allow
>>> support for certain code paths bypassing proxy settings to access
>>> potentially sensitive network locations (e.g. cloud metadata
>>> resources) this can result in mistakes in configuration occurring and
>>> or finding libraries/classes that ignore proxy configuration. You may
>>> be thinking "oh but surely no library/class would have proxy
>>> problems?" well that answer is "yes they can and do". For example,
>>> https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
>>> 9 but has not yet been fixed in java 8[2]. In a similar fashion,
>>> OkHttp before version 3.5.0 could also fallback back to a direct
>>> connection[3]. So having a "belt and braces", prox(y|ies) and a
>>> security manager, approach is valuable.
>>> 
>>> 
>>> [0] "Trusted" classes are not immune to security issues
>>> [1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
>>> [2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
>>> &  https://urldefense.com/v3/__https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java*L1180__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PCT2HmkQ$
>>> [3] https://urldefense.com/v3/__https://square.github.io/okhttp/changelog_3x/*version-350__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_OyQxtDiw$
>> 
> 
> 
> --
> David Black / Security Engineer.


From ron.pressler at oracle.com  Tue May 18 00:21:56 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 18 May 2021 00:21:56 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
References: 
 <119cd69e-3356-1d88-191f-e8d9ac071728@oracle.com>
 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
Message-ID: <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>



> On 18 May 2021, at 01:11, Peter Firmstone  wrote:
> 
> Your ideas are great in theory, in practice, the problem with your Agent proposal is every JVM release needs to be reviewed, and we have to review Java's internal implementation code, and understand it in order to instrument it.  

Absolutely. But that is exactly the work OpenJDK maintainers are required to do today to support something most 
people want better alternatives for at the expense of those better alternatives and other work.

> 
> Maybe if you put hooks (annotations?) into the JVM code, so it was easier for agents to know which calls need to be controlled for access decisions?   But then if not many people are using it, it will suffer neglect.

Yeah, it sounds neither here nor there, but the relevant maintainers will consider it.

> 
> It's your existing userbase with over 50% still using Java 8 that need convincing, who will be ultimate judge of the success or failure of this decision.

If you have data that contradicts our estimate of Security Manager usage among Java 8 users, please present it.

- Ron

From peter.firmstone at zeus.net.au  Tue May 18 02:39:44 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 18 May 2021 12:39:44 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
References: 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
Message-ID: <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>


On 18/05/2021 10:21 am, Ron Pressler wrote:
>
>> On 18 May 2021, at 01:11, Peter Firmstone  wrote:
>>
>> Your ideas are great in theory, in practice, the problem with your Agent proposal is every JVM release needs to be reviewed, and we have to review Java's internal implementation code, and understand it in order to instrument it.
> Absolutely. But that is exactly the work OpenJDK maintainers are required to do today to support something most
> people want better alternatives for at the expense of those better alternatives and other work.


Yes, I realize that, it is my understanding that because this is a 
security concern, it is not something the community is allowed to 
provide support for at OpenJDK, hence my suggestion to Alan, to make it 
possible for this to happen by changing the security level and calling 
it an access control layer concern.

Also is OpenJDK using static analysis to spot bugs?? Just out of 
curiosity, it's something we do for our code.

POLP isn't perfect, I acknowledge that, but it's much better than 
nothing as it does assist to limit damage in the event of an attack.? If 
this is the only issue, I'm sure the community will be willing to 
assist.?? It would be less work for me to maintain the existing 
implementation than try to re-implement this functionality in a 
relatively compatible way.?? I would review OpenJDK's permissions as 
well, given that I use doPrivileged and POLP regularly, it's probably 
going to be more obvious to me where bugs are,? I do see evidence of 
these bugs in my policy file generation, so I would be able to fix a 
number relatively quickly.

Unfortunately for us to put these proxy's into separate processes, in 
order to use OS level access control, we could have hundreds to 
thousands of processes running.? So it's not really an option.? We would 
still need to communicate with that process, so it's starting to make it 
difficult to manage secure connections etc.

ClassLoader's are so lightweight in comparison to a process.

Our RFC 3986 and RFC 5952 URI based ClassLoader is also so much faster 
than URLClassLoader, so it's not just security performance, I looked for 
hotspots and eliminated all of them.?? Where OpenJDK is doing dns 
network calls, we normalize ASCII strings.? It's AL2.0 licensed code 
refactored from Harmony, so I don't think it's an option for OpenJDK.

We'd like to avoid performance penalties as well, other options proposed 
have unknown performance costs, which may be significantly worse than 
current performant and scalable code. Remember our performance 
limitations are JVM native sockets, if you look at our hotspots, they're 
all JVM native methods.

While I admit that what we do with distributed software isn't commonly 
done in modern software, as most gave it up as too difficult years ago, 
we persisted and solved some very difficult problems.


>
>> Maybe if you put hooks (annotations?) into the JVM code, so it was easier for agents to know which calls need to be controlled for access decisions?   But then if not many people are using it, it will suffer neglect.
> Yeah, it sounds neither here nor there, but the relevant maintainers will consider it.


It may be the deciding factor for us, so I'd appreciate it if this can 
be considered.

Is it also possible to consider directing file access and network access 
through single points of access??? This will simplify the process so we 
don't need to scour the entire codebase for usages.

What about doPrivileged calls??? Will they remain in existing Java 
library code, so we can utilise them?? To avoid viral permission 
propagation?


>
>> It's your existing userbase with over 50% still using Java 8 that need convincing, who will be ultimate judge of the success or failure of this decision.
> If you have data that contradicts our estimate of Security Manager usage among Java 8 users, please present it.
>
> - Ron


I don't know what data you have, it's not something I've considered 
polling, if I find anything, I will most certainly share it.


-- 
Regards,
  
Peter Firmstone



From mbalao at openjdk.java.net  Tue May 18 02:59:49 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 18 May 2021 02:59:49 GMT
Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module
 from SunPKCS11's Secmod
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 May 2021 22:14:00 GMT, Valerie Peng  wrote:

>> Hi,
>> 
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>> 
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior.
>> 
>> No regressions observed in the jdk/sun/security/pkcs11 tests category.
>> 
>> A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11t.h line 105:
> 
>> 103: #define CKN_OTP_CHANGED         1UL
>> 104: 
>> 105: typedef CK_ULONG CK_PROFILE_ID;
> 
> There is already a typedef for CK_PROFILE_ID further down in this file.

oh, missed it. Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3661


From mbalao at openjdk.java.net  Tue May 18 03:03:41 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 18 May 2021 03:03:41 GMT
Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module
 from SunPKCS11's Secmod
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 May 2021 22:19:18 GMT, Valerie Peng  wrote:

>> Hi,
>> 
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>> 
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior.
>> 
>> No regressions observed in the jdk/sun/security/pkcs11 tests category.
>> 
>> A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/pkcs11t.h line 112:
> 
>> 110: #define NETSCAPE_SLOT_ID 1
>> 111: #define PRIVATE_KEY_SLOT_ID 2
>> 112: #define FIPS_SLOT_ID 3
> 
> These NSS specific defines is better off to be placed in a separate header file for ease of maintenance. In the past when PKCS#11 version is updated, we just drop the latest header files in and replace existing ones. Why not adding them to  to j2secmod.h or pkcs11wrapper.h?

Sure, moved to j2secmod.h

-------------

PR: https://git.openjdk.java.net/jdk/pull/3661


From mbalao at openjdk.java.net  Tue May 18 03:11:50 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 18 May 2021 03:11:50 GMT
Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module
 from SunPKCS11's Secmod
In-Reply-To: 
References: 
 
Message-ID: <5g6GO3_VWrSFTwzU_Oz7FLcu3QjZEdyQqA4nPuLDUHU=.6dc91474-4e0f-48a6-a417-c58ea18eecd3@github.com>

On Tue, 4 May 2021 22:24:36 GMT, Valerie Peng  wrote:

>> Hi,
>> 
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>> 
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior.
>> 
>> No regressions observed in the jdk/sun/security/pkcs11 tests category.
>> 
>> A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java line 81:
> 
>> 79: 
>> 80:     private final static int FIPS_SLOT_ID = 0x3;
>> 81: 
> 
> Add a comment on where these are defined in native side, i.e. which sunpkcs11 header file as well as the NSS header just in case?

Good, will add references to both

> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Secmod.java line 415:
> 
>> 413:                 } else {
>> 414:                     throw new RuntimeException("Unexpected slot ID in the" +
>> 415:                             " NSS Internal Module");
> 
> Add the slot ID to the exception message?

Good idea

-------------

PR: https://git.openjdk.java.net/jdk/pull/3661


From ascarpino at openjdk.java.net  Tue May 18 03:18:18 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 18 May 2021 03:18:18 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
> 
> Thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4072/files
  - new: https://git.openjdk.java.net/jdk/pull/4072/files/b21c2723..4a2e35c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=01-02

  Stats: 276 lines in 1 file changed: 123 ins; 150 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072

PR: https://git.openjdk.java.net/jdk/pull/4072


From mbalao at openjdk.java.net  Tue May 18 03:20:53 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 18 May 2021 03:20:53 GMT
Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module
 from SunPKCS11's Secmod
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 May 2021 23:25:16 GMT, Valerie Peng  wrote:

>> Hi,
>> 
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>> 
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior.
>> 
>> No regressions observed in the jdk/sun/security/pkcs11 tests category.
>> 
>> A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462
>
> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h line 78:
> 
>> 76: 
>> 77: /* represent a pkcs#11 slot reference counted. */
>> 78: struct PK11SlotInfoStr {
> 
> nit: add which nss header this is from.

Good

> src/jdk.crypto.cryptoki/share/native/libj2pkcs11/j2secmod.h line 166:
> 
>> 164: };
>> 165: 
>> 166: struct SECMODModuleStr {
> 
> Same nit: add which nss header this is from.

Good. Done for every structure there

-------------

PR: https://git.openjdk.java.net/jdk/pull/3661


From mbalao at openjdk.java.net  Tue May 18 04:03:16 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 18 May 2021 04:03:16 GMT
Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module
 from SunPKCS11's Secmod [v2]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Please find in this PR a proposal to fix JDK-8265462 [1].
> 
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior.
> 
> No regressions observed in the jdk/sun/security/pkcs11 tests category.
> 
> A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  Documentation improvements and minor reordering

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3661/files
  - new: https://git.openjdk.java.net/jdk/pull/3661/files/ae8b2d18..c83c98d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3661&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3661&range=00-01

  Stats: 20 lines in 3 files changed: 13 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3661.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3661/head:pull/3661

PR: https://git.openjdk.java.net/jdk/pull/3661


From mbalao at openjdk.java.net  Tue May 18 04:03:18 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 18 May 2021 04:03:18 GMT
Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module
 from SunPKCS11's Secmod [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 4 May 2021 23:26:34 GMT, Valerie Peng  wrote:

>> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Documentation improvements and minor reordering
>
> Here are some comments. Rest looks fine. Thanks. Valerie

@valeriepeng can you please take one more look at the changes?

No regressions found in jdk/sun/security/pkcs11 tests category.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3661


From dholmes at openjdk.java.net  Tue May 18 05:01:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 18 May 2021 05:01:46 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Changes to hotspot-* and serviceability look good.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071


From alanb at openjdk.java.net  Tue May 18 05:51:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 05:51:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Marked as reviewed by alanb (Reviewer).

The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.

test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.

test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.

For uses using ProcessTools then it seems to be very random.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071


From Alan.Bateman at oracle.com  Tue May 18 06:10:13 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 18 May 2021 07:10:13 +0100
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
References: 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
Message-ID: <8ed6cb5d-86b8-d11c-3d34-1d62011c30ce@oracle.com>

On 18/05/2021 03:39, Peter Firmstone wrote:
> :
>
>
> Yes, I realize that, it is my understanding that because this is a 
> security concern, it is not something the community is allowed to 
> provide support for at OpenJDK, hence my suggestion to Alan, to make 
> it possible for this to happen by changing the security level and 
> calling it an access control layer concern.
>
Sorry, I was too busy and didn't have time to reply to your previous 
mail on this and the performance anomaly in Java 14.

I'm dubious about your suggestion. Every issue or report that Java has a 
security bug has to be analyzed on the assumption that it may be a 
vulnerability. Saying that SM bypass or a ninja move that disables the 
SM is not a security concern would create a perception issue. It would 
get lost in the discussion that the SM is rarely used in the way that it 
was envisaged 20+ years ago. The other thing is that it wouldn't remove 
the ongoing burden to insert/audit permission checks, check that ACC are 
captured and used in the right places, and of course testing as it's 
another execution mode.

-Alan.


From dblack at atlassian.com  Tue May 18 06:10:25 2021
From: dblack at atlassian.com (David Black)
Date: Tue, 18 May 2021 16:10:25 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>
References: 
 <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>
Message-ID: 

Hi,

On Tue, 18 May 2021 at 10:13, Ron Pressler  wrote:
>
> We can call any mechanism that might impose restrictions a mitigation, but that
> doesn?t mean that any mechanism is worth its cost. I believe that the evidence
> gathered over the past few decades shows that attempting to assign different
> permissions to code of different origin in the same process is not a particularly
> effective way of increasing security compared to the alternatives, which is why
> the only other mainstream platform to employ such a mechanism other than Java has
> dropped it some years ago, and no other such platform has adopted it since.

I hope you aren't being rude on purpose by continuing to 1) top post
and 2) not ignore various parts of my emails.
To be clear, what I have written is partially answered by some of your
other emails which you talk about using a java agent and or hooks
which I mentioned in my previous email (& to say it again ... hooks
seem like they would be similar to a security manager).

> I don?t think rearchitecting is required. What?s required is a reexamination of
> security-per-hour-effort gained by trying to assign different permissions to
> different code sources.

I am not trying to be rude but I would like to ask what is more expensive -
1) auditing 1,000,000 lines of code - with active development on going
2) re-architecting an application so that the main process ?cannot?
make new connections after a certain point (preventing new FDs from
being opened) & making external connections from another process which
has operating/configuration/other restrictions on it to prevent it
from talking with sensitive network locations
3) examining all known locations using a security manager in a
non-enforcing mode or as you noted - the Java Flight recorder & fixing
all known currently existing locations
4) ^ 3 but you use a security manager or something that lets you make
decisions about connections/$things such that you can block in
addition to monitor things

Let's say you want to do 1 - you likely will not be able to keep up
with active development regardless of cost and humans make mistakes.
Let's say you want to do 2 - we are talking about re-architecting a
sizable application - it might not be possible to shift to your
suggested split model and it also imposes a relatively high barrier to
entry/additional complexity (e.g. additional monitoring) as well.
Let's say you want to do 3 - this works but it doesn't do anything to
help with changes to code changes, libraries, and java itself.
Let's say you want to do 4 - this works but it won't be 100% secure,
what if the class you permit somehow ends up in all call stacks/at the
"allowed" location, we get the benefits of 3 but with some additional
protection.

Real world software security experience -^ will likely push security
engineers towards 4 depending upon performance impacts etc.

If we end up with hooks in places which allow us to make decisions but
don't try to protect against tearing down/removing a "security
manager" & the hooks are easier to use than the existing security
manager, that sounds workable to me (not desirable but workable). (I
could go on and rant about about how oracle made changes that mean
that if you try to use a custom security manager in java 11 without
referencing internal java classes you have a performance penalty - or
how there are security related applet & other hangovers that hinder
the use of the security manager in java applications).


>
> > On 18 May 2021, at 01:02, David Black  wrote:
> >
> > Hi Ron,
> >
> > On Mon, 17 May 2021 at 21:38, Ron Pressler  wrote:
> >>
> >> I would say that trying to mitigate attacks on vulnerabilities in trusted code based on specific code paths is
> >> not recommended. You?re trying to preemptively defend agains something complex ? a security bug ? with
> >> another complex mechanism. Even if you do happen to defend against a particular attack attempt due to a bug
> >> that happens to be in the ?less trusted? code rather than in the more trusted code, the cost/benefit to this
> >> approach is not very attractive, in my opinion.
> >
> > That is your opinion and I will note that your reply didn't reference
> > my references that noted that there are & have been bugs in libraries
> > and java itself which make mitigating SSRF attacks difficult.
> > With regards to mitigating SSRF "something complex", I'd argue that it
> > isn't complex in itself but mitigating SSRF can be, with another
> > complex mechanism - I will note that implementing the mechanism is
> > rather simple so long as you are not using the built in java security
> > manager.
> >
> >> I think it is easier and simpler (and so more secure) to not differentiate codepaths in the same process, grant
> >> whatever minimal privileges are required to the entire process with more watertight mechanisms than the SM,
> >> and then actively monitor it ? say, with streaming JFR events, which will be made richer, and already do
> >> expose the stack trace ? for suspicious activity. If a bug is found ? fix it.
> >
> > I am not familiar with the Java Flight recorder but the documentation
> > for it seems to suggest that it is only for diagnostic purposes.
> >
> >>
> >> If your application clearly has more trusted/less exposed components and less trusted/less exposed ones,
> >> and you feel that they must be separated for security reasons, consider running them in different processes.
> >> Process isolation is a more secure, better studied, and better supported security mechanism than the Security Manager.
> >
> > My reading of your proposed solution is that it requires
> > re-architecting applications to ensure that any potential security
> > issues occur inside of an isolated and monitored component/process.
> > However, we do not get to pick where security issues can develop. It
> > is true we can mitigate the risk of security issues by using isolated
> > processes but I think you may have missed my main point which is
> > effectively "something that lets us examine $X, e.g. a network
> > connection, before the action is performed let's us at least partially
> > mitigate security vulnerabilities and while it might be ideal to have
> > software that contains 0 security vulnerabilities in it that often
> > isn't realistic." From my prior email - "So having a "belt and
> > braces", prox(y|ies) and a security manager, approach is valuable."
> > Perhaps a different but I would argue more complex solution would be
> > to use a java agent to rewrite java classes so as to be able to
> > implement class based checks at run time or to have java provide event
> > hooks where decisions can be made (but ... that sounds rather similar
> > to the current situation with the security manager).
> >
> > I would like to apologise for the system we use at my place of work
> > messing with the email subject. But I would appreciate it if you
> > didn't top post to reply to my email as you have left out some
> > concerns such as that Java 8 seemingly is still affected by
> > https://bugs.openjdk.java.net/browse/JDK-8161016.
> >
> >
> >> ? Ron
> >>
> >>> On 17 May 2021, at 03:11, David Black  wrote:
> >>>
> >>> Hi Ron
> >>>
> >>> On Thu, 13 May 2021 at 20:22, Ron Pressler  wrote:
> >>>>
> >>>>
> >>>>
> >>>>> On 13 May 2021, at 03:11, David Black  wrote:
> >>>>>
> >>>>>
> >>>>> This seems somewhat more useful than 1 & 2 but imho it would be better to be able to perform checks/grant access on a call stack basis.
> >>>>
> >>>> This is an important point we?re trying to get across. The very reason the Security Manager was made this
> >>>> way is because it does *seem* better; certainly it is much more flexible. However, twenty five years of
> >>>> experience have shown us that *in practice* this is not the case, certainly not when you look at the
> >>>> ecosystem as a whole. It is hard to get right, which results in people not using the mechanism (which
> >>>> significantly reduces its utility and the value in maintaining it), or worse, use it and think it gets
> >>>> the job done, but actually use it incorrectly, providing the illusion of security without actual security.
> >>>
> >>> Agreed, but if you don't have this level of introspection/detail how
> >>> do you propose to, at least partially, mitigating bug classes such as
> >>> SSRF?
> >>>
> >>>>> Atlassian currently makes use of a security manager to prevent access to cloud metadata services that do not have an amazon sdk related class on the call stack. This helps to mitigate the impact of SSRF in applications running in a cloud environment (https://urldefense.com/v3/__https://github.com/asecurityteam/ssrf-protection-example-manas-security-manager__;!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PHR4-37A$ ).
> >>>>
> >>>>
> >>>> We?re talking about a situation where *all* the classes running in your application are trusted,
> >>>> i.e. assumed to not be malicious, and that an accidental vulnerability might exist in any one of them.
> >>>> Can you explain why you believe this mechanism, that treats different classes differently is the best
> >>>> way to improve security?
> >>>
> >>> Because it allows for restrictions to be placed upon "trusted"[0]
> >>> classes so as to offer some mitigation against classes of bugs such as
> >>> SSRF. You can also use a security manager to monitor for potential
> >>> policy implementation issues & make adjustments. Specifically for
> >>> SSRF, if you want to mitigate the issue you need to ensure that
> >>> network connections being made respect proxy settings but also allow
> >>> support for certain code paths bypassing proxy settings to access
> >>> potentially sensitive network locations (e.g. cloud metadata
> >>> resources) this can result in mistakes in configuration occurring and
> >>> or finding libraries/classes that ignore proxy configuration. You may
> >>> be thinking "oh but surely no library/class would have proxy
> >>> problems?" well that answer is "yes they can and do". For example,
> >>> https://bugs.openjdk.java.net/browse/JDK-8161016[1] was fixed in java
> >>> 9 but has not yet been fixed in java 8[2]. In a similar fashion,
> >>> OkHttp before version 3.5.0 could also fallback back to a direct
> >>> connection[3]. So having a "belt and braces", prox(y|ies) and a
> >>> security manager, approach is valuable.
> >>>
> >>>
> >>> [0] "Trusted" classes are not immune to security issues
> >>> [1] https://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/3dc9d5deab5d
> >>> [2]https://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/0056610eefad/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java#l1180
> >>> &  https://urldefense.com/v3/__https://github.com/AdoptOpenJDK/openjdk-jdk8u/blob/master/jdk/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java*L1180__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_PCT2HmkQ$
> >>> [3] https://urldefense.com/v3/__https://square.github.io/okhttp/changelog_3x/*version-350__;Iw!!GqivPVa7Brio!IyJmrzRjucwPoKg96_YX9o_oR9CWp1zWRELtDpWvfKRtM8jcx7ZJI9Phg_OyQxtDiw$
> >>
> >
> >
> > --
> > David Black / Security Engineer.
>


-- 
David Black / Security Engineer.


From alanb at openjdk.java.net  Tue May 18 06:33:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 06:33:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

src/java.base/share/classes/java/lang/SecurityManager.java line 315:

> 313:  *
> 314:  * @since   1.0
> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a

Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From peter.firmstone at zeus.net.au  Tue May 18 07:36:59 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 18 May 2021 17:36:59 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <8ed6cb5d-86b8-d11c-3d34-1d62011c30ce@oracle.com>
References: 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <8ed6cb5d-86b8-d11c-3d34-1d62011c30ce@oracle.com>
Message-ID: <4b8cfbe3-a4c3-b44c-74b5-c8f8870823d4@zeus.net.au>


On 18/05/2021 4:10 pm, Alan Bateman wrote:
> On 18/05/2021 03:39, Peter Firmstone wrote:
>> :
>>
>>
>> Yes, I realize that, it is my understanding that because this is a 
>> security concern, it is not something the community is allowed to 
>> provide support for at OpenJDK, hence my suggestion to Alan, to make 
>> it possible for this to happen by changing the security level and 
>> calling it an access control layer concern.
>>
> Sorry, I was too busy and didn't have time to reply to your previous 
> mail on this and the performance anomaly in Java 14.
>
> I'm dubious about your suggestion. Every issue or report that Java has 
> a security bug has to be analyzed on the assumption that it may be a 
> vulnerability. Saying that SM bypass or a ninja move that disables the 
> SM is not a security concern would create a perception issue. It would 
> get lost in the discussion that the SM is rarely used in the way that 
> it was envisaged 20+ years ago. The other thing is that it wouldn't 
> remove the ongoing burden to insert/audit permission checks, check 
> that ACC are captured and used in the right places, and of course 
> testing as it's another execution mode.
>
> -Alan.


Thanks Alan,

It's a perception issue, I understand, but we can fix that far less 
painfully.

You could create a new parent class of SecurityManager that's more aptly 
named, for example AccessAssistant, and deprecate SecurityManager for 
removal.

That's actually pretty easy, even backport the new class to earlier 
versions of Java, so libraries can eliminate usages of SecurityManager 
sooner.

This would give us time to change our dependencies to the superclass, 
and it eliminates the name perception issue.

"AccessAssistant, is only intended to assist with access control 
measures to implement the principle of least privilege, while it may 
reduce the impact of a security breach, it's not capable of preventing 
it, therefore bugs in access decisions aren't given the same attention 
as security bugs, as both users and code are trusted."

AccessController and AccessControlContext have functionality that we 
depend on for access control and to obtain user credentials for 
authentication.

Let the community manage it as an access control layer, when we find the 
ACC has forgotten to be captured, we can fix it.?? When someone forgets 
to capture the ACC, the thread cannot establish a secure connection, it 
will get noticed and fixed, it alone cannot cause a security breach.

We use TLS connections, sanitize data, atomic failure, input validation 
and authentication for security, we only use access controls and Policy 
for limiting access of trusted users and code and to obtain user 
credentials.?? Access control and POLP gets those boxes ticked and might 
be the difference for choosing Java over another platform.

If people aren't defensively parsing their input, not using secure 
connections and authentication and someone takes advantage of that, well 
it's just too bad, it's their fault.

If someone is using trusted connections but there's a successful 
phishing attack on user credentials, then the attacker can usually only 
obtain what the user has access to, yes it is possible to perform a 
privilege escalation attack, but the point is the breach has already 
occurred, the security vulnerability is not access controls, it was the 
authentication system failure.

Don't stress the performance anomaly, it hasn't regressed in later 
versions and the standard Java Policy provider will mask it.?? You'll 
only notice it when using a scalable policy provider.? If I see it again 
in any long term releases, I'll let you know.?? I suspect whatever 
caused the problem was spotted and fixed already.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.



From Alan.Bateman at oracle.com  Tue May 18 09:13:58 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 18 May 2021 10:13:58 +0100
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <4b8cfbe3-a4c3-b44c-74b5-c8f8870823d4@zeus.net.au>
References: 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <8ed6cb5d-86b8-d11c-3d34-1d62011c30ce@oracle.com>
 <4b8cfbe3-a4c3-b44c-74b5-c8f8870823d4@zeus.net.au>
Message-ID: <676f2401-dc64-e9dd-8fb5-52a1ee6daf1f@oracle.com>



On 18/05/2021 08:36, Peter Firmstone wrote:
> :
>
> It's a perception issue, I understand, but we can fix that far less 
> painfully.

With respect, I don't see a viable route here. SM/AccessController and 
most of that security architecture has been an albatross around our 
necks for years. This JEP is the first step in pulling the JDK out of 
the sandboxing and policy enforcement business. It will take several 
releases and years to get there. Yes, it will be painful for those that 
have embraced this architecture but there will be years of supported 
releases to plan or develop alternatives. There is a wider group that 
have been using the SM as a means to intercept network, file and several 
other operations. This is an area that might need to be exploded further 
to see if an alternative solution is imported for the JDK to provider. 
We don't think that this needs to be fully explored and decided on 
before making progress on the deprecation.

-Alan


From peter.firmstone at zeus.net.au  Tue May 18 09:46:14 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 18 May 2021 19:46:14 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <676f2401-dc64-e9dd-8fb5-52a1ee6daf1f@oracle.com>
References: 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <8ed6cb5d-86b8-d11c-3d34-1d62011c30ce@oracle.com>
 <4b8cfbe3-a4c3-b44c-74b5-c8f8870823d4@zeus.net.au>
 <676f2401-dc64-e9dd-8fb5-52a1ee6daf1f@oracle.com>
Message-ID: 

Because people have been treating it like a sandbox.

Since it will take a number of years, can we at least consider my 
proposal and give it a try?? It may reduce the burden in the interim.

So this step deprecates it for removal, can we create a JEP for 
replacing the SecurityManager with AccessAssistant while retaining 
AccessController and AccessControlContext?

It's also true that Permisssion's are more numerous than necessary, 
because it has been treated like a sandbox.

If we rename and treat it like access control instead, we can reduce the 
burden, simplify permissions, provide tooling and make it much better 
than it is today.

We've been doing exactly that for years, and we knew the Java PolicyFile 
code was bad, but we never realised that JDK developers saw it in this 
light.

If I had realised that , I would have stepped in years ago to fix it. 
Maybe we got complacent because nothing was ever removed from Java for a 
very long time.

We've been using it silently and efficiently for years.

Regards,

Peter.


On 18/05/2021 7:13 pm, Alan Bateman wrote:
>
>
> On 18/05/2021 08:36, Peter Firmstone wrote:
>> :
>>
>> It's a perception issue, I understand, but we can fix that far less 
>> painfully.
>
> With respect, I don't see a viable route here. SM/AccessController and 
> most of that security architecture has been an albatross around our 
> necks for years. This JEP is the first step in pulling the JDK out of 
> the sandboxing and policy enforcement business. It will take several 
> releases and years to get there. Yes, it will be painful for those 
> that have embraced this architecture but there will be years of 
> supported releases to plan or develop alternatives. There is a wider 
> group that have been using the SM as a means to intercept network, 
> file and several other operations. This is an area that might need to 
> be exploded further to see if an alternative solution is imported for 
> the JDK to provider. We don't think that this needs to be fully 
> explored and decided on before making progress on the deprecation.
>
> -Alan

-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.



From mcimadamore at openjdk.java.net  Tue May 18 10:20:41 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 18 May 2021 10:20:41 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v22]
In-Reply-To: 
References: 
Message-ID: 

> 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 two additional commits since the last revision:

 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/9eb61a46..f6051daf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=20-21

  Stats: 32 lines in 1 file changed: 26 ins; 1 del; 5 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


From pconcannon at openjdk.java.net  Tue May 18 10:43:52 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 18 May 2021 10:43:52 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
Message-ID: 

Hi,

Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?

Kind regards,
Patrick

-------------

Commit messages:
 - 8267110: Update java.util to use instanceof pattern variable

Changes: https://git.openjdk.java.net/jdk/pull/4088/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267110
  Stats: 304 lines in 35 files changed: 1 ins; 144 del; 159 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088

PR: https://git.openjdk.java.net/jdk/pull/4088


From ron.pressler at oracle.com  Tue May 18 10:49:27 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 18 May 2021 10:49:27 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
References: 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
Message-ID: <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>



> On 18 May 2021, at 03:39, Peter Firmstone  wrote:
> 
> 
> Is it also possible to consider directing file access and network access through single points of access?   This will simplify the process so we don't need to scour the entire codebase for usages.
> 

Of all your suggestions, I think this is the one that will be seriously considered from a cost/benefit
perspective, although probably not as part of this JEP.

> What about doPrivileged calls?   Will they remain in existing Java library code, so we can utilise them?  To avoid viral permission propagation?

Doubtful. That is where much of the cost is, and it would mean investing significant resources into supporting
a use-case that what seems like the vast majority of security experts think is a wrong-headed approach, for the sake 
of the few who disagree. Even as an additional mechanism that might, maybe, block exploiting some vulnerability as a 
result of some particular bug in some cases, sometimes, maybe, the high cost doesn?t justify what we believe is the 
extra defence gained compared to the gain of such an effort directed elsewhere.

? Ron

From lancea at openjdk.java.net  Tue May 18 11:13:40 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 18 May 2021 11:13:40 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Changes look good.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4088


From peter.firmstone at zeus.net.au  Tue May 18 11:27:20 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Tue, 18 May 2021 21:27:20 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
References: 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
Message-ID: 


On 18/05/2021 8:49 pm, Ron Pressler wrote:
>
>> On 18 May 2021, at 03:39, Peter Firmstone  wrote:
>>
>>
>> Is it also possible to consider directing file access and network access through single points of access?   This will simplify the process so we don't need to scour the entire codebase for usages.
>>
> Of all your suggestions, I think this is the one that will be seriously considered from a cost/benefit
> perspective, although probably not as part of this JEP.


Thank you ,appreciated.


>
>> What about doPrivileged calls?   Will they remain in existing Java library code, so we can utilise them?  To avoid viral permission propagation?
> Doubtful. That is where much of the cost is, and it would mean investing significant resources into supporting
> a use-case that what seems like the vast majority of security experts think is a wrong-headed approach, for the sake
> of the few who disagree. Even as an additional mechanism that might, maybe, block exploiting some vulnerability as a
> result of some particular bug in some cases, sometimes, maybe, the high cost doesn?t justify what we believe is the
> extra defence gained compared to the gain of such an effort directed elsewhere.
>
> ? Ron

Oh well, there was no harm in asking.

I agree that sandboxing is the wrong approach, it's unfortunate that 
this wasn't seen as a potential issue in the early days. It's similar 
with Java Serialization, if they tried to do less initially it would 
have been much better, but they pushed to envelope too far.

But I'm pretty sure we've moved on from discussing sandboxes, no one is 
claiming that as their use case.

However I disagree that the Principle of least privilege is wrong 
headed, I think you've been discussing sandbox concepts with the experts 
and they're going to tell you that's a bad idea.? But the two aren't the 
same, one is access control, the other is attempted complete leak proof 
isolation,? which is a very difficult thing to do that grows 
exponentially with your API surface area, I'm sure in years to come 
crackers will find vulnerabilities in VM's too. Sandboxing would work if 
you removed most of the library code and features and limited memory and 
threads, but I don't think anyone is seriously considering that.? Java 
for applets should have been it's own stripped down limited JVM.

Our problem is we will need to grant remote third party's AllPermission 
because they are not represented as a Subject based ProtectionDomain in 
the JVM, but then we could implement some sort of analysis that removes 
their ability to connect at all if they violate policy.

But this doesn't seem very workable.? Thankfully we have a very good, 
functional and highly scalable solution available now.

What sort of cost, you mean development cost, the cost of understanding 
doPrivileged?

At least to me, it's just a simple lambda expression, it's not 
difficult.? It think people are making this more complex than it needs 
to be due to a proliferation of Permissions, but even that I manage with 
tooling.

AccessController.doPrivileged uses 1.3% of CPU time in my system, and 
I'm sure I use it far more than many, so I don't think your talking 
about performance.

Thankfully access control is much simpler today than say programming 
concurrently, but I try to do both well.?? I truly don't find it 
difficult to use, but then I've built a bunch of tools that make it useable.

But I get that JVM developers have suffered a lot of pain with Security 
vulnerabilities due to Java Serialization and the Sandbox and just the 
mention of SecurityManager is received negatively.

But it's such a shame to lose access control as collateral damage.

Thanks again for spending the time to discuss.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.



From dfuchs at openjdk.java.net  Tue May 18 11:33:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 18 May 2021 11:33:44 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas. Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I looked at serviceability, net, and corelibs. The changes look good to me - though I have one question about the NotificationEmissionTest. I believe that regardless of whether the new property is needed, test case 1 should be run in /othervm too.

test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:

> 32:  * @run clean NotificationEmissionTest
> 33:  * @run build NotificationEmissionTest
> 34:  * @run main NotificationEmissionTest 1

This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071


From alanb at openjdk.java.net  Tue May 18 12:05:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 12:05:38 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

You may need to coordinate with @DougLea on the changes to j.u.concurrent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4088


From ron.pressler at oracle.com  Tue May 18 12:09:01 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 18 May 2021 12:09:01 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
Message-ID: 



> On 18 May 2021, at 12:27, Peter Firmstone  wrote:
> 
> 
> However I disagree that the Principle of least privilege is wrong headed, I think you've been discussing sandbox concepts with the experts and they're going to tell you that's a bad idea.  But the two aren't the same, one is access control, the other is attempted complete leak proof isolation,  which is a very difficult thing to do that grows exponentially with your API surface area, I'm sure in years to come crackers will find vulnerabilities in VM's too. Sandboxing would work if you removed most of the library code and features and limited memory and threads, but I don't think anyone is seriously considering that.  Java for applets should have been it's own stripped down limited JVM.

When you say the ?principle of least privilege? you seem to imply that it is at *all* cost. Many believe that
the attempt to assign different privileges to different *pieces of code* (not different people) is not effective
from a cost/benefit perspective. In other words, the effort would have a bigger impact on security if directed
elsewhere. After all, the same principle would imply that we?d need to afford different permissions at a method
granularity rather than class granularity.

> 
> What sort of cost, you mean development cost, the cost of understanding doPrivileged?

Both, but mostly the former.

> 
> At least to me, it's just a simple lambda expression, it's not difficult.  It think people are making this more complex than it needs to be due to a proliferation of Permissions, but even that I manage with tooling.

There?s no point to argue over this. It?s been tried for a couple of decades, people don?t want it, experts say it?s 
not cost-effective, no popular platform after Java and .NET has chosen to invest in it, and .NET has dropped it already.
Even if you convinced me that the effort of attempting to afford different permissions to different code in the same 
process was an effective use of resources, if you could have changed the habits of millions of developers you would 
have done it by now. You can carry on the argument over whether this is a good or bad idea on security forums and at 
security conferences, but that it didn?t pan out, adoption-wise, in practice is an empirical fact (that it's worked 
great *for you* is completely irrelevant). Even good ideas can fail to gain traction, and we shouldn?t throw good money 
after bad.

> 
> But it's such a shame to lose access control as collateral damage.

Most applications that do access control today do not use the Security Manager for that. When you say ?access control? 
you mean something very specific, which is not what others mean when they say access control. In particular, even doAs 
is proposed to remain.


? Ron

From ron.pressler at oracle.com  Tue May 18 12:24:18 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Tue, 18 May 2021 12:24:18 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>
 
Message-ID: <25B49E78-4DA7-47F6-B01F-0093582B274E@oracle.com>


> On 18 May 2021, at 07:10, David Black  wrote:
> 
> 
> I hope you aren't being rude on purpose by continuing to 1) top post
> and 2) not ignore various parts of my emails.
> 

This isn?t a debate forum. We?re trying to collect information, not 
to convince every last person. I respond to what I think I can comment 
on.

> 
> I am not trying to be rude but I would like to ask what is more expensive -
> 1) auditing 1,000,000 lines of code - with active development on going
> 2) re-architecting an application so that the main process ?cannot?
> make new connections after a certain point (preventing new FDs from
> being opened) & making external connections from another process which
> has operating/configuration/other restrictions on it to prevent it
> from talking with sensitive network locations
> 3) examining all known locations using a security manager in a
> non-enforcing mode or as you noted - the Java Flight recorder & fixing
> all known currently existing locations
> 4) ^ 3 but you use a security manager or something that lets you make
> decisions about connections/$things such that you can block in
> addition to monitor things


I happen to think that the most cost-effective thing would be to assign
the entire trusted process the minimal permissions it requires, to monitor 
it for suspicious activity with JFR, and to invest the effort required to
maintain the Security Manager in security measures that most people might
actually use. Is that 3? The question of whether or not it?s worth it to go
from 3 to 4 depends on the added cost vs the added benefit, compared to all
other options. I happen to think it?s not worth it, but the relevant 
maintainers might well consider some inexpensive building blocks for those 
who think differently, and wish to construct a code-origin based permission 
system.

? Ron



From dl at openjdk.java.net  Tue May 18 12:23:43 2021
From: dl at openjdk.java.net (Doug Lea)
Date: Tue, 18 May 2021 12:23:43 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Because we still make jdk11-compatible test-release java.util.concurrent jars, we are not big fans of adding non-essential differences to openjdk version. But if there is some advantage to doing this, we'll cope.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4088


From mullan at openjdk.java.net  Tue May 18 12:44:48 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 12:44:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Tue, 18 May 2021 06:31:06 GMT, Alan Bateman  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
> 
>> 313:  *
>> 314:  * @since   1.0
>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
> 
> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?

It includes both:
![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From fguallini at openjdk.java.net  Tue May 18 13:37:58 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Tue, 18 May 2021 13:37:58 GMT
Subject: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain java
 tests and fix failures
Message-ID: 

Refactor the following shell tests to Java:
- security/pkcs11/KeyStore/Basic.sh
- security/pkcs11/KeyStore/ClientAuth.sh
- security/pkcs11/KeyStore/SecretKeysBasic.sh
- security/pkcs11/Provider/ConfigQuotedString.sh
- security/pkcs11/Provider/Login.sh
- security/pkcs11/Config/ReadConfInUTF16Env.sh

Currently, most of the shell tests in the list may be ignored during execution time in most platforms since they are incorrectly filtered out by the OS name they are run on. For example, ClientAuth.sh is only run if the OS name is equal to ?Linux?, but OS name may also include the architecture such as ?Linux x86_64?. Those platform constraints are removed in this PR.

Additionally, further changes are introduced in the following test:

- ClientAuth: it was failing intermittently because the server side was binding to the wildcard address. The issue is fixed by binding to loopback address instead. Also, Thread.sleep is replaced with CountdownLatch to facilitate synchronization between client and server. Finally, a new ?user1? certificate was generated since the current one has expired.

- Basic: Remove redundant X509Certificate casting 

- SecretKeysBasic: it was already in the problem list since it reproduces the open bug JDK-8209398 and fails. Test is refactored to java and still reproduces the issue.

All the mentioned tests were run many times in multiple platforms to ensure stability

-------------

Commit messages:
 - removed tab in comment
 - Merge branch 'master' into 8180571
 - fixed summary in ClientAuth
 - refactor tests
 - refactored shell tests to java

Changes: https://git.openjdk.java.net/jdk/pull/4092/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4092&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8180571
  Stats: 1075 lines in 18 files changed: 195 ins; 819 del; 61 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4092.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4092/head:pull/4092

PR: https://git.openjdk.java.net/jdk/pull/4092


From weijun at openjdk.java.net  Tue May 18 14:01:41 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:01:41 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 11:12:00 GMT, Daniel Fuchs  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java line 34:
> 
>> 32:  * @run clean NotificationEmissionTest
>> 33:  * @run build NotificationEmissionTest
>> 34:  * @run main NotificationEmissionTest 1
> 
> This test case (NotificationEmissionTest 1) calls `System.setProperty("java.security.policy", policyFile);` - even though it doesn't call System.setSecurityManager(); Should the @run command line for test case 1 be modified as well?

Or maybe the policy setting line should only be called when a security manager is set? IIRC jtreg is able to restore system properties even in agentvm mode. So maybe this really doesn't matter. We just want to modify as little as possible in this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071


From weijun at openjdk.java.net  Tue May 18 14:07:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 14:07:38 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 05:48:56 GMT, Alan Bateman  wrote:

> The changes look okay but a bit inconsistent on where -Djava...=allow is inserted for tests that already set other system properties or other parameters. Not a correctness issue, just looks odd in several places, e.g.
> 
> test/jdk/java/lang/System/LoggerFinder/BaseLoggerFinderTest/BaseLoggerFinderTest.java - the tests sets the system properties after -Xbootclasspath/a: but the change means it sets properties before and after.
> 
> test/jdk/java/lang/Class/getResource/ResourcesTest.java - you've added it in the middle of the module and class path parameters.
> 
> For uses using ProcessTools then it seems to be very random.

I've updated the 3 cases you mentioned and will go through more. Yes it looks good to group system property settings together. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071


From martin.doerr at sap.com  Tue May 18 15:02:35 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Tue, 18 May 2021 15:02:35 +0000
Subject: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with
 "java.security.InvalidAlgorithmParameterException: Salt must be 8
 bytes long"
Message-ID: 

Hi,

JDK-8266293 is backported to 11.0.12-oracle. The included test shows that the fix is required in 11u.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8266293

Original change:
https://git.openjdk.java.net/jdk/commit/04f71126479f9c39aa71e8aebe7196d72fc16796

It applies almost cleanly. Only the bug id addition in the test had to get done manually.

However, the new code needs an adaptation because JDK11u doesn't contain KnownOIDs.
One of the original author?s comments says:
"Backporters might need to check case-insensitive equality to both "PBEWithMD5AndDES" and "1.2.840.113549.1.5.3" because both the algorithm name and OID can be specified through the system property."
I've followed this suggestion directly.
It should also be possible to do something tricky with AlgorithmId.pbeWithMD5AndDES_oid, but that seems to be more error-prone, so that is not my first choice for a backport.

11u backport:
http://cr.openjdk.java.net/~mdoerr/8266293_keyprotection_11u/webrev.00/

Please review.

Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.java.net  Tue May 18 15:22:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 15:22:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Tue, 18 May 2021 12:42:08 GMT, Sean Mullan  wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 315:
>> 
>>> 313:  *
>>> 314:  * @since   1.0
>>> 315:  * @deprecated The Security Manager is deprecated and subject to removal in a
>> 
>> Javadoc will prefix, in bold, "Deprecated, for removal: This API element is subject to removal in a future version". I'm just wondering if the sentence will be repeated here, can you check?
>
> It includes both:
> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)

Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From mullan at openjdk.java.net  Tue May 18 15:49:38 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 18 May 2021 15:49:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: <0_9OMaDXfGSSqm5VdlusV4KRWnHxD2KFD5ifyV1hVFI=.1ba2b000-954e-4b23-a869-7d3aa1a909d6@github.com>

On Tue, 18 May 2021 15:19:21 GMT, Alan Bateman  wrote:

>> It includes both:
>> ![Screen Shot 2021-05-18 at 8 41 11 AM](https://user-images.githubusercontent.com/35072269/118652730-dfb35400-b7b4-11eb-83ee-92be9136fea2.jpg)
>
> Thanks for checking, I assumed that was the case so wondering if it should be dropped from the deprecation text to avoid the repeated sentence.

My feeling is that it is better to be more specific than the generic removal text as this is the most significant class that is being deprecated for removal. Also, this says "the Security Manager" (note the space between) which really encompasses more than the `java.lang.SecurityManager` API and which is explained more completely in the JEP.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From darcy at openjdk.java.net  Tue May 18 16:29:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 18 May 2021 16:29:47 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From chegar at openjdk.java.net  Tue May 18 16:38:42 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 18 May 2021 16:38:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

The changes in the net area look fine.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073


From naoto at openjdk.java.net  Tue May 18 16:45:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 18 May 2021 16:45:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Reviewed i18n/java.time/charset. They all look good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073


From naoto at openjdk.java.net  Tue May 18 16:52:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 18 May 2021 16:52:41 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Classes in the i18n area look good.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4088


From valeriep at openjdk.java.net  Tue May 18 17:07:41 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 18 May 2021 17:07:41 GMT
Subject: RFR: 8265462: Handle multiple slots in the NSS Internal Module
 from SunPKCS11's Secmod [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 May 2021 04:03:16 GMT, Martin Balao  wrote:

>> Hi,
>> 
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>> 
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior.
>> 
>> No regressions observed in the jdk/sun/security/pkcs11 tests category.
>> 
>> A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it.
>> 
>> Thanks,
>> Martin.-
>> 
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462
>
> Martin Balao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Documentation improvements and minor reordering

The updates look good. Thanks! Valerie

-------------

Marked as reviewed by valeriep (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3661


From joehw at openjdk.java.net  Tue May 18 17:30:39 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 18 May 2021 17:30:39 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

java.xml changes look good. Thanks.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4073


From alanb at openjdk.java.net  Tue May 18 17:39:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 18 May 2021 17:39:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/security/AccessController.java line 877:

> 875:     @CallerSensitive
> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From mchung at openjdk.java.net  Tue May 18 17:43:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:43:39 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, i18n, rmi, javadoc, swing, 2d, security, hotspot-runtime, nio, xml, beans, ~~core-libs~~, ~~net~~, compiler, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

I reviewed non-client areas.  Looks okay.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071


From mchung at openjdk.java.net  Tue May 18 17:53:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 18 May 2021 17:53:51 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang  wrote:

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Tue May 18 18:42:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 18:42:26 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Tue, 18 May 2021 17:36:55 GMT, Alan Bateman  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>
> src/java.base/share/classes/java/security/AccessController.java line 877:
> 
>> 875:     @CallerSensitive
>> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
> 
> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.

My rule is that a new line is added if there's only whitespaces before the insert position and the previous line does not end with a comma. In this case, unless I move `Permission... perms` onto a new line that an annotation on a new line looks like covering both `context` and `perms`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Tue May 18 21:13:40 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:13:40 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Tue, 18 May 2021 18:38:52 GMT, Weijun Wang  wrote:

>> src/java.base/share/classes/java/security/AccessController.java line 877:
>> 
>>> 875:     @CallerSensitive
>>> 876:     public static  T doPrivileged(PrivilegedExceptionAction action,
>>> 877:                                      @SuppressWarnings("removal") AccessControlContext context, Permission... perms)
>> 
>> you might find it easier if you put the Permissions parameter on a new line. There are several places in AccessController where the same thing happens.
>
> I'll try to update my auto-annotating program.

Turns out this only happens in this class:

$ rg '^\s*@SuppressWarnings("removal").*?,.'
src/java.base/share/classes/java/security/AccessController.java:449:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:514:        @SuppressWarnings("removal") AccessControlContext context, Permission... perms) {
src/java.base/share/classes/java/security/AccessController.java:877:                                     @SuppressWarnings("removal") AccessControlContext context, Permission... perms)

I'll fix them manually.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Tue May 18 21:21:45 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:21:45 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Sean, Phil and Alan

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/eb6c566f..bb73093a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=00-01

  Stats: 9 lines in 3 files changed: 4 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073


From bchristi at openjdk.java.net  Tue May 18 21:23:08 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 18 May 2021 21:23:08 GMT
Subject: RFR: 8266936: Add a finalization JFR event
Message-ID: 

Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
(The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)

The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.

The Category for the event:
`"Java Virtual Machine" / "GC" / "Finalization"`
is what made sense to me, even though the event is generated from library code.

Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
Automated testing looks good so far.

Thanks,
-Brent

-------------

Commit messages:
 - Fix jcheck some more
 - Fix jcheck
 - Merge branch 'master' into 8266936
 - Add jfr mode to test/jdk/java/lang/ref/FinalizeOverride.java
 - Fix spacing in new regtest
 - Remove extraneous comments from new regtest
 - Removed unintentional changes from FinalizeOverride.java
 - Actually check in new regtest
 - Update TestActiveSettingEvent.java
 - Update TestDefaultConfigurations.java and .jfc files
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e6705c0e...200268ab

Changes: https://git.openjdk.java.net/jdk/pull/4101/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266936
  Stats: 191 lines in 11 files changed: 190 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4101.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4101/head:pull/4101

PR: https://git.openjdk.java.net/jdk/pull/4101


From github.com+6502015+ineuwirth at openjdk.java.net  Tue May 18 21:43:48 2021
From: github.com+6502015+ineuwirth at openjdk.java.net (Istvan Neuwirth)
Date: Tue, 18 May 2021 21:43:48 GMT
Subject: RFR: 8266936: Add a finalization JFR event
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 20:55:10 GMT, Brent Christian  wrote:

> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
> 
> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
> 
> The Category for the event:
> `"Java Virtual Machine" / "GC" / "Finalization"`
> is what made sense to me, even though the event is generated from library code.
> 
> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
> Automated testing looks good so far.
> 
> Thanks,
> -Brent

test/jdk/jdk/jfr/event/gc/finalization/TestFinalizerEvent.java line 48:

> 46: 
> 47: public class TestFinalizerEvent {
> 48:     static boolean finalizerRun = false;

Should not this be a `volatile` field? (Or alternatively, using `AtomicBoolean`). As the `finalize` is invoked on the finalizer thread, the other thread executing the test might not see the change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101


From weijun at openjdk.java.net  Tue May 18 21:44:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 18 May 2021 21:44:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  adjust order of VM options

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/900c28c0..bfa955ad

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=00-01

  Stats: 59 lines in 18 files changed: 8 ins; 6 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071


From dblack at atlassian.com  Tue May 18 22:06:34 2021
From: dblack at atlassian.com (David Black)
Date: Wed, 19 May 2021 08:06:34 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <25B49E78-4DA7-47F6-B01F-0093582B274E@oracle.com>
References: 
 <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>
 
 <25B49E78-4DA7-47F6-B01F-0093582B274E@oracle.com>
Message-ID: 

On Tue, 18 May 2021 at 22:24, Ron Pressler  wrote:
>
>
> > On 18 May 2021, at 07:10, David Black  wrote:
> >
> >
> > I hope you aren't being rude on purpose by continuing to 1) top post
> > and 2) not ignore various parts of my emails.
> >
>
> This isn?t a debate forum. We?re trying to collect information, not
> to convince every last person. I respond to what I think I can comment
> on.

To be honest this still comes off as rude to me but at least you
aren't top posting and have explained why various things have been
left out.
Additionally, thank you for engaging with my emails. My point in
responding isn't to debate you but to ensure that a view is registered
& when it seems that things are left out it seems odd to me.

> >
> > I am not trying to be rude but I would like to ask what is more expensive -
> > 1) auditing 1,000,000 lines of code - with active development on going
> > 2) re-architecting an application so that the main process ?cannot?
> > make new connections after a certain point (preventing new FDs from
> > being opened) & making external connections from another process which
> > has operating/configuration/other restrictions on it to prevent it
> > from talking with sensitive network locations
> > 3) examining all known locations using a security manager in a
> > non-enforcing mode or as you noted - the Java Flight recorder & fixing
> > all known currently existing locations
> > 4) ^ 3 but you use a security manager or something that lets you make
> > decisions about connections/$things such that you can block in
> > addition to monitor things
>
>
> I happen to think that the most cost-effective thing would be to assign
> the entire trusted process the minimal permissions it requires, to monitor
> it for suspicious activity with JFR, and to invest the effort required to
> maintain the Security Manager in security measures that most people might
> actually use. Is that 3? The question of whether or not it?s worth it to go
> from 3 to 4 depends on the added cost vs the added benefit, compared to all
> other options. I happen to think it?s not worth it, but the relevant
> maintainers might well consider some inexpensive building blocks for those
> who think differently, and wish to construct a code-origin based permission
> system.

I don't think that this thinking is unique but it might not be worth
the "cost" to Oracle to maintain something that seemingly for various
reasons Oracle has little interest in maintaining (we're not in
applet-land anymore). I would like to encourage proposals that mean
that people who want to do 4, who implement further security hardening
where others seemingly shy away, can continue to do 4.


-- 
David Black / Security Engineer.


From bchristi at openjdk.java.net  Tue May 18 22:27:37 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 18 May 2021 22:27:37 GMT
Subject: RFR: 8266936: Add a finalization JFR event
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 May 2021 21:40:57 GMT, Istvan Neuwirth  wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> test/jdk/jdk/jfr/event/gc/finalization/TestFinalizerEvent.java line 48:
> 
>> 46: 
>> 47: public class TestFinalizerEvent {
>> 48:     static boolean finalizerRun = false;
> 
> Should not this be a `volatile` field? (Or alternatively, using `AtomicBoolean`). As the `finalize` is invoked on the finalizer thread, the other thread executing the test might not see the change.

Good idea, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101


From mbalao at openjdk.java.net  Tue May 18 22:37:43 2021
From: mbalao at openjdk.java.net (Martin Balao)
Date: Tue, 18 May 2021 22:37:43 GMT
Subject: Integrated: 8265462: Handle multiple slots in the NSS Internal Module
 from SunPKCS11's Secmod
In-Reply-To: 
References: 
Message-ID: 

On Fri, 23 Apr 2021 19:32:35 GMT, Martin Balao  wrote:

> Hi,
> 
> Please find in this PR a proposal to fix JDK-8265462 [1].
> 
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal Module. If the NSS Internal Module has more slots (for example, as a result of an initialization sequence such as the one triggered from the libnsssysinit.so library), they will be ignored. The goal is to handle multiple-slots scenarios while keeping OpenJDK's previous behavior.
> 
> No regressions observed in the jdk/sun/security/pkcs11 tests category.
> 
> A new regression test was not added as part of this changeset because of its complexity. It would depend on a specific NSS configuration, or the NSS library would need to be mocked. I've done manual testing in my environment and JDK-8265462 [1] has further information about it.
> 
> Thanks,
> Martin.-
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8265462

This pull request has now been integrated.

Changeset: bdbe23b9
Author:    Martin Balao 
URL:       https://git.openjdk.java.net/jdk/commit/bdbe23b9cb6151c81a4de675e629b0a42f00640d
Stats:     167 lines in 3 files changed: 135 ins; 3 del; 29 mod

8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod

Reviewed-by: valeriep

-------------

PR: https://git.openjdk.java.net/jdk/pull/3661


From bchristi at openjdk.java.net  Tue May 18 22:41:06 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 18 May 2021 22:41:06 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
> 
> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
> 
> The Category for the event:
> `"Java Virtual Machine" / "GC" / "Finalization"`
> is what made sense to me, even though the event is generated from library code.
> 
> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
> Automated testing looks good so far.
> 
> Thanks,
> -Brent

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  Test flag should be volatile

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4101/files
  - new: https://git.openjdk.java.net/jdk/pull/4101/files/200268ab..e0ef383b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4101&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4101.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4101/head:pull/4101

PR: https://git.openjdk.java.net/jdk/pull/4101


From egahlin at openjdk.java.net  Wed May 19 06:23:39 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 19 May 2021 06:23:39 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 May 2021 22:41:06 GMT, Brent Christian  wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test flag should be volatile

This looks useful, but I am worried about the performance impact:

- The added allocation for every object that is finalized. 
- The event being enabled in the default configuration. 

The default configuration must be safe to use even in pathological cases, i.e. an application with lots of objects being finalized. It's probably too much overhead (or number of events) for the profile configuration as well.

There is also the added startup cost of JFR. One event may not matter that much, but they all add up. We need to put in place a mechanism that doesn't rely on bytecode instrumentation at runtime. There is an enhancement for that, but it requires some engineering first.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101


From alanb at openjdk.java.net  Wed May 19 06:55:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 19 May 2021 06:55:39 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 May 2021 06:20:59 GMT, Erik Gahlin  wrote:

> This looks useful, but I am worried about the performance impact:
> 
> * The added allocation for every object that is finalized.
> * The event being enabled in the default configuration.
> 
> The default configuration must be safe to use even in pathological cases, i.e. an application with lots of objects being finalized. It's probably too much overhead (or number of events) for the profile configuration as well.
> 
> There is also the added startup cost of JFR. One event may not matter that much, but they all add up. We need to put in place a mechanism that doesn't rely on bytecode instrumentation at runtime. There is an enhancement for that, but it requires some engineering first.

I'm a bit worried by this too. Does it need to be enabled by default? Can we put a static final instance of FinalizerEvent in that class that can be used to test if the event is enabled so that it doesn't create a FinalizerEvent when disabled?

Is it worth exploring doing have an event in the VM, in register_finalizer, instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101


From egahlin at openjdk.java.net  Wed May 19 07:54:09 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Wed, 19 May 2021 07:54:09 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 May 2021 22:41:06 GMT, Brent Christian  wrote:

>> Please review this enhancement to add a new JFR event, generated whenever a finalizer is run.
>> (The makeup is similar to the Deserialization event, [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>> 
>> The event's only datum (beyond those common to all jfr events) is the class of the object that was finalized.
>> 
>> The Category for the event:
>> `"Java Virtual Machine" / "GC" / "Finalization"`
>> is what made sense to me, even though the event is generated from library code.
>> 
>> Along with the new regtest, I added a run mode to the basic finalizer test to enable jfr.
>> Automated testing looks good so far.
>> 
>> Thanks,
>> -Brent
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test flag should be volatile

I wonder if there needs to be one event per finalized object?

Perhaps a counter per class would be as useful, i.e. jdk.FinalizationStatistics, and if it could be implemented in the VM, without other implications, that would be great. 

Such an event could be enabled by default and provide much greater value than an event that users would need to know about and configure themselves, which 99,99% of all user will not do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4101


From goetz.lindenmaier at sap.com  Wed May 19 10:10:07 2021
From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz)
Date: Wed, 19 May 2021 10:10:07 +0000
Subject: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails
 with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes
 long"
In-Reply-To: 
References: 
Message-ID: 

Hi Martin,

This looks good to me. The adaption makes sense.

Best regards,
  Goetz.

From: security-dev  On Behalf Of Doerr, Martin
Sent: Dienstag, 18. Mai 2021 17:03
To: jdk-updates-dev at openjdk.java.net; security-dev 
Subject: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long"

Hi,

JDK-8266293 is backported to 11.0.12-oracle. The included test shows that the fix is required in 11u.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8266293

Original change:
https://git.openjdk.java.net/jdk/commit/04f71126479f9c39aa71e8aebe7196d72fc16796

It applies almost cleanly. Only the bug id addition in the test had to get done manually.

However, the new code needs an adaptation because JDK11u doesn't contain KnownOIDs.
One of the original author's comments says:
"Backporters might need to check case-insensitive equality to both "PBEWithMD5AndDES" and "1.2.840.113549.1.5.3" because both the algorithm name and OID can be specified through the system property."
I've followed this suggestion directly.
It should also be possible to do something tricky with AlgorithmId.pbeWithMD5AndDES_oid, but that seems to be more error-prone, so that is not my first choice for a backport.

11u backport:
http://cr.openjdk.java.net/~mdoerr/8266293_keyprotection_11u/webrev.00/

Please review.

Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Wed May 19 10:17:24 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Wed, 19 May 2021 10:17:24 +0000
Subject: AW: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails
 with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes
 long"
In-Reply-To: 
References: ,
 
Message-ID: 

Hi G?tz,

thank you for the review!

Best regards,
Martin


Von: Lindenmaier, Goetz 
Datum: Mittwoch, 19. Mai 2021 um 12:10
An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev 
Betreff: RE: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long"
Hi Martin,

This looks good to me. The adaption makes sense.

Best regards,
  Goetz.

From: security-dev  On Behalf Of Doerr, Martin
Sent: Dienstag, 18. Mai 2021 17:03
To: jdk-updates-dev at openjdk.java.net; security-dev 
Subject: [11u] RFR: 8266293: Key protection using PBEWithMD5AndDES fails with "java.security.InvalidAlgorithmParameterException: Salt must be 8 bytes long"

Hi,

JDK-8266293 is backported to 11.0.12-oracle. The included test shows that the fix is required in 11u.

Bug:
https://bugs.openjdk.java.net/browse/JDK-8266293

Original change:
https://git.openjdk.java.net/jdk/commit/04f71126479f9c39aa71e8aebe7196d72fc16796

It applies almost cleanly. Only the bug id addition in the test had to get done manually.

However, the new code needs an adaptation because JDK11u doesn't contain KnownOIDs.
One of the original author?s comments says:
"Backporters might need to check case-insensitive equality to both "PBEWithMD5AndDES" and "1.2.840.113549.1.5.3" because both the algorithm name and OID can be specified through the system property."
I've followed this suggestion directly.
It should also be possible to do something tricky with AlgorithmId.pbeWithMD5AndDES_oid, but that seems to be more error-prone, so that is not my first choice for a backport.

11u backport:
http://cr.openjdk.java.net/~mdoerr/8266293_keyprotection_11u/webrev.00/

Please review.

Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mcimadamore at openjdk.java.net  Wed May 19 12:15:28 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 19 May 2021 12:15:28 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v23]
In-Reply-To: 
References: 
Message-ID: 

> 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 VaList test
  Remove unused code in Utils

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/f6051daf..f5668ffc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=21-22

  Stats: 6 lines in 2 files changed: 0 ins; 5 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


From sean.mullan at oracle.com  Wed May 19 13:48:35 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 19 May 2021 09:48:35 -0400
Subject: Updates to JEP 411: Deprecate the Security Manager for Removal
Message-ID: <9272f796-4268-a674-b648-49ff26ad3bc6@oracle.com>

Thanks for those that have taken the time to review JEP 411 [1]. The JEP 
has been updated today with a few changes, the most significant which is 
the addition of a new section titled "Future Work" [2] which lists 
related potential enhancements and works in progress.

Other smaller changes have been made throughout the JEP, including:

  - The "Alternate JAAS APIs" section has been removed and replaced with 
a smaller section in the Description section with a pointer to a JBS 
issue with more details.

  - Changes have been made to the Motivation section to improve some of 
the wording and add more details.

  - A new item named "Preserve the Security Manager API for extension by 
custom Security Managers that wish to intercept, log, and veto access to 
resources" has been added to the Alternatives section, as this has been 
a topic of discussion since the JEP has been published.

  - RMISecurityException has been removed from the list of APIs to be 
deprecated for removal, and 
java.util.concurrent.Executors::{privilegedCallable, 
privilegedCallableUsingCurrentClassLoader, privilegedThreadFactory} have 
been added.

Thanks,
Sean

[1] https://openjdk.java.net/jeps/411
[2] https://openjdk.java.net/jeps/411#Future-Work


From weijun at openjdk.java.net  Wed May 19 13:47:54 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:54 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v2]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: <8mVaKSBeyfyVBHsp67PuOC1G7--flmHQzygrQTyrgGE=.ed4f6dd9-e0af-4058-97f5-cf5ab3651aa4@github.com>

On Tue, 18 May 2021 21:21:45 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback from Sean, Phil and Alan

A new commit fixing `awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java` test in tier4. The test compares stderr output with a known value but we have a new warning written to stderr now. It's now using stdout instead. @prrace, Please confirm this is acceptable. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Wed May 19 13:47:53 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 13:47:53 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/bb73093a..c4221b5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073


From pconcannon at openjdk.java.net  Wed May 19 14:08:15 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 19 May 2021 14:08:15 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
 [v2]
In-Reply-To: 
References: 
Message-ID: <8AXQCx52GlKankpXKO_Ouh0ASaCl9fkiRj8ZCz3TOJo=.85f154c1-0214-4db7-8834-ced49cf4c868@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications
 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Update java.util to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4088/files
  - new: https://git.openjdk.java.net/jdk/pull/4088/files/0ed0bd99..cd99dc49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=00-01

  Stats: 4003 lines in 175 files changed: 2590 ins; 890 del; 523 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088

PR: https://git.openjdk.java.net/jdk/pull/4088


From duke at openjdk.java.net  Wed May 19 16:26:50 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 16:26:50 GMT
Subject: Withdrawn: 8258588: MD5 MessageDigest in java.util.UUID should be
 cached
In-Reply-To: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
References: <2IYvtVT5H7WLlIBliMuQrPPq5kAGEoxa5KZN2-H_ljU=.3c016813-426d-4357-b197-f129051a1898@github.com>
Message-ID: 

On Thu, 17 Dec 2020 13:36:17 GMT, PROgrm_JARvis  wrote:

> Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an internal holder class.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1821


From gnu.andrew at redhat.com  Wed May 19 16:58:49 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 19 May 2021 17:58:49 +0100
Subject: [8u] RFR: 8206925: Support the certificate_authorities extension
In-Reply-To: 
References: 
Message-ID: <20210519165849.GA1394384@rincewind>

On 12:23 Tue 20 Apr     , Severin Gehwolf wrote:
> Hi,
> 
> Please review this OpenJDK 8u backport of the certificate_authorities
> extensionj. The OpenJDK 11u patch didn't apply cleanly after path
> unshuffeling, but was fairly trivial to resolve. Conflicts caused by:
> 
> 1. X509Authentication.java copyright line conflict only. Resolved
>    manually.
> 2. SSLContextTemplate.java private interface methods not allowed in
>    JDK 8. It's a JDK 9+ feature via JEP 213. Changed modifier to
>    default. Note: this is code used in tests only.
> 3. TooManyCAs.java. Added -Djdk.tls.client.protocols=TLSv1.3 to the
>    test invocations since JDK 8u doesn't enable TLSv1.3 on the
>    client side by default. See JDK-8248721, CSR of the TLSv1.3 8u
>    backport.
> 
> Other than that, the patch is identical to the OpenJDK 11.0.12 version
> of this patch.
> 
> This introduces a new system property,
> jdk.tls.client.enableCAExtension, for compatibilty reasons. CSR has
> been reused from the Oracle JDK backport. See below.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8206925
> CSR: https://bugs.openjdk.java.net/browse/JDK-8248709
> webrev: https://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8206925/jdk8/02/webrev/
> 
> Testing: sun/security/ssl tests and tier1. No new regressions.
>          New tests pass.
> 
> Thoughts?
> 
> Thanks,
> Severin
> 

There are some odd whitespace differences showing up in the diff between
the 8u & 11u versions of SSLContextTemplate.java, but seems ok.  Approved.

Please note that, where a manual backport bug is created, the fix
request should go on the backport bug, so we don't have things split
between two different bugs.

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: 

From prr at openjdk.java.net  Wed May 19 18:16:57 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:16:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From prr at openjdk.java.net  Wed May 19 18:19:49 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:19:49 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This change is so large that github won't even display the list of files so I can't jump to where I want to go !
And when I try to scroll I get just a blank page.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From prr at openjdk.java.net  Wed May 19 18:29:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 18:29:41 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.desktop/share/classes/java/awt/Component.java line 217:

> 215:  * @author      Sami Shaio
> 216:  */
> 217: @SuppressWarnings("removal")

Why is this placed on the *entire class* ??
This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

src/java.desktop/share/classes/java/awt/Container.java line 97:

> 95:  * @since     1.0
> 96:  */
> 97: @SuppressWarnings("removal")

Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.

Where else are you adding this to entire classes instead of the specific site ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Wed May 19 18:41:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:41:44 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Wed, 19 May 2021 18:26:25 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 217:
> 
>> 215:  * @author      Sami Shaio
>> 216:  */
>> 217: @SuppressWarnings("removal")
> 
> Why is this placed on the *entire class* ??
> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.

This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is

        s = java.security.AccessController.doPrivileged(
                                                        new GetPropertyAction("awt.image.redrawrate"));

> src/java.desktop/share/classes/java/awt/Container.java line 97:
> 
>> 95:  * @since     1.0
>> 96:  */
>> 97: @SuppressWarnings("removal")
> 
> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
> 
> Where else are you adding this to entire classes instead of the specific site ?

Similar as the one above, it's because of

    static {
        // Don't lazy-read because every app uses invalidate()
        isJavaAwtSmartInvalidate = AccessController.doPrivileged(
                new GetBooleanAction("java.awt.smartInvalidate"));
    }

> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
>> 57:                 ProcessCommunicator
>> 58:                         .executeChildProcess(Consumer.class, new String[0]);
>> 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

The child process is started with `-Djava.security.manager=allow` (after the other PR) and a warning will be printed to stderr. Therefore I move the message to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Wed May 19 18:46:46 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:46:46 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: 

On Wed, 19 May 2021 18:39:10 GMT, Weijun Wang  wrote:

>> src/java.desktop/share/classes/java/awt/Container.java line 97:
>> 
>>> 95:  * @since     1.0
>>> 96:  */
>>> 97: @SuppressWarnings("removal")
>> 
>> Same issue as with Component. a > 5,000 line file that uses AccessController in just 4 places.
>> 
>> Where else are you adding this to entire classes instead of the specific site ?
>
> Similar as the one above, it's because of
> 
>     static {
>         // Don't lazy-read because every app uses invalidate()
>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>                 new GetBooleanAction("java.awt.smartInvalidate"));
>     }

We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Wed May 19 18:51:43 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 18:51:43 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 
Message-ID: 

On Wed, 19 May 2021 18:44:06 GMT, Weijun Wang  wrote:

>> Similar as the one above, it's because of
>> 
>>     static {
>>         // Don't lazy-read because every app uses invalidate()
>>         isJavaAwtSmartInvalidate = AccessController.doPrivileged(
>>                 new GetBooleanAction("java.awt.smartInvalidate"));
>>     }
>
> We are thinking of more tweaks after this overall change to make the annotation more precise. For example, in this case we can assign the `doPrivileged` result to a local variable right at its declaration, and then assign it to `isJavaAwtSmartInvalidate`. Some people might think this is ugly. Such manual code changes need to done little by little to ease code reviewing.

I know it's not easy to read the commit and that's why I make the 3rd commit totally automatic. Hopefully you have more confidence on the program than my hand. All annotations are added to the nearest declarations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From hchao at openjdk.java.net  Wed May 19 19:10:17 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 19 May 2021 19:10:17 GMT
Subject: RFR: 8266400: importkeystore fails to a password less pkcs12 keystore
Message-ID: 

Please review the fix to address keytool -importkeystore failure when importing to a password-less PKCS12 keystore.

-------------

Commit messages:
 - 8266400: importkeystore fails to a password less pkcs12 keystore

Changes: https://git.openjdk.java.net/jdk/pull/4119/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4119&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266400
  Stats: 92 lines in 2 files changed: 89 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4119.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4119/head:pull/4119

PR: https://git.openjdk.java.net/jdk/pull/4119


From prr at openjdk.java.net  Wed May 19 19:34:48 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 19:34:48 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>

On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang  wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>> 
>>> 215:  * @author      Sami Shaio
>>> 216:  */
>>> 217: @SuppressWarnings("removal")
>> 
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long and mentions AccessControl something like 8 places it uses AccessController or AcessControlContext.
>
> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
> 
>         s = java.security.AccessController.doPrivileged(
>                                                         new GetPropertyAction("awt.image.redrawrate"));

That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
You can define a static private method to contain this and call it from the static initializer block.
Much better than applying the annotation to an entire class.

--- a/src/java.desktop/share/classes/java/awt/Component.java
+++ b/src/java.desktop/share/classes/java/awt/Component.java
@@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
      */
     static boolean isInc;
     static int incRate;
+
+    private static void initIncRate() {
+        String s = java.security.AccessController.doPrivileged(
+                                 new GetPropertyAction("awt.image.incrementaldraw"));
+        isInc = (s == null || s.equals("true"));
+
+        s = java.security.AccessController.doPrivileged(
+                          new GetPropertyAction("awt.image.redrawrate"));
+        incRate = (s != null) ? Integer.parseInt(s) : 100;
+    }
+
     static {
         /* ensure that the necessary native libraries are loaded */
         Toolkit.loadLibraries();
@@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
         if (!GraphicsEnvironment.isHeadless()) {
             initIDs();
         }
-
-        String s = java.security.AccessController.doPrivileged(
-                                                               new GetPropertyAction("awt.image.incrementaldraw"));
-        isInc = (s == null || s.equals("true"));
-
-        s = java.security.AccessController.doPrivileged(
-                                                        new GetPropertyAction("awt.image.redrawrate"));
-        incRate = (s != null) ? Integer.parseInt(s) : 100;
+        initIncRate();
     }

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From ascarpino at openjdk.java.net  Wed May 19 20:21:23 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 19 May 2021 20:21:23 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
> 
> Thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  Fix perf problem by reorganizing doLastBlock()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4072/files
  - new: https://git.openjdk.java.net/jdk/pull/4072/files/4a2e35c1..e75926e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=02-03

  Stats: 259 lines in 1 file changed: 70 ins; 106 del; 83 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Wed May 19 20:27:50 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 19 May 2021 20:27:50 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Mon, 17 May 2021 21:41:37 GMT, Anthony Scarpino  wrote:

>> Hi,
>> 
>> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - review comment updates
>  - Fixed the lack of overlap detection with GCMEncrypt.update()

Here are some comments. Please discard if it does not apply to the latest change.

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 54:

> 52:  * @since 1.8
> 53:  */
> 54: final class GCTR extends CounterMode implements GCM {

Not sure if this really needs to implements GCM?

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 58:

> 56:     // Maximum buffer size rotating ByteBuffer->byte[] intrinsic copy
> 57:     private static final int MAX_LEN = 1024;
> 58:     byte[] block;

make private?

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 86:

> 84:     }
> 85: 
> 86:     void checkBlock() {

make private?

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 95:

> 93: 
> 94:     /**
> 95:      * Using the given inLen, this operations only on blockSize data, leaving

nit: operates (instead of operations)

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 97:

> 95:      * Using the given inLen, this operations only on blockSize data, leaving
> 96:      * the remainder in 'in'.
> 97:      * The return value will be (inLen - (inLen - blockSize))

I think you mean (inLen - (inLen % blockSize))?

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 153:

> 151:             throw new RuntimeException("input length out of bound");
> 152:         }
> 153:         if (inLen < 0 || inLen % blockSize != 0) {

The 2nd condition, i.e. (inLen % blockSize != 0), should be removed just like the other update(byte[], int, int, byte[], int) method?

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 203:

> 201:         // allocating and copying for direct bytebuffers
> 202:         if (!src.isDirect() && !dst.isDirect() &&
> 203:             !src.isReadOnly() && !dst.isReadOnly()) {

Why do we need to check for src being isReadOnly() since we are not writing bytes into src? As for dst, if it's read only, then we should probably not proceed further? The other update method which takes ByteBuffer dst did not check if it's read only. A bit inconsistent?

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 219:

> 217:             // roll over incorrectly. Use GCM-specific code instead.
> 218:             for (int i = 0; i < numOfCompleteBlocks; i++) {
> 219:                 checkBlock();

checkBlock() can probably be moved outside of the for-loop?

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 268:

> 266:             }
> 267:         }
> 268:         reset();

To ensure no change of behavior, keep the reset() inside the try/finally block?

src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 283:

> 281:         // allocating and copying for direct bytebuffers
> 282:         if (!src.isDirect() && !dst.isDirect() &&
> 283:             !src.isReadOnly() && !dst.isReadOnly()) {

Same question regarding the isReadOnly() calls as in the update(ByteBuffer, ByteBuffer) method.

src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 51:

> 49:  */
> 50: final class GHASH implements Cloneable, GCM {
> 51:     private static final int AES_BLOCK_SIZE = 16;

nit: add an empty line between this and next.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Wed May 19 20:27:56 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 19 May 2021 20:27:56 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: 
References: 
 
Message-ID: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>

On Tue, 18 May 2021 03:18:18 GMT, Anthony Scarpino  wrote:

>> Hi,
>> 
>> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 181:

> 179: 
> 180:     // Will process as many blocks it can and will leave the remaining.
> 181:     int update(ByteBuffer ct, int inLen) {

Throughout this method, comments still have "src", but the variable is renamed to "ct". Fix this inconsistency?

src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 187:

> 185:             int processed = inLen - (inLen % AES_BLOCK_SIZE);
> 186:             processBlocksDirect(ct, inLen);
> 187:             ct.position(ct.position());

ct.position(ct.position())? looks redundant?

src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 189:

> 187:             ct.position(ct.position());
> 188:             return processed;
> 189:         } else if (!ct.isReadOnly()) {

Maybe you meant "ct.hasArray()" instead of "!ct.isReadOnly()"?

src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 202:

> 200:         if (inLen == 0) {
> 201:             return 0;
> 202:         }

Seems that this should be moved to the very beginning of this method, i.e. before the if-check on line 184?

src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 338:

> 336:     public int doFinal(ByteBuffer src, ByteBuffer dst) {
> 337:         return doFinal(src, src.remaining());
> 338:     }

Have you considered changing the argument list of existing update/doFinal(...) methods? Less calls.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 75:

> 73:     private GCMEngine engine;
> 74: 
> 75:     private boolean encryption = true;

Move these non-static fields to where they belong?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 92:

> 90: 
> 91:     private boolean initialized = false;
> 92:     // Default value is 128bits, this in stores bytes.

nit: "this in stores bytes" -> "this is in bytes"?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 94:

> 92:     // Default value is 128bits, this in stores bytes.
> 93:     int tagLenBytes = 16;
> 94:     // Key size if the value is passed

nit: add info such as this is in bits or bytes to comment.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 98:

> 96:     // Prevent reuse of iv or key
> 97:     boolean reInit = false;
> 98:     final static byte[] emptyBuf = new byte[0];

Move this to where the rest of static variables are? "final static" -> "static final". emptyBuf -> EMPTY_BUF or else?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 133:

> 131:             throw new InvalidKeyException("The key must be " +
> 132:                 keySize + " bytes");
> 133:         }

Set the keyValue to all 0s before throwing exception, i.e. try-finally.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 137:

> 135:         // Check for reuse
> 136:         if (encryption) {
> 137:             if (Arrays.compare(keyValue, lastKey) == 0 && Arrays.compare(iv,

Per the earlier impl, it uses MessageDigest.isEqual(...) instead of Arrays.compare(...).

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 144:

> 142: 
> 143:             // Both values are already clones
> 144:             lastKey = keyValue;

Per the earlier impl, it does a check-n-erase before this assignment, i.e.
`if (lastKey != null) { Arrays.fill(lastKey, (byte) 0); }`

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 149:

> 147:             if (spec == null) {
> 148:                 throw new InvalidKeyException("No GCMParameterSpec specified");
> 149:             }

This seems redundant as it's already been checked in engineInit() before calling this method. Line 154 directly calls spec.getTLen() without checking spec != null.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 168:

> 166:     // return tag length in bytes
> 167:     int getTagLen() {
> 168:         return this.tagLenBytes;

Doesn't seem too useful if all it does is just returning the 'tagLenBytes' field? With your current code, tagLenBytes is initialized with 16 and is set in init(). When a GCMParameterSpec is not specified, it uses the tagLenBytes value from earlier init() instead of a fixed default. This seems incorrect?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 199:

> 197:     @Override
> 198:     protected int engineGetKeySize(Key key) throws InvalidKeyException {
> 199:         return super.engineGetKeySize(key);

CipherSpi.engineGetKeySize(...) throws UnsupportedOperationException(). You will need to copy the impl from AESCipher.engineGetKeySize(...).

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 204:

> 202:     @Override
> 203:     protected byte[] engineGetIV() {
> 204:         return iv.clone();

Check for iv != null, otherwise NPE.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 220:

> 218:             random.nextBytes(iv);
> 219:         } else {
> 220:             new SecureRandom().nextBytes(iv);

Consider using JCAUtil.getDefSecureRandom()?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 225:

> 223:     }
> 224: 
> 225:     SecureRandom random = null;

Is this field used? I didn't find any assignment. If it's needed, can you please move it to where the rest of fields are?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 230:

> 228:         GCMParameterSpec spec;
> 229:         spec = new GCMParameterSpec(getTagLen() * 8,
> 230:             iv == null ? createIv(random) : iv.clone());

Use default tag length if (iv == null)?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 259:

> 257:     @Override
> 258:     protected void engineInit(int opmode, Key key,
> 259:         AlgorithmParameterSpec params, SecureRandom random)

The specified "random" is not saved to internal "random". Perhaps an oversight?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 266:

> 264:         if (params == null) {
> 265:             iv = createIv(random);
> 266:             spec = new GCMParameterSpec(getTagLen() * 8, iv);

Same, use default tag length?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 279:

> 277:             if (iv.length == 0) {
> 278:                 throw new InvalidAlgorithmParameterException("IV is empty");
> 279:             }

Why separating the validation of iv and tag length in separate methods, i.e. engineInit() vs init()? Consider consolidating them?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 402:

> 400:         }
> 401:         try {
> 402:             ArrayUtil.nullAndBoundsCheck(input, inputOffset, inputLen);

Why is only this ArrayUtil.nullAndBoundsCheck(...) present in this engineDoFinal(...)? There are other engineUpdate/engineDoFinal() calls which also have input array, offset, and length. Shouldn't this check be added there as well? If the crypto engine check is separated out into a separate method, e.g. checkEngine(), then you don't have to explicitly release the crypto engine (as on line 405) and can just call checkEngine() after all the input validation has passed.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 446:

> 444:         } finally {
> 445:             // Release crypto engine
> 446:             engine = null;

Should also do `Arrays.fill(encodedKey, (byte)0);`

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 468:

> 466:                 "The wrapped key does not have the correct length");
> 467:         }
> 468:         return ConstructKeys.constructKey(encodedKey, wrappedKeyAlgorithm,

should try-finally this call and do `Arrays.fill(encodedKey, (byte)0);`

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Wed May 19 20:27:57 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Wed, 19 May 2021 20:27:57 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
 
Message-ID: <863aV9irXc_UhU2Ug7w--ieSG-kaJXfv94h8aECUhMA=.9cfb5abf-34d0-49b4-9bca-9937932feafe@github.com>

On Wed, 19 May 2021 20:21:23 GMT, Anthony Scarpino  wrote:

>> Hi,
>> 
>> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix perf problem by reorganizing doLastBlock()

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 59:

> 57: final class GaloisCounterMode extends FeedbackCipher {
> 58: 
> 59:     static int DEFAULT_TAG_LEN = AES_BLOCK_SIZE;

Hmm, for the same reason as the DEFAULT_IV_LEN, you will probably need a DEFAULT_TAG_LEN. Otherwise, how do you know what the default tag length is after several Cipher.init() calls?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From mullan at openjdk.java.net  Wed May 19 20:33:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 19 May 2021 20:33:43 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: 

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The changes to the security tests look good.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071


From weijun at openjdk.java.net  Wed May 19 21:56:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 21:56:30 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
Message-ID: 

On Wed, 19 May 2021 19:31:24 GMT, Phil Race  wrote:

>> This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class. The call in this file is
>> 
>>         s = java.security.AccessController.doPrivileged(
>>                                                         new GetPropertyAction("awt.image.redrawrate"));
>
> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
> You can define a static private method to contain this and call it from the static initializer block.
> Much better than applying the annotation to an entire class.
> 
> --- a/src/java.desktop/share/classes/java/awt/Component.java
> +++ b/src/java.desktop/share/classes/java/awt/Component.java
> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>       */
>      static boolean isInc;
>      static int incRate;
> +
> +    private static void initIncRate() {
> +        String s = java.security.AccessController.doPrivileged(
> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
> +        isInc = (s == null || s.equals("true"));
> +
> +        s = java.security.AccessController.doPrivileged(
> +                          new GetPropertyAction("awt.image.redrawrate"));
> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +    }
> +
>      static {
>          /* ensure that the necessary native libraries are loaded */
>          Toolkit.loadLibraries();
> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>          if (!GraphicsEnvironment.isHeadless()) {
>              initIDs();
>          }
> -
> -        String s = java.security.AccessController.doPrivileged(
> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
> -        isInc = (s == null || s.equals("true"));
> -
> -        s = java.security.AccessController.doPrivileged(
> -                                                        new GetPropertyAction("awt.image.redrawrate"));
> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
> +        initIncRate();
>      }

Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From prr at openjdk.java.net  Wed May 19 22:07:36 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 22:07:36 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
Message-ID: 

On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang  wrote:

>> That's a sad limitation of the annotation stuff then, but I don't think that it is insurmountable.
>> You can define a static private method to contain this and call it from the static initializer block.
>> Much better than applying the annotation to an entire class.
>> 
>> --- a/src/java.desktop/share/classes/java/awt/Component.java
>> +++ b/src/java.desktop/share/classes/java/awt/Component.java
>> @@ -618,6 +618,17 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>       */
>>      static boolean isInc;
>>      static int incRate;
>> +
>> +    private static void initIncRate() {
>> +        String s = java.security.AccessController.doPrivileged(
>> +                                 new GetPropertyAction("awt.image.incrementaldraw"));
>> +        isInc = (s == null || s.equals("true"));
>> +
>> +        s = java.security.AccessController.doPrivileged(
>> +                          new GetPropertyAction("awt.image.redrawrate"));
>> +        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +    }
>> +
>>      static {
>>          /* ensure that the necessary native libraries are loaded */
>>          Toolkit.loadLibraries();
>> @@ -625,14 +636,7 @@ public abstract class Component implements ImageObserver, MenuContainer,
>>          if (!GraphicsEnvironment.isHeadless()) {
>>              initIDs();
>>          }
>> -
>> -        String s = java.security.AccessController.doPrivileged(
>> -                                                               new GetPropertyAction("awt.image.incrementaldraw"));
>> -        isInc = (s == null || s.equals("true"));
>> -
>> -        s = java.security.AccessController.doPrivileged(
>> -                                                        new GetPropertyAction("awt.image.redrawrate"));
>> -        incRate = (s != null) ? Integer.parseInt(s) : 100;
>> +        initIncRate();
>>      }
>
> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.

I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
I think it should all be taken care of as part of this proposed change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Wed May 19 22:17:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Wed, 19 May 2021 22:17:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
Message-ID: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>

On Wed, 19 May 2021 22:04:57 GMT, Phil Race  wrote:

>> Correct, there are ways to modify the code to make it more annotation-friendly. We thought about whether it's good to do it before adding the annotations or after it. Our decision now is to do it after because it will be more easy to see why it's necessary and we can take time to do them little by little. A new enhancement at https://bugs.openjdk.java.net/browse/JDK-8267432 is filed.
>
> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
> I think it should all be taken care of as part of this proposed change.

I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From duke at openjdk.java.net  Wed May 19 23:30:41 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 19 May 2021 23:30:41 GMT
Subject: Withdrawn: 8262880: Add support for the NSS Key Log Format for
 SSL/TLS keys
In-Reply-To: 
References: 
Message-ID: 

On Tue, 9 Mar 2021 17:18:39 GMT, Greg Rubin  wrote:

> This is my implementation for [JDK-8262880](https://bugs.openjdk.java.net/browse/JDK-8262880) and enables creating of an SSL/TLS key log in the standardized [NSS Key Log Format](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Key_Log_Format). This is supported by many TLS implementations and also by several parsers such as Wireshark. Supporting this will greatly ease in debugging TLS problems.
> 
> (Note: I am covered by the Amazon corporate contribution agreement).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2896


From prr at openjdk.java.net  Wed May 19 23:53:35 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 19 May 2021 23:53:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
Message-ID: 

On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang  wrote:

>> I don't think it is a separate P4 enhancement (?) that someone will (maybe) do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.

Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
I already pasted the patch for Component.java and it took about 60 seconds to do that.
Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.

I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Thu May 20 02:09:42 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:09:42 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
Message-ID: 

On Wed, 19 May 2021 23:50:04 GMT, Phil Race  wrote:

>> I just made it P3 (P4 was the default value), and I will target it to 17 once JEP 411 is targeted 17. But I think it's probably not a good idea to include it inside *this* PR. There are some middle ground where it's debatable if a change is worth doing (Ex: which is uglier between an a-liitle-faraway-annotation and a temporary variable?) so it's not obvious what the scope of the refactoring can be. Thus it will be divided into smaller sub-tasks. It's not totally impossible that part of the work will be delayed to next release.
>
> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
> I already pasted the patch for Component.java and it took about 60 seconds to do that.
> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
> 
> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?

I can make it a bug.

I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.

And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.

Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Thu May 20 02:12:33 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 20 May 2021 02:12:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 02:06:46 GMT, Weijun Wang  wrote:

>> Well .. as an enhancement (P3 or otherwise) I can see it being dropped and definitely if it misses the fork,
>> and I don't get why you can't do it here. And if it isn't done the JEP isn't really ready.
>> I already pasted the patch for Component.java and it took about 60 seconds to do that.
>> Then yes, you would have to deal with the fact that now you need to reapply your automated tool to the file but this is just work you'd have to have done anyway if it was already refactored.
>> 
>> I only *noticed* Component and Container. And stopped there to raise the question. How many more cases are there ?
>
> I can make it a bug.
> 
> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
> 
> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
> 
> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.

By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From prr at openjdk.java.net  Thu May 20 04:08:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:08:38 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
Message-ID: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>

On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang  wrote:

>> I can make it a bug.
>> 
>> I don't want to do it here is because it involves indefinite amount of manual work and we will see everyone having their preferences. The more time we spend on this PR the more likely there will be merge conflict. There are just too many files here.
>> 
>> And no matter if we include that change in this PR or after it, it will be after the automatic conversion. In fact, the data about which cases are more worth fixing come from the automatic conversion itself. Also, as the manual work will be done part by part, if the automatic conversion is after it, there will be rounds and rounds of history rewriting and force push. This is quite unfriendly to the reviewers.
>> 
>> Altogether, there are 117 class-level annotations. Unfortunately, `java.awt.Component` is the one with the biggest class -- estimated number of bytes that the annotation covers is over 380K. In the client area, the 2nd place is `java.awt.Container`, and then we have `sun.font.SunFontManager`, `java.awt.Window`, and `java.awt.Toolkit` which are over 100KB, and other 25 classes over 10KB, and other 11 classes smaller than 10KB.
>
> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.

That is unfortunate, but nonetheless I think required to be done.
We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>From my point of view it is a blocker.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From prr at openjdk.java.net  Thu May 20 04:25:29 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 20 May 2021 04:25:29 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
Message-ID: 

On Thu, 20 May 2021 04:05:23 GMT, Phil Race  wrote:

>> By converting JDK-8267432 to a bug, there is an extra benefit that we can fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
> From my point of view it is a blocker.

The JEP isn't PTT for 17 so there's plenty of time isn't there ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 06:45:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 06:45:43 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ???????  wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Any more comments?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589


From alanb at openjdk.java.net  Thu May 20 07:08:35 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 07:08:35 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
Message-ID: 

On Thu, 20 May 2021 04:22:32 GMT, Phil Race  wrote:

>> That is unfortunate, but nonetheless I think required to be done.
>> We have acknowledeged this can't reasonably be called an RFE, so the JEP is introducing bugs/technical debt/call it what you will. This should generally be part of a sandbox for the JEP and fixed before integration of the JEP.
>> From my point of view it is a blocker.
>
> The JEP isn't PTT for 17 so there's plenty of time isn't there ?

There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From redestad at openjdk.java.net  Thu May 20 10:45:37 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 20 May 2021 10:45:37 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ???????  wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589


From peter.firmstone at zeus.net.au  Thu May 20 10:53:28 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Thu, 20 May 2021 20:53:28 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
References: 
 
 
 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
Message-ID: <4999fbec-1a55-fdaf-b3bb-ec03773f1f6f@zeus.net.au>


On 18/05/2021 10:21 am, Ron Pressler wrote:
>> On 18 May 2021, at 01:11, Peter Firmstone  wrote:
>>
>> Your ideas are great in theory, in practice, the problem with your Agent proposal is every JVM release needs to be reviewed, and we have to review Java's internal implementation code, and understand it in order to instrument it.
> Absolutely. But that is exactly the work OpenJDK maintainers are required to do today to support something most
> people want better alternatives for at the expense of those better alternatives and other work.
>

The Principle of Least Privilege reduces the consequences resulting from 
attacks that penetrate external security defenses, whether by social 
engineering, failure to sanitize input, protocols, or platform 
vulnerabilities.


After many years of pain, JDK development work has not been wasted, I 
for one am grateful for the development efforts and thoughts put into 
securing the JVM.?? It is expensive and now your employer has decided 
they no longer wish to carry this expense, pushing it downstream.

Java has a proven and well tested security API, it's flaws are generally 
well understood.

At sometime in the future, Java's internal security defenses will be 
removed, and new code will no longer perform permission checks, so any 
breaches of external defenses will result in a JVM being Pwned.

After considering the proposals for new Security API, I have decided 
that the Java 1.8 to Java 1.17 versions will be the most suitable as it 
has the best well developed and understood security architecture, 
requiring little further development work.

The new proposals arising from this JEP present a significant 
development upgrade cost, and these new API's that we need to use for 
building new security architecture around, won't be battle hardened, are 
experimental and haven't passed the test of time.

My assessment is the cost to upgrade is too high and far too great a 
risk in this instance, the least cost and safest option is to stay with 
well proven, deployment tested, high performance, hardened existing API's.

I wish the OpenJDK project success in their future endeavors.? We will 
try to support later Java versions in Service implementations, similar 
to other languages, however these will not be able to consume other 
services.? This may enable users to take advantage of later language 
features.? However we will always require the use of Java 1.8 to 1.17 as 
service consumers.

I am grateful for the efforts, which appear to be thought of as wasted 
efforts or bad money, however this time spent addressing security 
issues, will leave the series of Java versions from 1.8 to 1.17 as some 
of the most secure versions of any software platform, as an asset of 
significant value to those who value security.

Thank you.

Peter Firmstone.





From adinn at redhat.com  Thu May 20 11:27:33 2021
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 20 May 2021 12:27:33 +0100
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>
 
 <25B49E78-4DA7-47F6-B01F-0093582B274E@oracle.com>
 
Message-ID: <911eab87-6fd5-9912-0392-4a6c9694d1d0@redhat.com>

On 18/05/2021 23:06, David Black wrote:
> I don't think that this thinking is unique but it might not be worth
> the "cost" to Oracle to maintain something that seemingly for various
> reasons Oracle has little interest in maintaining (we're not in
> applet-land anymore). I would like to encourage proposals that mean
> that people who want to do 4, who implement further security hardening
> where others seemingly shy away, can continue to do 4.
Please don't do that. The cost Ron is talking about is not to "Oracle". 
It is a cost to the OpenJDK project as a whole.

Likewise, the lack of project team interest in maintaining the security 
manager and self-evident interest in applying resources to providing 
other, more valuable Java capabilities is not simply restricted to 
"Oracle" project members.

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



From mcimadamore at openjdk.java.net  Thu May 20 13:05:22 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:05:22 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: 
References: 
Message-ID: 

> 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 35 additional commits since the last revision:

 - Add sealed modifiers in morally sealed API interfaces
 - Merge branch 'master' into JEP-412
 - Fix VaList test
   Remove unused code in Utils
 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - Take care of remaining references to "Panama"
 - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
   * Replace EntryBlob with OptimizedEntryBlob
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/788875f9...e927c235

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/f5668ffc..e927c235

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=22-23

  Stats: 7087 lines in 360 files changed: 4302 ins; 1796 del; 989 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


From mcimadamore at openjdk.java.net  Thu May 20 13:05:55 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:05:55 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: 
References: 
 
Message-ID: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>

On Thu, 20 May 2021 13:00:15 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 35 additional commits since the last revision:
> 
>  - Add sealed modifiers in morally sealed API interfaces
>  - Merge branch 'master' into JEP-412
>  - Fix VaList test
>    Remove unused code in Utils
>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>    
>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Merge branch 'master' into JEP-412
>  - Fix issue with bounded arena allocator
>  - Rename is_entry_blob to is_optimized_entry_blob
>    Rename as_entry_blob to as_optimized_entry_blob
>    Fix misc typos and indentation issues
>  - Take care of remaining references to "Panama"
>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>    * Replace EntryBlob with OptimizedEntryBlob
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/629f67e6...e927c235

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 200:

> 198:  * Implementations of this interface are immutable, thread-safe and value-based.
> 199:  */
> 200: public sealed interface MemoryLayout extends Constable permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout {

In principle we could just permit AbstractLayout and be done. In practice, the javadoc comes out better if we list all the concrete API interfaces which extend MemoryLayout, as the `permit` list will be displayed in the javadoc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 13:07:34 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 13:07:34 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-6K32RgKOwmXJztestBAA8OWC406eWVuqTRIjvfzcoQ=.59f5b0be-a1d9-48a8-89bd-5b7c51222bd7@github.com>

On Thu, 20 May 2021 10:42:49 GMT, Claes Redestad  wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8261880: Remove static from declarations of Holder nested classes
>
> Marked as reviewed by redestad (Reviewer).

@cl4es now you can sponsor :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589


From jvernee at openjdk.java.net  Thu May 20 13:12:26 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 20 May 2021 13:12:26 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>
References: 
 
 <0XX1uEuGfH11GkV08duVqk1u1vbP8IKAuZbf56JMKeY=.565f6565-3968-4f4f-ad10-de5dd6058e18@github.com>
Message-ID: 

On Thu, 20 May 2021 13:00:14 GMT, Maurizio Cimadamore  wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 35 additional commits since the last revision:
>> 
>>  - Add sealed modifiers in morally sealed API interfaces
>>  - Merge branch 'master' into JEP-412
>>  - Fix VaList test
>>    Remove unused code in Utils
>>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>>    
>>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>>  - Merge branch 'master' into JEP-412
>>  - Fix issue with bounded arena allocator
>>  - Rename is_entry_blob to is_optimized_entry_blob
>>    Rename as_entry_blob to as_optimized_entry_blob
>>    Fix misc typos and indentation issues
>>  - Take care of remaining references to "Panama"
>>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>>    * Replace EntryBlob with OptimizedEntryBlob
>>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/26a8cf83...e927c235
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 200:
> 
>> 198:  * Implementations of this interface are immutable, thread-safe and value-based.
>> 199:  */
>> 200: public sealed interface MemoryLayout extends Constable permits AbstractLayout, SequenceLayout, GroupLayout, PaddingLayout, ValueLayout {
> 
> In principle we could just permit AbstractLayout and be done. In practice, the javadoc comes out better if we list all the concrete API interfaces which extend MemoryLayout, as the `permit` list will be displayed in the javadoc.

At least the internal class name is hidden in the javadoc:
![image](https://user-images.githubusercontent.com/5962029/118983890-37042080-b97d-11eb-9ee0-ae5d5db5cd7e.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From mcimadamore at openjdk.java.net  Thu May 20 13:12:09 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 20 May 2021 13:12:09 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: 
References: 
 
Message-ID: <9PaAroygCBAEwYmF4lNFzy46QKSPJsET65dXf6XQs18=.9059eafa-0dae-4a6c-ab12-461bb6456b92@github.com>

On Thu, 20 May 2021 13:05:22 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 35 additional commits since the last revision:
> 
>  - Add sealed modifiers in morally sealed API interfaces
>  - Merge branch 'master' into JEP-412
>  - Fix VaList test
>    Remove unused code in Utils
>  - Merge pull request #11 from JornVernee/JEP-412-MXCSR
>    
>    Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Add MXCSR save and restore to upcall stubs for non-windows platforms
>  - Merge branch 'master' into JEP-412
>  - Fix issue with bounded arena allocator
>  - Rename is_entry_blob to is_optimized_entry_blob
>    Rename as_entry_blob to as_optimized_entry_blob
>    Fix misc typos and indentation issues
>  - Take care of remaining references to "Panama"
>  - * Replace is_panama_entry_frame() with is_optimized_entry_frame()
>    * Replace EntryBlob with OptimizedEntryBlob
>  - ... and 25 more: https://git.openjdk.java.net/jdk/compare/354e6edf...e927c235

Latest javadoc:
http://cr.openjdk.java.net/~mcimadamore/JEP-412/v3/javadoc/jdk/incubator/foreign/package-summary.html
Latest specdiff:
http://cr.openjdk.java.net/~mcimadamore/JEP-412/v3/specdiff/overview-summary.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From github.com+1324414+desruisseaux at openjdk.java.net  Thu May 20 13:18:36 2021
From: github.com+1324414+desruisseaux at openjdk.java.net (Martin Desruisseaux)
Date: Thu, 20 May 2021 13:18:36 GMT
Subject: RFR: 8261880: Change nested classes in java.base to static nested
 classes where possible [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 17 Feb 2021 16:38:03 GMT, ?????? ???????  wrote:

>> Non-static classes hold a link to their parent classes, which in many cases can be avoided.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8261880: Remove static from declarations of Holder nested classes

Just for information there is similar issues in `javax.imageio.metadata.IIOMetadataFormatImpl` class in the `java.desktop` module.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589


From github.com+10835776+stsypanov at openjdk.java.net  Thu May 20 13:59:41 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Thu, 20 May 2021 13:59:41 GMT
Subject: Integrated: 8261880: Change nested classes in java.base to static
 nested classes where possible
In-Reply-To: 
References: 
Message-ID: 

On Tue, 16 Feb 2021 14:30:58 GMT, ?????? ???????  wrote:

> Non-static classes hold a link to their parent classes, which in many cases can be avoided.

This pull request has now been integrated.

Changeset: 9425d3de
Author:    Sergey Tsypanov 
Committer: Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/9425d3de83fe8f4caddef03ffa3f4dd4de58f236
Stats:     15 lines in 11 files changed: 0 ins; 0 del; 15 mod

8261880: Change nested classes in java.base to static nested classes where possible

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/2589


From alanb at openjdk.java.net  Thu May 20 17:45:45 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 20 May 2021 17:45:45 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v24]
In-Reply-To: 
References: 
 <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com>
 
Message-ID: <8LA0NkO48Sxqf8ITGs8HWtyQhcr5oK5sbMBcYYOZCe0=.5c378205-caed-467e-9dc3-999b5dd54b05@github.com>

On Wed, 28 Apr 2021 08:20:05 GMT, Chris Hegarty  wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466:
>> 
>>> 464:     }
>>> 465: 
>>> 466:     private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess();
>> 
>> It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil.
>
> I went back and forth on this a number of times already. I think where we landed is a reasonable place, given the current shape of the code.
> 
> Scope is a private property of Buffer, and as such should be consulted anywhere where a buffer's address is being accessed. In fact, a prior prototype would not allow access to the underlying address value without the caller passing a valid handle for the buffer view's scope. It's hard to find the sweet-spot here between code reuse and safety, but the high-order bit is that the code accessing the address is auditable and testable to avoid accessing memory unsafely. Maybe there is a better alternative implementation code structure (at the cost of some duplication), but it is not obvious to me what that is (and I have given it some thought). Suggestions welcome.
> 
> Note, there is a little more follow-on work to be done in this area, if we are to expand support to other non-TCP channel implementations. Maybe investigation into possible code refactorings could be done as part of that?

Can you create a follow-on issue to re-visit the changes to IOUtil? The changes in this area that are in this PR will need to re-worked so that it more cleanly separate the synchronous and asynchronous usages.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3699


From kcr at openjdk.java.net  Thu May 20 18:31:33 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 20 May 2021 18:31:33 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: <58-JOVfSiUl3xFtcjGhwaviPqV-amDLlusvj_yCwmj8=.6d3bbada-4a59-443a-9940-121606b64a71@github.com>

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

This isn't a review of the code changes, although I did take a quick look at the manual changes, and they look fine.

I did a local build of the PR branch on Windows, Mac, and Linux, and then did a build / test of JavaFX using that locally built JDK to find all the places where I need to add `-Djava.security.manager=allow` to the JavaFX tests to fix [JDK-8264140](https://bugs.openjdk.java.net/browse/JDK-8264140). It's working as expected.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/4073


From ascarpino at openjdk.java.net  Thu May 20 21:09:34 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 20 May 2021 21:09:34 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: 

On Wed, 19 May 2021 18:15:26 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 279:
> 
>> 277:             if (iv.length == 0) {
>> 278:                 throw new InvalidAlgorithmParameterException("IV is empty");
>> 279:             }
> 
> Why separating the validation of iv and tag length in separate methods, i.e. engineInit() vs init()? Consider consolidating them?

I think I had a reason for this where I didn't know what the exact error was.  I'd rather keep them separate so it throws the right message for the error.  It's not a performance critical area.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Thu May 20 21:17:34 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 20 May 2021 21:17:34 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: 

On Wed, 19 May 2021 18:17:27 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 259:
> 
>> 257:     @Override
>> 258:     protected void engineInit(int opmode, Key key,
>> 259:         AlgorithmParameterSpec params, SecureRandom random)
> 
> The specified "random" is not saved to internal "random". Perhaps an oversight?

Yeah, I changed this code long ago, i suspect I didn't realize engineGetParameters() used it

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Thu May 20 23:20:40 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 20 May 2021 23:20:40 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: <863aV9irXc_UhU2Ug7w--ieSG-kaJXfv94h8aECUhMA=.9cfb5abf-34d0-49b4-9bca-9937932feafe@github.com>
References: 
 
 <863aV9irXc_UhU2Ug7w--ieSG-kaJXfv94h8aECUhMA=.9cfb5abf-34d0-49b4-9bca-9937932feafe@github.com>
Message-ID: 

On Tue, 18 May 2021 21:56:38 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 59:
> 
>> 57: final class GaloisCounterMode extends FeedbackCipher {
>> 58: 
>> 59:     static int DEFAULT_TAG_LEN = AES_BLOCK_SIZE;
> 
> Hmm, for the same reason as the DEFAULT_IV_LEN, you will probably need a DEFAULT_TAG_LEN. Otherwise, how do you know what the default tag length is after several Cipher.init() calls?

Yes, I can see where running init() on a previously used object can use the old tag

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Thu May 20 23:24:37 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 20 May 2021 23:24:37 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: <3itl0DpTNPw_DyWNuqYHgFIwq3zORbmd5HZQCjnPSH4=.b7c4b049-abad-4692-afb8-90c5c69f6fde@github.com>

On Tue, 18 May 2021 18:52:06 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 75:
> 
>> 73:     private GCMEngine engine;
>> 74: 
>> 75:     private boolean encryption = true;
> 
> Move these non-static fields to where they belong?

Do you mean below the static references?  I never noticed that as a style requirement

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Thu May 20 23:34:35 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Thu, 20 May 2021 23:34:35 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: 

On Tue, 18 May 2021 20:33:22 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 133:
> 
>> 131:             throw new InvalidKeyException("The key must be " +
>> 132:                 keySize + " bytes");
>> 133:         }
> 
> Set the keyValue to all 0s before throwing exception, i.e. try-finally.

If the key is not valid and never used, I don't see why it needs to be cleared.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Fri May 21 00:18:36 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 00:18:36 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: 

On Tue, 18 May 2021 21:58:24 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 149:
> 
>> 147:             if (spec == null) {
>> 148:                 throw new InvalidKeyException("No GCMParameterSpec specified");
>> 149:             }
> 
> This seems redundant as it's already been checked in engineInit() before calling this method. Line 154 directly calls spec.getTLen() without checking spec != null.

That does appear to be unnecessary. engineInit() make sure there is a spec exists.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Fri May 21 00:25:34 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 00:25:34 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: <-ksRyxcuYNr3G_WBHlZN-QWbrK8kH_FJGZjWNmUtXR8=.58e00289-8f0b-4298-9647-85f979768dc3@github.com>

On Tue, 18 May 2021 22:46:58 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 168:
> 
>> 166:     // return tag length in bytes
>> 167:     int getTagLen() {
>> 168:         return this.tagLenBytes;
> 
> Doesn't seem too useful if all it does is just returning the 'tagLenBytes' field? With your current code, tagLenBytes is initialized with 16 and is set in init(). When a GCMParameterSpec is not specified, it uses the tagLenBytes value from earlier init() instead of a fixed default. This seems incorrect?

Agreed.. I was probably trying to follow the getIv() idea, but never implemented it elsewhere

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From dblack at atlassian.com  Fri May 21 01:25:01 2021
From: dblack at atlassian.com (David Black)
Date: Fri, 21 May 2021 11:25:01 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <911eab87-6fd5-9912-0392-4a6c9694d1d0@redhat.com>
References: 
 <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>
 
 <25B49E78-4DA7-47F6-B01F-0093582B274E@oracle.com>
 
 <911eab87-6fd5-9912-0392-4a6c9694d1d0@redhat.com>
Message-ID: 

On Thu, 20 May 2021 at 21:27, Andrew Dinn  wrote:
>
> On 18/05/2021 23:06, David Black wrote:
> > I don't think that this thinking is unique but it might not be worth
> > the "cost" to Oracle to maintain something that seemingly for various
> > reasons Oracle has little interest in maintaining (we're not in
> > applet-land anymore). I would like to encourage proposals that mean
> > that people who want to do 4, who implement further security hardening
> > where others seemingly shy away, can continue to do 4.
> Please don't do that. The cost Ron is talking about is not to "Oracle".
> It is a cost to the OpenJDK project as a whole.

Sorry about that, that is a good point.

> Likewise, the lack of project team interest in maintaining the security
> manager and self-evident interest in applying resources to providing
> other, more valuable Java capabilities is not simply restricted to
> "Oracle" project members.
>
> 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
>


-- 
David Black / Security Engineer.


From peter.firmstone at zeus.net.au  Fri May 21 01:40:31 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 21 May 2021 11:40:31 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>
 
 <25B49E78-4DA7-47F6-B01F-0093582B274E@oracle.com>
 
 <911eab87-6fd5-9912-0392-4a6c9694d1d0@redhat.com>
 
Message-ID: <0cd12f78-49c1-a53f-2565-ee81eff470f1@zeus.net.au>

If there are those of us who wanted to maintain a fork of Java 17, 
focused on security, we could backport new features after they've been 
reviewed for security.

Would we be welcomed to do that here?? Otherwise is it something we 
should do on GitHub?

Cheers,

Peter.

On 21/05/2021 11:25 am, David Black wrote:
> On Thu, 20 May 2021 at 21:27, Andrew Dinn  wrote:
>> On 18/05/2021 23:06, David Black wrote:
>>> I don't think that this thinking is unique but it might not be worth
>>> the "cost" to Oracle to maintain something that seemingly for various
>>> reasons Oracle has little interest in maintaining (we're not in
>>> applet-land anymore). I would like to encourage proposals that mean
>>> that people who want to do 4, who implement further security hardening
>>> where others seemingly shy away, can continue to do 4.
>> Please don't do that. The cost Ron is talking about is not to "Oracle".
>> It is a cost to the OpenJDK project as a whole.
> Sorry about that, that is a good point.
>
>> Likewise, the lack of project team interest in maintaining the security
>> manager and self-evident interest in applying resources to providing
>> other, more valuable Java capabilities is not simply restricted to
>> "Oracle" project members.
>>
>> 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
>>
>
-- 
Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.



From weijun at openjdk.java.net  Fri May 21 01:58:47 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 01:58:47 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
Message-ID: 

The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/4073

Commit messages:
 - 8267521: Post JEP 411 refactoring: maximum covering > 50K

Changes: https://git.openjdk.java.net/jdk/pull/4138/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267521
  Stats: 226 lines in 18 files changed: 142 ins; 29 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138


From ascarpino at openjdk.java.net  Fri May 21 02:41:31 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 02:41:31 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: <1p5oeCfvxp9W5kcke78JkQLlw0qnQm9yahk049luKFU=.fab1d91e-7c56-48f9-a2ac-66e01b32f3d4@github.com>

On Tue, 18 May 2021 22:23:11 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 225:
> 
>> 223:     }
>> 224: 
>> 225:     SecureRandom random = null;
> 
> Is this field used? I didn't find any assignment. If it's needed, can you please move it to where the rest of fields are?

As part of your earlier comment, I realized it should be used when the user specifies a random.  I also moved it up to the top

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Fri May 21 02:54:54 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 02:54:54 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: 

On Wed, 19 May 2021 19:20:20 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 402:
> 
>> 400:         }
>> 401:         try {
>> 402:             ArrayUtil.nullAndBoundsCheck(input, inputOffset, inputLen);
> 
> Why is only this ArrayUtil.nullAndBoundsCheck(...) present in this engineDoFinal(...)? There are other engineUpdate/engineDoFinal() calls which also have input array, offset, and length. Shouldn't this check be added there as well? If the crypto engine check is separated out into a separate method, e.g. checkEngine(), then you don't have to explicitly release the crypto engine (as on line 405) and can just call checkEngine() after all the input validation has passed.

yeah these checks are a bit all over the place.. I'll rework them

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Fri May 21 02:54:53 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 21 May 2021 02:54:53 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 17 May 2021 21:58:48 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comment updates
>>  - Fixed the lack of overlap detection with GCMEncrypt.update()
>
> src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 54:
> 
>> 52:  * @since 1.8
>> 53:  */
>> 54: final class GCTR extends CounterMode implements GCM {
> 
> Not sure if this really needs to implements GCM?

Well, I see how you use this GCM interface now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Fri May 21 02:54:52 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 21 May 2021 02:54:52 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 19 May 2021 20:21:23 GMT, Anthony Scarpino  wrote:

>> Hi,
>> 
>> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix perf problem by reorganizing doLastBlock()

Here are comments on the remaining src changes. Will continue looking at the tests. 
Thanks,
Valerie

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 628:

> 626:         }
> 627: 
> 628:         int mergeBlock(byte[] buffer, int bufOfs, byte[] in, int inOfs,

Can be made 'static'? No javadoc for this one, maybe move the javadoc for the other one up and use "Methods" in the javadoc to cover both?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 637:

> 635:          * The method takes two buffers to create one block of data
> 636:          *
> 637:          * This in only called when buffer length is less that a blockSize

nit: typo in->is, that->than

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 640:

> 638:          * @return number of bytes used from 'in'
> 639:          */
> 640:         int mergeBlock(byte[] buffer, int bufOfs, int bufLen, byte[] in,

Can be made 'static'?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 648:

> 646: 
> 647:             System.arraycopy(buffer, bufOfs, block, 0, bufLen);
> 648:             int inUsed = Math.min(block.length - bufLen,

Seems equivalent to `int inUsed = Math.min((block.length - bufLen), inLen);`?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 741:

> 739:                         } else {
> 740:                             // If the remaining in buffer + data does not fill a
> 741:                             // block, complete the gctr operation

This comment seems more suited for the else block below at line 753. In addition, the criteria for completing the gctr operation should be whether src still has remaining bytes left. It's possible that the (src.remaining() == blockSize - over) and happen to fill up the block, right? The current flow for this particular case would be an op.update(...) then continue down to line 770-778, maybe you can adjust the if-check on line748 so this would go through line 754-759 and return, i.e. the else block?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 752:

> 750:                             if (dst != null) {
> 751:                                 dst.put(block, 0, blockSize);
> 752:                             }

not counting this blockSize value into "processed"?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 752:

> 750:                             if (dst != null) {
> 751:                                 dst.put(block, 0, blockSize);
> 752:                             }

Why not just do `op.update(block, 0, blockSize, dst); `?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 757:

> 755:                             if (dst != null) {
> 756:                                 dst.put(block, 0, Math.min(block.length, len));
> 757:                             }

Would this method work correctly if dst is null? Shouldn't this be checked in the beginning of this method?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 805:

> 803:         /**
> 804:          * This segments large data into smaller chunks so hotspot will start
> 805:          * using CTR and GHASH intrinsics sooner.  This is a problem for app

nit: typo: CTR->GCTR? This is to improve performance rather than a problem, no? Same comment applies to the other throttleData() method above.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 874:

> 872:             } else if (!src.isDirect() && !dst.isDirect()) {
> 873:                 // if src is read only, then we need a copy
> 874:                 if (!src.isReadOnly()) {

Do you mean if (src.hasArray() && dst.hasArray())? Even if src is not read only, but array()/arrayOffset() methods are optional and can only be safely invoked after the hasArray() call.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 908:

> 906:          * If an intermediate array is needed, the whole original out array
> 907:          * length is allocated because it's simpler than keep the same offset
> 908:          * and hope the expected output is

The comment seems incomplete? Perhaps you mean "if an intermediate array is needed, it will be allocated using the whole original out array length, so that the same out array offset can be used for code simplicity."

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 942:

> 940: 
> 941:             System.arraycopy(out, originalOutOfs, originalOut, originalOutOfs,
> 942:                 len);

Don't you need to do `originalOut = null;` after copying the bytes over? Otherwise, if you have two overlapping calls with the same engine, the 2nd restoreOut(...) call may lead to data corruption, i.e. it will duplicate the output bytes to the original output buffer (in the 1st overlapping call).
Same applies for the ByteBuffer case, i.e. restoreDst(...).
If time permits, please add a regression test to cover this.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 975:

> 973:                 doUpdate(in, inOff, inLen, output, 0);
> 974:             } catch (ShortBufferException e) {
> 975:                 // update decryption has no output

The comment does not seems to make sense? This is GCMEncrypt class. The right reason should be that the output array is allocated by the provider and should have the right size. However, it seems safer to throw AssertionException() instead of swallowing the SBE...

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1014:

> 1012:                     len += gctrghash.update(buffer, 0, bLen, out, outOfs);
> 1013:                     outOfs += bLen;
> 1014:                 }

For encryption, would the ibuffer contain more than one blocksize of data? Isn't the existing impl only put the remaining input (less than a block) into it? Line 1013: the `outOfs += bLen;`, shouldn't 'bLen' be 'len'?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1016:

> 1014:                 }
> 1015: 
> 1016:                 // blen is now the offset for 'buffer'

nit: typo, blen->bLen

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1030:

> 1028:                     inOfs += inLenUsed;
> 1029:                     inLen -= inLenUsed;
> 1030:                     outOfs += blockSize;

'blockSize' should be 'len'?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1033:

> 1031:                     ibuffer.reset();
> 1032:                     // Code below will write the remainder from 'in' to ibuffer
> 1033:                 } else if (remainder > 0) {

If bLen == 0, there is no need to put the rest of 'buffer' into 'ibuffer'.
It looks strange that the remaining buffer data is stored back into 'ibuffer', then the code proceeds to encrypt 'in' from line 1043-1046. This looks incorrect as all prior buffered input should be processed before process current input.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1036:

> 1034:                     // If a block or more was encrypted from 'buffer' only, but
> 1035:                     // the rest of 'buffer' with 'in' could not construct a
> 1036:                     //  block, then put the rest of 'buffer' back into ibuffer.

If 'ibuffer' is always less than a block long, then some of these are dead code and can be trimmed. Same goes for the doUpdate() w/ ByteBuffer arguments.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1044:

> 1042: 
> 1043:             // Encrypt the remaining blocks inside of 'in'
> 1044:             if (inLen > 0) {

If encrypting the remaining blocks, should use (inLen >= blockSize)?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1055:

> 1053:                 // remainder offset is based on original buffer length
> 1054:                 ibuffer.write(in, inOfs + inLen, remainder);
> 1055:             }

I wonder if these update(byte[], int, int, byte[], int) calls (such as the one on line 1045) should take ibuffer and stores the unprocessed bytes into it. This way seems more robust and you won't need separate logic. Same comment for the doUpdate() taking ByteBuffer arguments.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1163:

> 1161:                     r = doUpdate(buffer, 0, bufLen, out, outOfs);
> 1162:                     bufLen -= r;
> 1163:                     inOfs += r;

Would bufLen >= blockSize? Regardless, 'inOfs' should not be touched as 'in' is not used in the above doUpdate() call.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1174:

> 1172:                     inLen -= r;
> 1173:                     r = gctrghash.update(block, 0, blockSize, out,
> 1174:                         outOfs + resultLen);

I don't follow why you don't update the 'outOfs' after the line 1161 doUpdate() call and then add the resultLen when calling gctrhash.update(...) here. Seems fragile and difficult to maintain?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1184:

> 1182:                     block = new byte[bufLen + inLen];
> 1183:                     System.arraycopy(buffer, 0, block, 0, bufLen);
> 1184:                     System.arraycopy(in, inOfs, block, bufLen, inLen);

Not needed if inLen == 0.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1213:

> 1211: 
> 1212:             // copy the tag to the end of the buffer
> 1213:             System.arraycopy(block, 0, out, resultLen + outOfs, tagLenBytes);

Now that the tag is copied to the output, why not increment resultLen w/ tagLenBytes? This way, you don't have to keep repeating the (resultLen + tagLenBytes) for another two times?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1317:

> 1315:          * If tagOfs = 0, 'in' contains only the tag
> 1316:          * if tagOfs = blockSize, there is no data in 'in' and all the tag
> 1317:          *   is in ibuffer

Is this correct? mergeBlock() returns the number of used bytes from 'in', if no data is in 'in' and all the tag is from 'ibuffer', tagOfs should equal to -tagLenBytes. The next line should be moved up as the tag position gradually shifts from 'in' toward 'ibuffer'. The tagOfs for the next line should be -tagLenBytes < tagOfs < 0?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1401:

> 1399:             ShortBufferException {
> 1400:             GHASH save = null;
> 1401: 

Should do ArrayUtil.nullAndBoundsCheck() on 'in'?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1412:

> 1410:             }
> 1411: 
> 1412:             checkDataLength(len - tagLenBytes);

The impl of checkDataLength(...) is based on the "processed" variable which is always 0 for doUpdate() calls. This suits encryption better, but does not suit decryption? It seems that the doUpdate() calls would just keep buffering the data into 'ibuffer' without checking the size. It seems to me that this checkDataLength() call on line 1412 would always pass.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1437:

> 1435:             } catch (ArrayIndexOutOfBoundsException aiobe) {
> 1436:                 throw new ShortBufferException("Output buffer invalid");
> 1437:             }

I think this should be moved to the very beginning before all the processing and if the output capacity is less than 'len-tagLenBytes' value, then no need to proceed? IIRC, the save/restore is more for algorithms which use padding, may not be needed for GCM?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1442:

> 1440:                 throw new ShortBufferException("Output buffer too small, must" +
> 1441:                     "be at least " + (len - tagLenBytes) + " bytes long");
> 1442:             }

This looks like a half-baked save/restore functionality?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1475:

> 1473: 
> 1474:             // Length of the input
> 1475:             ByteBuffer tag;

Is the comment obsolete? I don't quite follow how it's related to 'tag'.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1503:

> 1501:                 tag.put(ct);
> 1502:                 tag.flip();
> 1503:                 // Limit is how much of the ibuffer has been chopped off.

The comment seems incorrect? Limit is not how much the ibuffer has been chopped off, but rather what has not been chopped off, no?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1510:

> 1508: 
> 1509:             // 'len' contains the length in ibuffer and src
> 1510:             checkDataLength(len);

Is this really useful given 'processed' is 0 and there is only one argument 'len'. Should always pass?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1515:

> 1513:             // the dst buffer is too short.  Context will be restored so the
> 1514:             // method can be called again with the proper sized dst buffer.
> 1515:             if (len > dst.remaining()) {

We should check the dst capacity in the beginning of the method, if its capacity is too small, i.e. less than the overall length - tag length, don't proceed further.
As in the doFinal() w/ byte[] arguments, I am not sure if the save/restore is really necessary.
Maybe add a test if it's not already covered by existing tests if time permits.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1557:

> 1555: 
> 1556:             // Decrypt the all the input data and put it into dst
> 1557:             //decryptBlocks(buffer, ct, dst);

nit: remove obsolete commented out code?

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1610:

> 1608:                     // update the input parameters for what was taken out of 'in'
> 1609:                     inOfs += inUsed;
> 1610:                     inLen -= inUsed;

This merge block code won't be needed if inLen == 0, i.e. can just assign in to be buffer, inOfs to 0, and inLen to bufRemaining.

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1615:

> 1613:                     if (inLen > 0) {
> 1614:                         int resultLen;
> 1615:                         resultLen = op.update(block, 0, blockSize,

nit: can just do `int resultLen = op.update(...);`

src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1665:

> 1663:     /**
> 1664:      * This class is for encryption operations when both GCTR and GHASH
> 1665:      * can operation in parallel.

nit: typo "operation"->"operate"

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 255:

> 253:         attrs.put("SupportedKeyFormats", "RAW");
> 254:         ps("Cipher", "DESedeWrap",
> 255:             "com.sun.crypto.provider.DESedeWrapCipher", null, attrs);

fix indentation to be consistent?

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 264:

> 262:                 "com.sun.crypto.provider.ARCFOURCipher", attrs);
> 263:         ps("Cipher", "AESWrap", "com.sun.crypto.provider.AESWrapCipher$General",
> 264:             null, attrs);

fix indentation to be consistent?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Fri May 21 03:10:36 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 03:10:36 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: 
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
 
Message-ID: <5bTZnp3tlrgGIqsD9zCO-ER22fOWrUkEBfDAqE8j7ag=.d0005d10-504a-45db-a917-fbc1d4da4764@github.com>

On Fri, 21 May 2021 02:51:05 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 402:
>> 
>>> 400:         }
>>> 401:         try {
>>> 402:             ArrayUtil.nullAndBoundsCheck(input, inputOffset, inputLen);
>> 
>> Why is only this ArrayUtil.nullAndBoundsCheck(...) present in this engineDoFinal(...)? There are other engineUpdate/engineDoFinal() calls which also have input array, offset, and length. Shouldn't this check be added there as well? If the crypto engine check is separated out into a separate method, e.g. checkEngine(), then you don't have to explicitly release the crypto engine (as on line 405) and can just call checkEngine() after all the input validation has passed.
>
> yeah these checks are a bit all over the place.. I'll rework them

So I think I only need to add a check to the engineDoFinal() that did not have a check before.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From peter.firmstone at zeus.net.au  Fri May 21 03:55:29 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 21 May 2021 13:55:29 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
Message-ID: 


On 18/05/2021 10:09 pm, Ron Pressler wrote:
>
>> On 18 May 2021, at 12:27, Peter Firmstone  wrote:
>>
>>
>> However I disagree that the Principle of least privilege is wrong headed, I think you've been discussing sandbox concepts with the experts and they're going to tell you that's a bad idea.  But the two aren't the same, one is access control, the other is attempted complete leak proof isolation,  which is a very difficult thing to do that grows exponentially with your API surface area, I'm sure in years to come crackers will find vulnerabilities in VM's too. Sandboxing would work if you removed most of the library code and features and limited memory and threads, but I don't think anyone is seriously considering that.  Java for applets should have been it's own stripped down limited JVM.
> When you say the ?principle of least privilege? you seem to imply that it is at *all* cost. Many believe that
> the attempt to assign different privileges to different *pieces of code* (not different people) is not effective
> from a cost/benefit perspective. In other words, the effort would have a bigger impact on security if directed
> elsewhere. After all, the same principle would imply that we?d need to afford different permissions at a method
> granularity rather than class granularity.


No, actually to date, it's been a very affordable option, probably 
because the burden has been on Openjdk developers to date, to which I'm 
very grateful.?? It doesn't impact performance and it allows me to 
reduce the attack surface of my programs, especially in regard to 
dependencies.


https://debricked.com/blog/2021/01/02/vulnerabilities-in-dependencies/


>> What sort of cost, you mean development cost, the cost of understanding doPrivileged?
> Both, but mostly the former.


Yes everything is a compromise and there are trade-offs.?? The way I see 
it, the cheapest way to maintain security is to find others who share a 
common pain point is to maintain a copy of OpenJDK? focused on 
security.?? We can audit upstream changes and add them later, with the 
security cost penalty, without throwing out the huge amount of effort 
performed by JDK developers over the years, there's no way we can 
re-implement it economically, so this appears the most sensible option.


>
>> At least to me, it's just a simple lambda expression, it's not difficult.  It think people are making this more complex than it needs to be due to a proliferation of Permissions, but even that I manage with tooling.
> There?s no point to argue over this. It?s been tried for a couple of decades, people don?t want it, experts say it?s
> not cost-effective, no popular platform after Java and .NET has chosen to invest in it, and .NET has dropped it already.
> Even if you convinced me that the effort of attempting to afford different permissions to different code in the same
> process was an effective use of resources, if you could have changed the habits of millions of developers you would
> have done it by now. You can carry on the argument over whether this is a good or bad idea on security forums and at
> security conferences, but that it didn?t pan out, adoption-wise, in practice is an empirical fact (that it's worked
> great *for you* is completely irrelevant). Even good ideas can fail to gain traction, and we shouldn?t throw good money
> after bad.


These are just opinions, it's nice to have them, but they're not 
helping.?? I think you'll find usages of SecurityManager api's are far 
more widespread than your opinion suggests, but that's just my opinion 
too lol.

You've probably have never used it, so you don't really understand it, I 
can't argue with ignorance and you can't understand the benefit, if you 
are only asking others for their opinions, you are likely surrounded by 
people with the same opinion, so you're suffering from confirmation bias 
without any practical application, as is anyone else that doesn't use it.

https://berteig.com/coaching/confirmation-bias/


>
>> But it's such a shame to lose access control as collateral damage.
> Most applications that do access control today do not use the Security Manager for that. When you say ?access control?
> you mean something very specific, which is not what others mean when they say access control. In particular, even doAs
> is proposed to remain.
>
>
> ? Ron


Yes, I think we should keep it simple, and keep calling it the principle 
of least privilege, to avoid confusion, it's very beneficial for 
reducing the consequences of perimeter security failure, even if your 
experts think otherwise.

-- 
Regards,
  
Peter Firmstone



From ascarpino at openjdk.java.net  Fri May 21 04:10:39 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 04:10:39 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 May 2021 21:18:27 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 640:
> 
>> 638:          * @return number of bytes used from 'in'
>> 639:          */
>> 640:         int mergeBlock(byte[] buffer, int bufOfs, int bufLen, byte[] in,
> 
> Can be made 'static'?

mergeBlock contains blockSize which isn't static

> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 648:
> 
>> 646: 
>> 647:             System.arraycopy(buffer, bufOfs, block, 0, bufLen);
>> 648:             int inUsed = Math.min(block.length - bufLen,
> 
> Seems equivalent to `int inUsed = Math.min((block.length - bufLen), inLen);`?

I think you're right.. and my main test seems to be ok with it too

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Fri May 21 04:18:41 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 04:18:41 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Wed, 19 May 2021 21:18:15 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 628:
> 
>> 626:         }
>> 627: 
>> 628:         int mergeBlock(byte[] buffer, int bufOfs, byte[] in, int inOfs,
> 
> Can be made 'static'? No javadoc for this one, maybe move the javadoc for the other one up and use "Methods" in the javadoc to cover both?

I just copied it and made a slight change to explain the difference

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Fri May 21 04:23:36 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 04:23:36 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 01:57:08 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1503:
> 
>> 1501:                 tag.put(ct);
>> 1502:                 tag.flip();
>> 1503:                 // Limit is how much of the ibuffer has been chopped off.
> 
> The comment seems incorrect? Limit is not how much the ibuffer has been chopped off, but rather what has not been chopped off, no?

I think it's which direction you are looking at it from, when I wrote this I was thinking how much of the ibuffer was chopped off into tag.. i can reword that because its ambiguous.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Fri May 21 04:31:36 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 04:31:36 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 01:58:43 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1510:
> 
>> 1508: 
>> 1509:             // 'len' contains the length in ibuffer and src
>> 1510:             checkDataLength(len);
> 
> Is this really useful given 'processed' is 0 and there is only one argument 'len'. Should always pass?

Are you asking if its necessary at all to check the length when decrypting?  That's a good question given it's encryption.  Maybe decryption doesn't need this check, only encryption.

If we do want to check it, then len could be greater than MAX_BUF_SIZE, then the exception would be thrown

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Fri May 21 04:50:33 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 04:50:33 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 02:03:56 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix perf problem by reorganizing doLastBlock()
>
> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 1515:
> 
>> 1513:             // the dst buffer is too short.  Context will be restored so the
>> 1514:             // method can be called again with the proper sized dst buffer.
>> 1515:             if (len > dst.remaining()) {
> 
> We should check the dst capacity in the beginning of the method, if its capacity is too small, i.e. less than the overall length - tag length, don't proceed further.
> As in the doFinal() w/ byte[] arguments, I am not sure if the save/restore is really necessary.
> Maybe add a test if it's not already covered by existing tests if time permits.

I think it can be moved up without doing any extra work
I'm pretty sure there is a test because I remember Sean C working on a bug with restoring when dst was too small.

> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 221:
> 
>> 219: 
>> 220:         store("AES/GCM", KnownOIDs.AES_128$GCM$NoPadding,
>> 221:             "AES/GCM/NoPadding");
> 
> In SunJCE class, the registration is done using "AES/GCM/NoPadding" instead of "AES/GCM". I am not sure why is this store() call using AES/GCM is necessary?

I will double check this, but I believe this change and the need for AESGCM in SunJCE are linked together

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ron.pressler at oracle.com  Fri May 21 08:58:25 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 21 May 2021 08:58:25 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <0C5B1C05-10BE-4776-9F4F-92CEEDD669F6@oracle.com>
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
Message-ID: 



> On 21 May 2021, at 04:55, Peter Firmstone  wrote:
> 
> 
> Yes everything is a compromise and there are trade-offs.   The way I see it, the cheapest way to maintain security is to find others who share a common pain point is to maintain a copy of OpenJDK  focused on security.   We can audit upstream changes and add them later, with the security cost penalty, without throwing out the huge amount of effort performed by JDK developers over the years, there's no way we can re-implement it economically, so this appears the most sensible option.
> 

That may be the way you see it, but I think you have to accept that many security experts don?t think
that focusing on the Security Manager and focusing on security are the same thing. We want to remove the 
SM *because* we want to focus on security measures that will have a larger impact in the real world. Even 
if you think that the SM is the best path to Java security you must accept that others do not, and that 
even if we?re misguided, we?re doing this because we believe it will help improve security, and that the 
SM harms it. So if you want to maintain the Security Manager in the JDK and ecosystem libraries, you can 
say so, but saying that that is ?focusing on security? is a mischaracterisation because it depends on
assertions that you know are controversial at the very least.

> 
> These are just opinions, it's nice to have them, but they're not helping.   I think you'll find usages of SecurityManager api's are far more widespread than your opinion suggests, but that's just my opinion too lol.

I guess you could say they?re my opinions because there is no conclusive proof, but they are based
on empirical data. At least you should scan GitHub and Maven Central. That few libraries are properly 
instrumented is yet another piece of evidence. This isn?t conclusive, and that is why we?re discussing
this here in an attempt to collect more information, but we have done our homework.

> 
> Yes, I think we should keep it simple, and keep calling it the principle of least privilege, to avoid confusion, it's very beneficial for reducing the consequences of perimeter security failure, even if your experts think otherwise.

It is absolutely not the principle of least privilege, which was formed long before the Security Manager
existed and is applied for all software, even that not written in Java (the last remaining mainstream platform 
with a mechanism that assigns permissions on a per-class basis). It is true that the SM allows smaller
units than the process or the user for the purpose of permissions, but if you think the principle means that
least privilege must be assigned at the smallest unit theoretically possible, then the Security Manager
doesn?t do that, and if you think it?s a matter of picking an effective unit granularity, then I believe
other measures apply it more effectively.

But there is something you keep missing here, and that is that the question of whether or not there are
circumstances in which the Security Manager will stop an attack ? and there are ? is irrelevant to the 
question of whether it is an effective security mechanism. That an elaborate trap will stop intruders who 
happen to try to enter my property at a specific spot doesn?t make it an effective mechanism, because a 
fence surrounding my property will stop even more intruders and do it more cheaply. ?Beneficial? for us 
doesn?t mean ?might help?, but what is the amount of total help offered per unit cost *compared to all 
other mechanisms? benefit per cost*. In other words, we ask ourselves, is the Security Manager the best 
thing to invest in if we want security compared to all other things we can invest in?

If your codebase is trusted, then what you want to defend against are accidental vulnerabilities, 
i.e. bugs. Suppose your application requires permissions X and Y to run. What the Security Manager 
allows you is to notice that your application is made of two components, A and B, and after analysis 
conclude that while A requires permissions X and Y, B requires only X, and to grant only X to B. This 
can preemptively prevent exploits in your application that: 1. target component B and 2. require permission 
X. How much is preventing this particular scenario worth and are there ways to prevent more?

Just as the Security Manager doesn?t find it a good tradeoff to separate A and B at a method granularity, 
we don?t think it?s a good tradeoff to separate them at a class granularity. Grant your entire process 
permissions X and Y, and monitor it. Modern detection methods can automatically detect an unusual behaviour 
if B attempts Y and alert you to fix the bug, and we prefer investing the very high effort of maintaining
the SM at reducing the attack surface area of the JDK overall, reducing the chance of attacks on either A 
or B, whether they require permissions X or Y, and also being always on for everyone. We believe this buys 
us *more* security for the same cost, and that is why newer Java versions will be more secure than previous 
ones.

? Ron

From peter.firmstone at zeus.net.au  Fri May 21 10:29:22 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 21 May 2021 20:29:22 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
Message-ID: 


On 21/05/2021 6:58 pm, Ron Pressler wrote:
>> These are just opinions, it's nice to have them, but they're not 
>> helping. I think you'll find usages of SecurityManager api's are far 
>> more widespread than your opinion suggests, but that's just my 
>> opinion too lol.
> I guess you could say they?re my opinions because there is no 
> conclusive proof, but they are based
> on empirical data. At least you should scan GitHub and Maven Central. 
> That few libraries are properly
> instrumented is yet another piece of evidence. This isn?t conclusive, 
> and that is why we?re discussing
> this here in an attempt to collect more information, but we have done 
> our homework.


Can you share this list please??? If I see anything missing I can add it 
for you.


>
>> Yes, I think we should keep it simple, and keep calling it the 
>> principle of least privilege, to avoid confusion, it's very 
>> beneficial for reducing the consequences of perimeter security 
>> failure, even if your experts think otherwise.
> It is absolutely not the principle of least privilege,

So I'm restricting permissions granted to only those required to perform 
the intended tasks of the software,? restricted even to a subset of 
which that software is capable, and you say it is not the principle of 
least privilege?

Please refer this policy file: 
https://www.dropbox.com/s/0w1c140zts93cmw/defaultnonactvm-policy.txt?dl=0

It's even specific to the JVM used, vendor, version and installation path.


Notice how the attached grants permission to code and principal? That 
means the code without the Principal cannot attain that privilege, nor 
can the Principal use that permission without the specified code?

This means if an attacker breaches peripheral protection systems, such 
as authentication, they can not perform anything that requires 
permission outside of the granted scope?

I execute exactly the code paths I want executed, with the user role I 
want to perform that task, I grant only the permissions required to 
perform the intended task.

How is this absolutely not the principle of least privilege?

> Java (the last remaining mainstream platform
> with a mechanism that assigns permissions on a per-class basis).

Java Policy doesn't assign permissions on a per-class basis, it assigns 
them by ProtectionDomain, or by ClassLoader, or by CodeSource, or by 
Signer Certificates, or by Principal, or by a combination of Principal's 
and (ProtectionDomain or ClassLoader or CodeSource, or signer 
Certificates) and Certificates.? I don't really want to document all the 
possibilities here if yo don't mind.

How do you critique something if you don't understand how it works?

With test cases, I can generate policy files for the principle of least 
privilege for any Java software, including dependencies.

Not only that, but I do it without impacting performance or scalability.

Show me some evidence for your arguments, name your experts you speak of 
so often.

If you are going to argue, back it up with hard evidence, not nonsense.

I provide you with hard evidence, show me the same courtesy and respect 
please.

I'm not seeing any evidence that you have done much homework at all sir?

Previously you claimed SecurityManager didn't even work, that a 
Doctorate in Nuclear particle physics was required to use it.

I don't wish to publicly show that I doubt your credibility, but you are 
making it difficult for me not to sir.? It is your user base you need to 
convince, so far, you are not very convincing.


-- 
Respectfully,

Peter Firmstone




From dalibor.topic at oracle.com  Fri May 21 10:47:52 2021
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Fri, 21 May 2021 12:47:52 +0200
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <0cd12f78-49c1-a53f-2565-ee81eff470f1@zeus.net.au>
References: 
 <815A8F92-2057-413E-B3A3-712E301BB07C@oracle.com>
 
 <25B49E78-4DA7-47F6-B01F-0093582B274E@oracle.com>
 
 <911eab87-6fd5-9912-0392-4a6c9694d1d0@redhat.com>
 
 <0cd12f78-49c1-a53f-2565-ee81eff470f1@zeus.net.au>
Message-ID: <50b82fdf-b098-7576-06fa-c107e43cba23@oracle.com>

On 21.05.2021 03:40, Peter Firmstone wrote:
> If there are those of us who wanted to maintain a fork of Java 17, 
> focused on security, we could backport new features after they've been 
> reviewed for security.
> 
> Would we be welcomed to do that here?? Otherwise is it something we 
> should do on GitHub?

Once a Project Lead resigns, or in the case of a repository in the JDK 
Updates Project, a repository lead maintainer resigns, someone 
sufficiently qualified to do so is welcome to step up and continue 
maintaining a release under the umbrella of the JDK Updates Project.

Please see http://openjdk.java.net/projects/jdk-updates/maintainers.html 
for details, and keep in mind that as any process, it's open to change 
through discussion on the jdk-updates-dev mailing list.

Ideas like differently focused repositories were discussed for JDK 11 in 
the past on that list, but the discussion was inconclusive, fwiw. It's 
worth keeping in mind that adequately maintaining an update release is 
by no means a trivial affair, and as such, there is usually little 
desire in the long run to balkanize the comparatively sparse community 
of OpenJDK update release maintainers across vastly different 
approaches, even if that may initially seem appealing for various reasons.

cheers,
dalibor topic


-- 
 Dalibor Topic
Consulting Product Manager
Phone: +494089091214 , Mobile: +491737185961
, Video: dalibor.topic at oracle.com


Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann



From ron.pressler at oracle.com  Fri May 21 11:14:03 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 21 May 2021 11:14:03 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
Message-ID: <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>



> On 21 May 2021, at 11:29, Peter Firmstone  wrote:
> 
> 
> Can you share this list please?   If I see anything missing I can add it for you.

No, because this might give the false impression that this is a debate. In a community
of millions, almost no decision will be universally accepted. So the goal here is to collect
information and have people try to convince the maintainers, not the other way around.

This is the only way to not get into interminable debates and to get things done. At the end of 
the day, either you trust that our intentions is to make Java more secure and more successful or 
you don?t. We hope that the majority of Java users do.

> 
> So I'm restricting permissions granted to only those required to perform the intended tasks of the software,  restricted even to a subset of which that software is capable, and you say it is not the principle of least privilege?

That is not what the Security Manager is doing, though. It is able to assign ?least privilege? to some
arbitrary level of granularity and not others. Other techniques apply the same principle at different
granularities.

> 
> How do you critique something if you don't understand how it works?

I stand by what I said. ?X granularity? means up-to and no-less-than X, and assigning software privileges
per user at the application level does not require the Security Manager. I understand that your particular
codebase does use the Security Manager to assign all software privileges, and that removing it might require
costly changes to your codebase, but that is not the most common way, and it is certainly not the *only*
way this is done in Java codebases. I absolutely sympathise with the pain this proposal would cause you,
but please sympathise with the pain that not accepting it would cause what we believe is a far greater
number of people, and don?t try to universalise your particular situation.

So you are mistaken about what it is that I am critiquing. I am not critiquing the operation of the 
Security Manager nor am I saying that it is incapable of preventing certain attacks. I am critiquing the 
claim that no other technique can achieve better security more cheaply. I am saying that the marginal utility 
if the Security Manager divided by its marginal cost is lower than the marginal utility divided by the marginal 
cost of other security techniques.

We have no argument over the value of security or that of the principle of least privilege.
We merely disagree over whether the Security Manager specifically is the best possible means to those ends.

> 
> I don't wish to publicly show that I doubt your credibility, but you are making it difficult for me not to sir.  It is your user base you need to convince, so far, you are not very convincing.
> 

I am sorry, but that not everyone would be convinced by every argument we make is something we take as a given.
It is the duty of those who disagree with proposals put forth by the maintainers to convince the maintainers,
not the other way around. I am trying to help you focus you on arguments that would be relevant. They are:


1. The *current* value the Security Manager to the Java ecosystem is high, evidenced by the great number of 
   companies that employ it for software security.

2. The Security Manager has the highest ROI compared to all other approaches.

Our assumption is that both 1 and 2 are false. If you?d like to convince the maintainers, support one or both 
of these arguments. Any other is irrelevant, because true or not it has no bearing on the proposal.

Short of that, my intention is not to convince you, because I agree that this proposal would harm you (even
though I believe it will help increase security for the Java ecosystem as a whole), and for that, I am truly 
sorry. My intention is to try to focus on productive avenues that might lessen that harm.


? Ron

From pconcannon at openjdk.java.net  Fri May 21 11:26:56 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 21 May 2021 11:26:56 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications
 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Update java.util to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4088/files
  - new: https://git.openjdk.java.net/jdk/pull/4088/files/cd99dc49..da615e7d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=01-02

  Stats: 4905 lines in 201 files changed: 2421 ins; 2058 del; 426 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088

PR: https://git.openjdk.java.net/jdk/pull/4088


From peter.firmstone at zeus.net.au  Fri May 21 11:52:25 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 21 May 2021 21:52:25 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
References: 
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
Message-ID: <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>


On 21/05/2021 9:14 pm, Ron Pressler wrote:
>
>> On 21 May 2021, at 11:29, Peter Firmstone  wrote:
>>
>>
>> Can you share this list please?   If I see anything missing I can add it for you.
> No, because this might give the false impression that this is a debate.


It's quite clear this will be pushed through anyway, so there's no harm 
in sharing the information, unless you don't have a list, in which case 
it's not possible to share something you don't have.


>
>> So I'm restricting permissions granted to only those required to perform the intended tasks of the software,  restricted even to a subset of which that software is capable, and you say it is not the principle of least privilege?
> That is not what the Security Manager is doing, though. It is able to assign ?least privilege? to some
> arbitrary level of granularity and not others.


The granularity is not arbitrary, you said by class, which is incorrect.

Granularity is by a combination of one or more of the following:

 1. ProtectionDomain
 2. CodeSource
 3. Code signers
 4. ClassLoader
 5. Principals.

>> How do you critique something if you don't understand how it works?
> I stand by what I said. ?X granularity? means up-to and no-less-than X, and assigning software privileges
> per user at the application level does not require the Security Manager. I understand that your particular
> codebase does use the Security Manager to assign all software privileges, and that removing it might require
> costly changes to your codebase, but that is not the most common way, and it is certainly not the *only*
> way this is done in Java codebases. I absolutely sympathise with the pain this proposal would cause you,
> but please sympathise with the pain that not accepting it would cause what we believe is a far greater
> number of people, and don?t try to universalise your particular situation.


You said class level granularity, which is incorrect.?? True, it is not 
possible to upgrade, I guess you could say that's painful, as it will be 
for everyone else caught up by it.

I would like to understand this pain that is being caused to a far 
greater number of people??? So far information has been scarce and it 
seems more of an excuse, as it's very light on detail.? I would guess 
it's the pain of having to update policy files and making sure tests 
pass with security enabled.

I perform all tests with security enabled, because it will work if it 
isn't anyway.?? Policy files are easily regenerated using tools.

What other pain is there?

I think the results of locking down the JVM to principles of least 
privilege are totally worth it and a saleable commodity in the current 
global environment.


>
> So you are mistaken about what it is that I am critiquing. I am not critiquing the operation of the
> Security Manager nor am I saying that it is incapable of preventing certain attacks. I am critiquing the
> claim that no other technique can achieve better security more cheaply.


Sure, theoretical things might, but there's no implementation in 
existence.? It has been quite affordable for me, so I wish to understand 
this pain, because I currently don't, I'm already using the latest 
encryption, static analysis, secure coding practices, validating input, 
sanitizing data etc.


>   I am saying that the marginal utility
> if the Security Manager divided by its marginal cost is lower than the marginal utility divided by the marginal
> cost of other security techniques.


Other techniques that are yet to be developed.?? OpenJDK is deprecating 
SecurityManager prior to the implementation of it's replacement, a 
little more notice would have been nice.?? I'm ready for you to 
deprecate Serialization, we saw that coming, but this is just completely 
unexpected out of left field.


>
> We have no argument over the value of security or that of the principle of least privilege.
> We merely disagree over whether the Security Manager specifically is the best possible means to those ends.


Currently it is the only possible and practicable means that has been 
implemented, I'm sure something better will come along, but everything 
better is just theoretical at this time.

Nothing else is even remotely capable of locking the JVM down this 
securely.


>
>> I don't wish to publicly show that I doubt your credibility, but you are making it difficult for me not to sir.  It is your user base you need to convince, so far, you are not very convincing.
>>
> I am sorry, but that not everyone would be convinced by every argument we make is something we take as a given.
> It is the duty of those who disagree with proposals put forth by the maintainers to convince the maintainers,
> not the other way around. I am trying to help you focus you on arguments that would be relevant. They are:
>
>
> 1. The *current* value the Security Manager to the Java ecosystem is high, evidenced by the great number of
>     companies that employ it for software security.
>
> 2. The Security Manager has the highest ROI compared to all other approaches.
>
> Our assumption is that both 1 and 2 are false. If you?d like to convince the maintainers, support one or both
> of these arguments. Any other is irrelevant, because true or not it has no bearing on the proposal.
>
> Short of that, my intention is not to convince you, because I agree that this proposal would harm you (even
> though I believe it will help increase security for the Java ecosystem as a whole), and for that, I am truly
> sorry. My intention is to try to focus on productive avenues that might lessen that harm.
>
>
> ? Ron

This is not new software, these justifications are for new features, and 
would have been originally considered, now it has become a backward 
compatibility and functionality issue, no replacement functionality is 
available.

I don't see how you can argue there are better ways if they don't exist.

This is a breaking change to Java, so after this JEP, you should be 
releasing Java 2.0.

-- 
Regards,
  
Peter Firmstone
Zeus Project Services Pty Ltd.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ron.pressler at oracle.com  Fri May 21 13:06:00 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 21 May 2021 13:06:00 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
References: 
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
 <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
Message-ID: <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>



> On 21 May 2021, at 12:52, Peter Firmstone  wrote:
> 
> It's quite clear this will be pushed through anyway,
> 

No, not *anyway*, but given the fact that the community consists of millions of users, this
proposal has been well-publicised, only very few people have voiced objections, fewer
still who have voiced objections actually use the Security Manager for security, and no
one has yet made a single relevant argument, accepting this proposal so far seems like the
only reasonable outcome, perhaps with accommodations to offer alternatives for certain
use-cases. 

> so there's no harm in sharing the information, unless you don't have a list, in which case it's not possible to share something you don't have.

I have already linked to one empirical study, I know that further scans of public repositories
have been conducted but *I* don?t have the data; those who do are free to share it if they
think there is no harm in that (although I think there might be).

> 
> The granularity is not arbitrary, you said by class, which is incorrect.
> 
> Granularity is by a combination of one or more of the following:
> 
> 	? ProtectionDomain
> 	? CodeSource
> 	? Code signers
> 	? ClassLoader
> 	? Principals.

What I said is correct. Assigning a ProtectionDomain to a class is possible, though not to a method 
(certainly not in code you can?t modify). In fact, ProtectionDomain is defined as ?a set of classes,?
i.e. class granularity. In particular, that is the granularity that instrumentation with doPrivileged 
aims to address, and that is one of the Security Manager?s most defining features.

Restricting access by principal at the application level does not require the Security Manager, so that 
part is irrelevant, and, in fact, not only Principal, but also Permission, and even CodeSource and 
ProtectionDomain are *not* being proposed for terminal deprecation or even deprecation by this JEP.

> 
> I would like to understand this pain that is being caused to a far greater number of people?   So far information has been scarce and it seems more of an excuse, as it's very light on detail.  I would guess it's the pain of having to update policy files and making sure tests pass with security enabled.

The pain is that the high cost of maintaining the Security Manager comes at the expense of
other security measures that, we believe, provide far more security value to the Java ecosystem
as a whole.

> 
> I think the results of locking down the JVM to principles of least privilege are totally worth it and a saleable commodity in the current global environment.

I absolutely accept the principle of least privilege. I do not accept that the marginal cost/benefit
of applying it at class granularity yields its best application.

> 
> Sure, theoretical things might, but there's no implementation in existence.  It has been quite affordable for me, so I wish to understand this pain, because I currently don't, I'm already using the latest encryption, static analysis, secure coding practices, validating input, sanitizing data etc.

There are, though. Here are some: JFR, the module system, crypto protocols and ad-hoc mechanisms for 
specific vulnerable components (serialization, XML etc.). Maintaining the Security Manager comes at their 
expense -- some require urgent improvements like adding more events to JFR and closing down gaps in the 
module system?s defences -- and we believe investing in them has a better security ROI overall.

> 
> Other techniques that are yet to be developed.   OpenJDK is deprecating SecurityManager prior to the implementation of it's replacement, a little more notice would have been nice.   I'm ready for you to deprecate Serialization, we saw that coming, but this is just completely unexpected out of left field.

First, any deprecation proposal could be said to be unexpected until it is proposed. But that is why 
we have a deprecation policy that makes the process gradual and gives people time to adjust. Second, I
don?t think this is "out of left field" at all. The writing on the wall was pretty clear when, after twenty-five 
years, few projects use the Security Manager and few libraries are properly instrumented for it, other platforms 
have decided not to adopt a similar model, and those few that have have already abandoned it some years ago.

> 
> Currently it is the only possible and practicable means that has been implemented, I'm sure something better will come along, but everything better is just theoretical at this time.
> 
> Nothing else is even remotely capable of locking the JVM down this securely.

I?m sure you're responding to *some* argument, but not to mine. Any additional security measure would 
?lock something down? more than not having it. Whether or not it is worthwhile depends on the marginal 
benefit vs. the marginal cost. I believe that the marginal benefit for the marginal cost of the Security 
Manager with respect to the existing measures I listed above (and which are constantly improved) is low, 
lower still considering how rarely it is actually employed in the field.

If we could invest as much as we want in those mechanisms and *also* have the Security Manager for those
few who use it for additional security, however small, we would; but we can?t. For a given investment,
the other mechanisms protect the Java ecosystem overall better than the Security Manager.

> This is not new software, these justifications are for new features, and would have been originally considered, now it has become a backward compatibility and functionality issue, no replacement functionality is available.

No, they are not. They specifically concern the *current* value of the Security Manager rather than
some future value. And while there is no replacement *to that particular security model* ? because
we believe, like other platforms, that it fundamentally offers a bad ROI, not only are there alternative
measures to securing Java applications, but most applications have been relying on them rather than on
the Security Manager for years.

> 
> I don't see how you can argue there are better ways if they don't exist.

They do; I listed some of them.

> 
> This is a breaking change to Java, so after this JEP, you should be releasing Java 2.0.

It absolutely is a breaking change, but it is hardly the first, nor is it even the biggest (that
would be, I think, the removal of Applets). This isn?t even the only ?breaking" JEP proposed to target 17.

We make intentional breaking changes when the number of those affected is small, and when the cost of 
maintaining a feature far outweighs the value it brings to the ecosystem as a whole. When we do, there 
is always some non-zero number of people who are harmed, but because such features incur a constant cost 
that comes at the expense of other things, we don?t remove unless we think more people would be harmed by 
keeping the feature.

We recognised some years ago that *sometimes* the most appropriate course of action, the one that yields the 
greater good for the greater number, all things considered, is to make breaking changes. Not making intentional
breaking changes ever might have been a viable strategy in Java?s first decade or so, but as time passes and
obsolete/abandoned/disused features accumulate, it no longer is. Still, we do our best to minimise the harm.

I saw that you?ve come to the conclusion that the best course of action for you would be to invest
in maintaining old Java versions. I would just like to suggest that you stay open to other possibilities
of providing good security without the Security Manager, as you might find cheaper options (consider that 
the small number of libraries instrumented for the Security Manager will diminish further once it is removed, 
so you?ll have more than just the JDK to maintain, and even that is a large undertaking). As I already 
mentioned before, think of suggestions you could make that might be acceptable and would reduce the impact to 
you. I think you?ve already made one.

? Ron


From weijun at openjdk.java.net  Fri May 21 14:00:39 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 14:00:39 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: 
References: 
Message-ID: 

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  typo on windows

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/e3f0405a..d460efb8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138


From pconcannon at openjdk.java.net  Fri May 21 14:00:43 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Fri, 21 May 2021 14:00:43 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` 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:

  8267110: Reverted changes made to files in java.util.concurrent

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4088/files
  - new: https://git.openjdk.java.net/jdk/pull/4088/files/da615e7d..2c076a55

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=02-03

  Stats: 31 lines in 5 files changed: 16 ins; 0 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088

PR: https://git.openjdk.java.net/jdk/pull/4088


From dfuchs at openjdk.java.net  Fri May 21 15:36:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:36:08 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

src/java.base/share/classes/java/lang/SecurityManager.java line 104:

> 102:  * method will throw an {@code UnsupportedOperationException}). If the
> 103:  * {@systemProperty java.security.manager} system property is set to the
> 104:  * special token "{@code allow}", then a security manager will not be set at

Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From dfuchs at openjdk.java.net  Fri May 21 15:55:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 21 May 2021 15:55:07 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 14:00:39 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   typo on windows

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:

> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
> 120:                     }

It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:

> 548:      * @throws IOException if the connection was unsuccessful.
> 549:      */
> 550:     @SuppressWarnings("removal")

Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 921:

> 919:     }
> 920: 
> 921:     @SuppressWarnings("removal")

Could the scope be further reduced by applying it at line 926 in this method - at the cost of creating a temporary variable? The code could probably be further simplified by using a lambda...


            PrivilegedAction pa = () -> new Socket(proxy);
            @SuppressWarnings("removal")
            var ps = AccessController.doPrivileged(pa);
            s = ps;

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From msterner at openjdk.mxy.se  Fri May 21 17:33:50 2021
From: msterner at openjdk.mxy.se (Mikael Sterner)
Date: Fri, 21 May 2021 19:33:50 +0200
Subject: JEP 411: Disable warning message with flag?
Message-ID: 

The current version of JEP 411 (Deprecate the Security Manager for Removal) has as its goal "Warn users if their Java applications rely on the Security Manager.". To that end it proposes to "Issue a warning message at startup if the Security Manager is enabled on the command line."

I would suggest adding a flag to disable the warning message, for use in cases where an application ships to end users with a Java runtime included. Because in those cases, the warning is meant for the developer of the application and not end users. End users would not be the ones providing/upgrading the Java runtime, and in many cases it would not be acceptable to have a warning displayed on startup that could confuse users.

If a flag to disable the command line warning is not added, the effect will be that the Security Manager is not possible to use in such applications already in Java 17 (counting on the proposed target), which seems rather harsh given the short notice.

If the flag is added, developers of applications that use the Security Manager will still notice the warning (until disabled) but they get more time to migrate to better solutions like process isolation. As a bonus, for hard-to-migrate cases you can stay on Java 17 with the Security Manager for as long as you're willing to pay, since many vendors seem to plan to offer long term support for it.

Yours,
Mikael Sterner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From prr at openjdk.java.net  Fri May 21 18:03:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:03:01 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
 
Message-ID: 

On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman  wrote:

>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class level is introducing technical debt but if addressing that requires refactoring and re-testing of AWT or font code then it would be better to have someone from that area working on. Is there any reason why this can't be going on now on awt-dev/2d-dev and integrated immediately after JEP 411? I don't think we should put Max through the wringer here as there are too many areas to cover.

Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
It is very straight forward to run the automated tests across all platforms these days.
I get the impression that no one is guaranteeing to do this straight after integration.
It sounds like it is up for deferral if time runs out.

The amount of follow-on work that I am hearing about here, and may be for tests, does not  make it sound
like this JEP is nearly as done as first presented.

If there was some expectation that groups responsible for an area would get involved with this
issue which I am assured was already known about, then why was it not raised before and made
part of the plan ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From prr at openjdk.java.net  Fri May 21 18:31:01 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 18:31:01 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: 
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
Message-ID: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>

On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang  wrote:

>> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
>> 
>> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
>> 
>> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
>> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
>> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
>> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
>> 
>> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
>> 
>> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
>> 
>> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
>> 
>> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
>> 
>> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
>> 
>> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
>> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>>  ```
>> 
>> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust order of VM options

The client changes are fine except for the one misplaced (c)

test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

Probably the (c) update was meant to be on the .sh file that is actually modified.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4071


From weijun at openjdk.java.net  Fri May 21 19:50:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 19:50:15 GMT
Subject: RFR: 8267184: JEP 411: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager [v2]
In-Reply-To: <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
 
 <4w0JvyhZ5Kx5a_qqKvyBYBOw0thtX4_wBTtk1bDgsfw=.1665918a-092c-4b7e-a48e-5fc9810b9e0b@github.com>
Message-ID: 

On Fri, 21 May 2021 18:26:48 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust order of VM options
>
> test/jdk/java/awt/FontClass/CreateFont/fileaccess/FontFile.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.
>> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> 
> Probably the (c) update was meant to be on the .sh file that is actually modified.

Oops, I'll back it out. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071


From weijun at openjdk.java.net  Fri May 21 20:01:15 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:01:15 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v3]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  feedback from Phil
  
  reverted:

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/bfa955ad..9a3ec578

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071


From weijun at openjdk.java.net  Fri May 21 20:18:58 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:18:58 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: <-G6LsP9NmgT4W265oaeXphH-xSg2U-9ofbhBlay7_-w=.0241068a-301f-4f94-802e-69a8adb545a4@github.com>

On Fri, 21 May 2021 15:35:05 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 120:
> 
>> 118:                         vals[1] = Integer.getInteger("sun.net.client.defaultConnectTimeout", 300_000).intValue();
>> 119:                         return System.getProperty("file.encoding", "ISO8859_1");
>> 120:                     }
> 
> It is a bit strange that "file.encoding" seem to get a special treatment - but I guess that's OK.

You might say we thus avoid wasting the return value, as much as possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From weijun at openjdk.java.net  Fri May 21 20:23:14 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:23:14 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Fri, 21 May 2021 15:37:48 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   typo on windows
>
> src/java.base/share/classes/sun/net/ftp/impl/FtpClient.java line 550:
> 
>> 548:      * @throws IOException if the connection was unsuccessful.
>> 549:      */
>> 550:     @SuppressWarnings("removal")
> 
> Could the scope of the annotation be further reduced by applying it to the two places where `doPrivileged` is called in this method?

I'll probably need to assign the doPriv result on L631 to a tmp variable and then assign it to `s`. Are you OK with this ugliness? Update: Ah, I see you already have similar suggestion in the next comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From weijun at openjdk.java.net  Fri May 21 20:37:30 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:37:30 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
Message-ID: 

> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
> 
> The code change shows some common solutions to avoid such too wide annotations:
> 
> 1. Extract calls into a method and add annotation on that method
> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
> 3. Put declaration and assignment into a single statement if possible.
> 4. Rewrite code to achieve #3 above.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  update FtpClient.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4138/files
  - new: https://git.openjdk.java.net/jdk/pull/4138/files/d460efb8..60d97a4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4138&range=01-02

  Stats: 23 lines in 1 file changed: 0 ins; 12 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4138.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4138/head:pull/4138

PR: https://git.openjdk.java.net/jdk/pull/4138


From prr at openjdk.java.net  Fri May 21 20:46:03 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 21 May 2021 20:46:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>
>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java

test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:

> 57:                 ProcessCommunicator
> 58:                         .executeChildProcess(Consumer.class, new String[0]);
> 59:         if (!"Hello".equals(processResults.getStdOut())) {

Who or what prompted this change ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Fri May 21 20:55:02 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 21 May 2021 20:55:02 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 20:43:05 GMT, Phil Race  wrote:

> I haven't seen any response to this comment I made a couple of days ago and I suspect it got missed
> 
> > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> > fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
> 
> test/jdk/java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java line 59:
> 
> > 57:                 ProcessCommunicator
> > 58:                         .executeChildProcess(Consumer.class, new String[0]);
> > 59:         if (!"Hello".equals(processResults.getStdOut())) {
> 
> Who or what prompted this change ?

I replied right in the thread but unfortunately GitHub does not display it at the end of page.

This is because the process is now launched with `-Djava.security.manager=allow` (because of another change in https://github.com/openjdk/jdk/pull/4071), and a new warning is displayed in stderr. Therefore I switched to stdout.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From xuelei at openjdk.java.net  Fri May 21 21:01:14 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 21 May 2021 21:01:14 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
Message-ID: 

On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng  wrote:

>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>> 
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
>> 
>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge master into JDK-8248268
>  - Minor update to address review comments.
>  - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>    KWParameters and KWPParameters.
>  - Refactor code to reduce code duplication
>    Address review comments
>    Add more test vectors
>  - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>    AES/KWP/NoPadding
>  - Restored Iv algorithm parameters impl.
>  - 8248268: Support KWP in addition to KW
>    
>    Updated existing AESWrap support with AES/KW/NoPadding cipher
>    transformation. Added support for AES/KWP/NoPadding and
>    AES/KW/PKCS5Padding support to SunJCE provider.

src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:

> 48: 
> 49:     public AESParameters() {
> 50:         core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);

A cipher object may not take different IV sizes at the same time.  I was just wondering how it could be used in practice.  Maybe something like:


AlgorithmParameters algParams = AlgorithmParameters.getInstance("AES");
algParams.init(ivParameterSpec);

The IV parameter is given with the init() method.  Then, it may be not necessary to construct the BlockCipherParamsCore object will all potential IV sizes.  See the comments in BlockCipherParamsCore.

src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 52:

> 50:     private byte[] iv = null;
> 51: 
> 52:     private int[] moreSizes = null;

The moreSizes is not used other than the init() method field.  It may be not easy to check the specific size if we cache all supported sized in the object.  For example, if the required IV size if 8 bytes, it may be a problem about how to make sure the iv size is 8 bytes exactly for a specific algorithm.

Maybe, we could just have a ivSize filed.  The default value is block_size, which coupe be set with the init(ivParameterSpec) method.


    ....
    private int ivSize;
    ...
   BlockCipherParamsCore(int blkSize) {
       block_size = blkSize;
       ivSize = blkSize;
    }
    ...
   void init(AlgorithmParameterSpec paramSpec) {
        ivSize = ...;  // reset IV size.
    }

    // use ivSize while encoding and decoding.

src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 81:

> 79:                         expectedLen + " bytes long");
> 80:         }
> 81:         iv = tmpIv.clone();

The moreSizes is not used after initialization.  The iv/tmpIv could be a value other than the block_size.   The getEncoded() method would use the iv value for the encoding.  While in the decoding method init(byte[]) method, the IV sizes other block_size is not considered, and IOE will be thrown.  Could this be a problem?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From ascarpino at openjdk.java.net  Fri May 21 21:18:34 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Fri, 21 May 2021 21:18:34 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
> 
> Thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  Review comments update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4072/files
  - new: https://git.openjdk.java.net/jdk/pull/4072/files/e75926e8..76a984a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=03-04

  Stats: 221 lines in 5 files changed: 85 ins; 84 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072

PR: https://git.openjdk.java.net/jdk/pull/4072


From peter.firmstone at zeus.net.au  Fri May 21 23:17:39 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 22 May 2021 09:17:39 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>
References: 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
 <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
 <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>
Message-ID: 

I had hoped by end of this discussion, that there would at least be an 
understanding of what OpenJDK is so hastily choosing to destroy.

Once it is gone, it will be irretrievable, it will never be possible to 
lock down the JVM so securely again.


On 21/05/2021 11:06 pm, Ron Pressler wrote:
>
>> On 21 May 2021, at 12:52, Peter Firmstone  wrote:
>>
>> It's quite clear this will be pushed through anyway,
>>
> No, not *anyway*, but given the fact that the community consists of millions of users, this
> proposal has been well-publicised,


I discovered the proposal on the 11th of the May on a mailing list I was 
subscribed to and I almost missed it.?? Yes, it will be pushed through 
regardless, clearly the decision was made before publication.?? Everyone 
saw applets coming, if the developers were serious about supporting 
applets, they would have designed a stripped down subset of Java, a JVM 
specifically suited that task which, didn't include things like XML or 
serialization.

Just think, Applets were killed because of their atrocious security.?? 
How ironic.


>> The granularity is not arbitrary, you said by class, which is incorrect.
>>
>> Granularity is by a combination of one or more of the following:
>>
>> 	? ProtectionDomain
>> 	? CodeSource
>> 	? Code signers
>> 	? ClassLoader
>> 	? Principals.
> What I said is correct. Assigning a ProtectionDomain to a class is possible, though not to a method
> (certainly not in code you can?t modify). In fact, ProtectionDomain is defined as ?a set of classes,?
> i.e. class granularity. In particular, that is the granularity that instrumentation with doPrivileged
> aims to address, and that is one of the Security Manager?s most defining features.

It may be possible to assign a ProtectionDomain, to a single class, but 
that doesn't make your assertions correct, you should be quoting common 
use cases, I have never seen an example of assigning permissions to a 
single class, besides, it requires a dynamic policy to do that, and Java 
doesn't have one by default, so you can't use PolicyFile to assign it 
permissions.?? Maybe you could use it to encapsulate ObjectInputStream 
with no permissions, then no one could grant it permissions, so that 
would be useful for Security.? It doesn't change class resolution or 
visibility. But OpenJDK didn't do that, why not?


What use case would there be to assign a ProtectionDomain to a method?

Just use a permission check in the method, or wrap a sensitive class 
with a decorator before publication:

http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup

But these are corner cases.

More useful cases are for isolation, such as JEE.


>
> Restricting access by principal at the application level does not require the Security Manager, so that
> part is irrelevant, and, in fact, not only Principal, but also Permission, and even CodeSource and
> ProtectionDomain are *not* being proposed for terminal deprecation or even deprecation by this JEP.


I guess your use case is a desktop application running in a single process?

What about a multi user server application running in a single 
process??? Now we have to spawn multiple processes for each user, that's 
hardly efficient or performant is it?


>
>> I would like to understand this pain that is being caused to a far greater number of people?   So far information has been scarce and it seems more of an excuse, as it's very light on detail.  I would guess it's the pain of having to update policy files and making sure tests pass with security enabled.
> The pain is that the high cost of maintaining the Security Manager comes at the expense of
> other security measures that, we believe, provide far more security value to the Java ecosystem
> as a whole.


Such as?


>> I think the results of locking down the JVM to principles of least privilege are totally worth it and a saleable commodity in the current global environment.
> I absolutely accept the principle of least privilege. I do not accept that the marginal cost/benefit
> of applying it at class granularity yields its best application.


I agree that there's little value for class granularity, but you are 
applying a corner case that although possible, is never applied in 
practice, and applying it with a broad brush, then using it as an 
argument against, please stop making this false assertion.?? Just 
because you can do something, doesn't mean that you should.?? Just 
because you can walk in front of a passing train, doesn't mean you 
should sir.

There is however a significant benefit for applying the principle of 
least privilege.

It can be assigned to Principal and Code signer granularity, that's 
actually quite coarse grained.? It's very flexible, unlike white listing 
Serializable classes.

>> Sure, theoretical things might, but there's no implementation in existence.  It has been quite affordable for me, so I wish to understand this pain, because I currently don't, I'm already using the latest encryption, static analysis, secure coding practices, validating input, sanitizing data etc.
> There are, though. Here are some: JFR, the module system, crypto protocols and ad-hoc mechanisms for
> specific vulnerable components (serialization, XML etc.). Maintaining the Security Manager comes at their
> expense -- some require urgent improvements like adding more events to JFR and closing down gaps in the
> module system?s defences -- and we believe investing in them has a better security ROI overall.

Don't be rude.? These are not alternatives, some are complementary, but 
not one provides the missing functionality.

And yuck, serialization, XML, vulnerable components should have been 
given un-privilged ProtectionDomains, so they couldn't do anything 
privileged while on the stack, like Perl Taint mode.?? Or better yet 
alternative implementations created that practice data hygiene.

Java Serialization is a good example of good money thrown after bad, 
that has a far greater development cost.?? Why did you (yes you OpenJDK) 
make Lambda's serializable?? Inner classes?? Yuck! Put it in a separate 
library, let people that use it download it, then the platform isn't 
made insecure for those who don't want it, this is a good use case for 
your new module system.

Once SecurityManager is gone, attackers will likely be able to bypass 
your feeble protections, such as whitelisting classes to be 
de-serialized; they only need to find a way to change a property prior 
to initialization, the first use of ObjectInputStream, which is quite 
easy if an application doesn't use it.? In future developers who don't 
use Java serialization will need to make sure it has been initialized so 
it can't be used as an attack vector, who will remember to do that?

>> Other techniques that are yet to be developed.   OpenJDK is deprecating SecurityManager prior to the implementation of it's replacement, a little more notice would have been nice.   I'm ready for you to deprecate Serialization, we saw that coming, but this is just completely unexpected out of left field.
> First, any deprecation proposal could be said to be unexpected until it is proposed. But that is why
> we have a deprecation policy that makes the process gradual and gives people time to adjust. Second, I
> don?t think this is "out of left field" at all. The writing on the wall was pretty clear when, after twenty-five
> years, few projects use the Security Manager and few libraries are properly instrumented for it, other platforms
> have decided not to adopt a similar model, and those few that have have already abandoned it some years ago.


Library's don't need to be instrumented for it, the Java platform is 
already and provides the necessary protection for network connections, 
file access and class loading for example.


- Peter.



From xuelei at openjdk.java.net  Sat May 22 01:07:25 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 22 May 2021 01:07:25 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
Message-ID: 

On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng  wrote:

>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>> 
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
>> 
>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge master into JDK-8248268
>  - Minor update to address review comments.
>  - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>    KWParameters and KWPParameters.
>  - Refactor code to reduce code duplication
>    Address review comments
>    Add more test vectors
>  - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>    AES/KWP/NoPadding
>  - Restored Iv algorithm parameters impl.
>  - 8248268: Support KWP in addition to KW
>    
>    Updated existing AESWrap support with AES/KW/NoPadding cipher
>    transformation. Added support for AES/KWP/NoPadding and
>    AES/KW/PKCS5Padding support to SunJCE provider.

src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java line 176:

> 174:             return ConstructKeys.constructPublicKey(encoding, keyAlgorithm);
> 175:         default:
> 176:             throw new RuntimeException("Unsupported key type");

Good improvement to thrown an exception rather than return "null"!

Is NoSuchAlgorithmException fitted better the specification?  See also the comment in  KeyWrapCipher.engineUnwrap().

src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java line 190:

> 188:                 return constructKey(encoding, keyAlgorithm, keyType);
> 189:             } else {
> 190:                 byte[] encoding2 = Arrays.copyOfRange(encoding, ofs, ofs + len);

The array will be copied again in the X509EncodedKeySpec and PKCS8EncodedKeySpec.  It is out of this scope, but it may be a performance improvement if adding X509EncodedKeySpec and PKCS8EncodedKeySpec constructors that accept array offset, so that the array copy here could be avoid.

src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java line 192:

> 190:                 byte[] encoding2 = Arrays.copyOfRange(encoding, ofs, ofs + len);
> 191:                 try {
> 192:                     return constructKey(encoding2, keyAlgorithm, keyType);

The two constructKey methods are depended on each other.  It may improve the readability if only having one-way dependence, by moving the switch-block logic from the former constructKey() to the later one.


 static final Key constructKey(byte[] encoding, String keyAlgorithm,
       int keyType) throws InvalidKeyException, NoSuchAlgorithmException {
    return constructKey(encoding, 0. encoding.length, keyAlgorithm, keyType);
}


With this re-org, the array copy could be avoid if the key type is unknown.

src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 710:

> 708:             outLen = helperDecrypt(dataBuf, dataIdx);
> 709:             return ConstructKeys.constructKey(dataBuf, 0, outLen,
> 710:                     wrappedKeyAlgorithm, wrappedKeyType);

Per the specification of engineUnwrap,  maybe, the ConstructKeys.constructKey() implementation could throw NoSuchAlgorithmException if wrappedKeyType is unknown.  See the common in the the ConstructKeys.constructKey() implementation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From ron.pressler at oracle.com  Sat May 22 01:12:25 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Sat, 22 May 2021 01:12:25 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
 <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
 <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>
 
Message-ID: 

Let me be very clear: the proposers of this JEP, some of whom have worked on the Security Manager for the
last twenty years, strongly believe that not only will its removal not harm Java?s security, but considerably
improve it, as do the maintainers of other platforms who have decided to either not try to offer security
through the deep stack-dependent sandbox model or did but have since also removed it. Their view is backed
by security experts, both those working on OpenJDK and outside it.

While I seriously hope you don?t actually believe a decision was made before publication, it is also obviously
true that this wouldn?t have been proposed in the first place without *a lot* of thought, study and discussion.
The proposal was made only after it was clear this was a very, *very* strong case, and that the chances of finding
fault with it are low. It wasn?t put up after someone just had an idea. It is, therefore, not entirely 
surprising that no one has been able to give any relevant arguments against it. Clearly, you have had far less 
time to think about it, but I can?t seem to steer your arguments in a direction that?s relevant to what is actually 
the issue.

I understand you?re invested in the Security Manager and that its removal would impose real costs on you. I am even
willing to believe that you actually believe that, despite what studies show, despite what experts say, despite
what the developers of Java say, despite what the developers of *all* other mainstream software platforms with 
an emphasis on security, both new and old ?- from .NET to WebAssembly ?- have concluded after decades of experience, 
that the Security Manager is not only the best way to secure Java but apparently the only one. Maybe you?re right 
and those others are wrong, but please accept that we all want to improve Java?s security, we just disagree with you 
on the best way to do it.

Yes, additional security measures, whatever they are, would provide additional security. But if the choice is 
between measure A and measure B -? you *can?t* have both ?- you pick the one that is *more* effective per cost. 
None of your arguments so much as glance in that direction, and they don?t acknowledge the fact that Java security 
would be hardly affected by the Security Manager?s removal even without better protection elsewhere for the simple 
reason that it is hardly ever installed, including on the most security-critical applications, whose defences 
apparently aren?t so feeble even today. In any event, if the question is, do we want a perimeter fence and security 
cameras *XOR* locks on all room doors, the argument that they provide security through different mechanisms so we 
should have both completely misunderstands the question. I am also confused by your point about multi-user
applications. Of course different users have different access, but surely you are aware that very few applications
do that using the Security Manager, which isn?t needed ?- and is rarely used -? for that purpose.

Short of making relevant arguments, I would urge you again to focus on suggestions to reduce the harm this proposal 
would cause you.

? Ron



> On 22 May 2021, at 00:17, Peter Firmstone  wrote:
> 
> I had hoped by end of this discussion, that there would at least be an understanding of what OpenJDK is so hastily choosing to destroy.
> 
> Once it is gone, it will be irretrievable, it will never be possible to lock down the JVM so securely again.
> 
> 
> On 21/05/2021 11:06 pm, Ron Pressler wrote:
>> 
>>> On 21 May 2021, at 12:52, Peter Firmstone  wrote:
>>> 
>>> It's quite clear this will be pushed through anyway,
>>> 
>> No, not *anyway*, but given the fact that the community consists of millions of users, this
>> proposal has been well-publicised,
> 
> 
> I discovered the proposal on the 11th of the May on a mailing list I was subscribed to and I almost missed it.   Yes, it will be pushed through regardless, clearly the decision was made before publication.   Everyone saw applets coming, if the developers were serious about supporting applets, they would have designed a stripped down subset of Java, a JVM specifically suited that task which, didn't include things like XML or serialization.
> 
> Just think, Applets were killed because of their atrocious security.   How ironic.
> 
> 
>>> The granularity is not arbitrary, you said by class, which is incorrect.
>>> 
>>> Granularity is by a combination of one or more of the following:
>>> 
>>> 	? ProtectionDomain
>>> 	? CodeSource
>>> 	? Code signers
>>> 	? ClassLoader
>>> 	? Principals.
>> What I said is correct. Assigning a ProtectionDomain to a class is possible, though not to a method
>> (certainly not in code you can?t modify). In fact, ProtectionDomain is defined as ?a set of classes,?
>> i.e. class granularity. In particular, that is the granularity that instrumentation with doPrivileged
>> aims to address, and that is one of the Security Manager?s most defining features.
> 
> It may be possible to assign a ProtectionDomain, to a single class, but that doesn't make your assertions correct, you should be quoting common use cases, I have never seen an example of assigning permissions to a single class, besides, it requires a dynamic policy to do that, and Java doesn't have one by default, so you can't use PolicyFile to assign it permissions.   Maybe you could use it to encapsulate ObjectInputStream with no permissions, then no one could grant it permissions, so that would be useful for Security.  It doesn't change class resolution or visibility. But OpenJDK didn't do that, why not?
> 
> 
> What use case would there be to assign a ProtectionDomain to a method?
> 
> Just use a permission check in the method, or wrap a sensitive class with a decorator before publication:
> 
> https://urldefense.com/v3/__http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup__;!!GqivPVa7Brio!LdTftZDa5TWyQFfdIFBzHe3OFQMmnVFcIa0TeUz2kNlVyBaY475E1rWMksv_wkow7A$ 
> But these are corner cases.
> 
> More useful cases are for isolation, such as JEE.
> 
> 
>> 
>> Restricting access by principal at the application level does not require the Security Manager, so that
>> part is irrelevant, and, in fact, not only Principal, but also Permission, and even CodeSource and
>> ProtectionDomain are *not* being proposed for terminal deprecation or even deprecation by this JEP.
> 
> 
> I guess your use case is a desktop application running in a single process?
> 
> What about a multi user server application running in a single process?   Now we have to spawn multiple processes for each user, that's hardly efficient or performant is it?
> 
> 
>> 
>>> I would like to understand this pain that is being caused to a far greater number of people?   So far information has been scarce and it seems more of an excuse, as it's very light on detail.  I would guess it's the pain of having to update policy files and making sure tests pass with security enabled.
>> The pain is that the high cost of maintaining the Security Manager comes at the expense of
>> other security measures that, we believe, provide far more security value to the Java ecosystem
>> as a whole.
> 
> 
> Such as?
> 
> 
>>> I think the results of locking down the JVM to principles of least privilege are totally worth it and a saleable commodity in the current global environment.
>> I absolutely accept the principle of least privilege. I do not accept that the marginal cost/benefit
>> of applying it at class granularity yields its best application.
> 
> 
> I agree that there's little value for class granularity, but you are applying a corner case that although possible, is never applied in practice, and applying it with a broad brush, then using it as an argument against, please stop making this false assertion.   Just because you can do something, doesn't mean that you should.   Just because you can walk in front of a passing train, doesn't mean you should sir.
> 
> There is however a significant benefit for applying the principle of least privilege.
> 
> It can be assigned to Principal and Code signer granularity, that's actually quite coarse grained.  It's very flexible, unlike white listing Serializable classes.
> 
>>> Sure, theoretical things might, but there's no implementation in existence.  It has been quite affordable for me, so I wish to understand this pain, because I currently don't, I'm already using the latest encryption, static analysis, secure coding practices, validating input, sanitizing data etc.
>> There are, though. Here are some: JFR, the module system, crypto protocols and ad-hoc mechanisms for
>> specific vulnerable components (serialization, XML etc.). Maintaining the Security Manager comes at their
>> expense -- some require urgent improvements like adding more events to JFR and closing down gaps in the
>> module system?s defences -- and we believe investing in them has a better security ROI overall.
> 
> Don't be rude.  These are not alternatives, some are complementary, but not one provides the missing functionality.
> 
> And yuck, serialization, XML, vulnerable components should have been given un-privilged ProtectionDomains, so they couldn't do anything privileged while on the stack, like Perl Taint mode.   Or better yet alternative implementations created that practice data hygiene.
> 
> Java Serialization is a good example of good money thrown after bad, that has a far greater development cost.   Why did you (yes you OpenJDK) make Lambda's serializable?  Inner classes?  Yuck! Put it in a separate library, let people that use it download it, then the platform isn't made insecure for those who don't want it, this is a good use case for your new module system.
> 
> Once SecurityManager is gone, attackers will likely be able to bypass your feeble protections, such as whitelisting classes to be de-serialized; they only need to find a way to change a property prior to initialization, the first use of ObjectInputStream, which is quite easy if an application doesn't use it.  In future developers who don't use Java serialization will need to make sure it has been initialized so it can't be used as an attack vector, who will remember to do that?
> 
>>> Other techniques that are yet to be developed.   OpenJDK is deprecating SecurityManager prior to the implementation of it's replacement, a little more notice would have been nice.   I'm ready for you to deprecate Serialization, we saw that coming, but this is just completely unexpected out of left field.
>> First, any deprecation proposal could be said to be unexpected until it is proposed. But that is why
>> we have a deprecation policy that makes the process gradual and gives people time to adjust. Second, I
>> don?t think this is "out of left field" at all. The writing on the wall was pretty clear when, after twenty-five
>> years, few projects use the Security Manager and few libraries are properly instrumented for it, other platforms
>> have decided not to adopt a similar model, and those few that have have already abandoned it some years ago.
> 
> 
> Library's don't need to be instrumented for it, the Java platform is already and provides the necessary protection for network connections, file access and class loading for example.
> 
> 
> - Peter.
> 


From peter.firmstone at zeus.net.au  Sat May 22 03:31:36 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 22 May 2021 13:31:36 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
 <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
 <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>
 
 
Message-ID: <746afaf4-2078-dcc1-e621-38c4726c5cf5@zeus.net.au>

Studies, experts, meetings and academics, without practical application 
of the principle of least privilege, these are meaningless.? I hope 
someone remembered to bring tea and scones.

My point is nothing gets done without workers.? It's the Pareto 
Principle or 80:20 rule.?? Li Gong may have been an academic at that 
time, but he also got down to business and got the work done too, today 
he's a CEO.? How many of your experts are CEO's??? Very smart people 
study in academia, but they spread their wings and apply what they've 
learned, and in doing so learn new lessons and truly understand, then 
they are no longer academics, some retreat to the safety of the academic 
world. ? The best lecturers were retiree's from the real world of 
application, well lets just leave it at that.

No matter how expert you are at A, doesn't qualify you to comment on B, 
when you've had limited or no experience in B.

I have demonstrated practical application and arguments based on 
examples and implementations.

Yes, NPV analysis indicates the best option is to not upgrade. This is 
the least harm, lowest cost option, in your words, I can't have both A 
and B, so I've chosen A.

Abandoning the principles of least privilege will significantly increase 
the consequences of a security breach.

The Australian native bee, has a unique defense system:

 1. Guard bee's are positioned at the hive entrance to authenticate the
    bees entering the hive and will defend against intruders, battling
    until death.
 2. If an intruder makes it past the guard bees, the bees inside the
    hive use resin to glue the intruders to the hives internal
    structures, intruders are rendered immobile and cannot move. Then
    the bees continue about their daily tasks ignoring the intruders
    until they die, then a bee on cleanup duty removes them and discards
    their carcasses outside the hive.

This is the principle of least privilege, to render the attacker 
harmless after breaching the perimeter, also it helps maintain perimeter 
defenses by reducing the attackers ability to pull them down, in doing 
so, it adds to the effectiveness of perimeter defenses.

I wonder how long the bee's would survive if they stopped immobilizing 
intruders and let them eat their larvae?

No it makes Bee's less secure, not more.

I get it that many developers don't care about security, at least until 
they wish they had.?? Bee's get it, I wonder why many developers don't?

I get it that OpenJDK didn't know that SecurityManager infrastructure 
actually worked and thought that no one was using it, maybe that's why 
they did nothing to improve it, because they never believed in it in the 
first place, it was an annoying feature that got in the way of getting 
something else done.

https://github.com/openjdk/jdk/blame/master/src/java.base/share/classes/java/lang/SecurityManager.java

https://github.com/openjdk/jdk/blame/master/src/hotspot/share/prims/jvm.cpp

https://github.com/openjdk/jdk/blame/master/src/java.base/share/classes/java/security/AccessController.java

https://github.com/openjdk/jdk/blame/master/src/java.base/share/native/libjava/AccessController.c

I accept it's being removed, I just want you to understand just what it 
is you're removing, so you understand that this isn't going to be easy 
for you either, the consequences await you at a later date, I can see 
them, but you cannot because you cannot foresee what's unknown to you.

I hope that next time, more thorough research is done before making such 
hasty decisions.? Even experts make mistakes.? More time needs to be 
spent on community consultation, but then maybe not if its not something 
you care about.

With respect I think it's time to retire this conversation, I'm sure we 
both have other things we need to do.? Judging by the conversation, 
people haven't had time to review the practical examples submitted, or 
aren't interested, I'll remain available should there be interest.

Regards,

Peter.

On 22/05/2021 11:12 am, Ron Pressler wrote:
> Let me be very clear: the proposers of this JEP, some of whom have worked on the Security Manager for the
> last twenty years, strongly believe that not only will its removal not harm Java?s security, but considerably
> improve it, as do the maintainers of other platforms who have decided to either not try to offer security
> through the deep stack-dependent sandbox model or did but have since also removed it. Their view is backed
> by security experts, both those working on OpenJDK and outside it.
>
> While I seriously hope you don?t actually believe a decision was made before publication, it is also obviously
> true that this wouldn?t have been proposed in the first place without *a lot* of thought, study and discussion.
> The proposal was made only after it was clear this was a very, *very* strong case, and that the chances of finding
> fault with it are low. It wasn?t put up after someone just had an idea. It is, therefore, not entirely
> surprising that no one has been able to give any relevant arguments against it. Clearly, you have had far less
> time to think about it, but I can?t seem to steer your arguments in a direction that?s relevant to what is actually
> the issue.
>
> I understand you?re invested in the Security Manager and that its removal would impose real costs on you. I am even
> willing to believe that you actually believe that, despite what studies show, despite what experts say, despite
> what the developers of Java say, despite what the developers of *all* other mainstream software platforms with
> an emphasis on security, both new and old ?- from .NET to WebAssembly ?- have concluded after decades of experience,
> that the Security Manager is not only the best way to secure Java but apparently the only one. Maybe you?re right
> and those others are wrong, but please accept that we all want to improve Java?s security, we just disagree with you
> on the best way to do it.
>
> Yes, additional security measures, whatever they are, would provide additional security. But if the choice is
> between measure A and measure B -? you *can?t* have both ?- you pick the one that is *more* effective per cost.
> None of your arguments so much as glance in that direction, and they don?t acknowledge the fact that Java security
> would be hardly affected by the Security Manager?s removal even without better protection elsewhere for the simple
> reason that it is hardly ever installed, including on the most security-critical applications, whose defences
> apparently aren?t so feeble even today. In any event, if the question is, do we want a perimeter fence and security
> cameras *XOR* locks on all room doors, the argument that they provide security through different mechanisms so we
> should have both completely misunderstands the question. I am also confused by your point about multi-user
> applications. Of course different users have different access, but surely you are aware that very few applications
> do that using the Security Manager, which isn?t needed ?- and is rarely used -? for that purpose.
>
> Short of making relevant arguments, I would urge you again to focus on suggestions to reduce the harm this proposal
> would cause you.
>
> ? Ron
>
>
>
>> On 22 May 2021, at 00:17, Peter Firmstone  wrote:
>>
>> I had hoped by end of this discussion, that there would at least be an understanding of what OpenJDK is so hastily choosing to destroy.
>>
>> Once it is gone, it will be irretrievable, it will never be possible to lock down the JVM so securely again.
>>
>>
>> On 21/05/2021 11:06 pm, Ron Pressler wrote:
>>>> On 21 May 2021, at 12:52, Peter Firmstone  wrote:
>>>>
>>>> It's quite clear this will be pushed through anyway,
>>>>
>>> No, not *anyway*, but given the fact that the community consists of millions of users, this
>>> proposal has been well-publicised,
>> I discovered the proposal on the 11th of the May on a mailing list I was subscribed to and I almost missed it.   Yes, it will be pushed through regardless, clearly the decision was made before publication.   Everyone saw applets coming, if the developers were serious about supporting applets, they would have designed a stripped down subset of Java, a JVM specifically suited that task which, didn't include things like XML or serialization.
>>
>> Just think, Applets were killed because of their atrocious security.   How ironic.
>>
>>
>>>> The granularity is not arbitrary, you said by class, which is incorrect.
>>>>
>>>> Granularity is by a combination of one or more of the following:
>>>>
>>>> 	? ProtectionDomain
>>>> 	? CodeSource
>>>> 	? Code signers
>>>> 	? ClassLoader
>>>> 	? Principals.
>>> What I said is correct. Assigning a ProtectionDomain to a class is possible, though not to a method
>>> (certainly not in code you can?t modify). In fact, ProtectionDomain is defined as ?a set of classes,?
>>> i.e. class granularity. In particular, that is the granularity that instrumentation with doPrivileged
>>> aims to address, and that is one of the Security Manager?s most defining features.
>> It may be possible to assign a ProtectionDomain, to a single class, but that doesn't make your assertions correct, you should be quoting common use cases, I have never seen an example of assigning permissions to a single class, besides, it requires a dynamic policy to do that, and Java doesn't have one by default, so you can't use PolicyFile to assign it permissions.   Maybe you could use it to encapsulate ObjectInputStream with no permissions, then no one could grant it permissions, so that would be useful for Security.  It doesn't change class resolution or visibility. But OpenJDK didn't do that, why not?
>>
>>
>> What use case would there be to assign a ProtectionDomain to a method?
>>
>> Just use a permission check in the method, or wrap a sensitive class with a decorator before publication:
>>
>> https://urldefense.com/v3/__http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup__;!!GqivPVa7Brio!LdTftZDa5TWyQFfdIFBzHe3OFQMmnVFcIa0TeUz2kNlVyBaY475E1rWMksv_wkow7A$  
>> But these are corner cases.
>>
>> More useful cases are for isolation, such as JEE.
>>
>>
>>> Restricting access by principal at the application level does not require the Security Manager, so that
>>> part is irrelevant, and, in fact, not only Principal, but also Permission, and even CodeSource and
>>> ProtectionDomain are *not* being proposed for terminal deprecation or even deprecation by this JEP.
>> I guess your use case is a desktop application running in a single process?
>>
>> What about a multi user server application running in a single process?   Now we have to spawn multiple processes for each user, that's hardly efficient or performant is it?
>>
>>
>>>> I would like to understand this pain that is being caused to a far greater number of people?   So far information has been scarce and it seems more of an excuse, as it's very light on detail.  I would guess it's the pain of having to update policy files and making sure tests pass with security enabled.
>>> The pain is that the high cost of maintaining the Security Manager comes at the expense of
>>> other security measures that, we believe, provide far more security value to the Java ecosystem
>>> as a whole.
>> Such as?
>>
>>
>>>> I think the results of locking down the JVM to principles of least privilege are totally worth it and a saleable commodity in the current global environment.
>>> I absolutely accept the principle of least privilege. I do not accept that the marginal cost/benefit
>>> of applying it at class granularity yields its best application.
>> I agree that there's little value for class granularity, but you are applying a corner case that although possible, is never applied in practice, and applying it with a broad brush, then using it as an argument against, please stop making this false assertion.   Just because you can do something, doesn't mean that you should.   Just because you can walk in front of a passing train, doesn't mean you should sir.
>>
>> There is however a significant benefit for applying the principle of least privilege.
>>
>> It can be assigned to Principal and Code signer granularity, that's actually quite coarse grained.  It's very flexible, unlike white listing Serializable classes.
>>
>>>> Sure, theoretical things might, but there's no implementation in existence.  It has been quite affordable for me, so I wish to understand this pain, because I currently don't, I'm already using the latest encryption, static analysis, secure coding practices, validating input, sanitizing data etc.
>>> There are, though. Here are some: JFR, the module system, crypto protocols and ad-hoc mechanisms for
>>> specific vulnerable components (serialization, XML etc.). Maintaining the Security Manager comes at their
>>> expense -- some require urgent improvements like adding more events to JFR and closing down gaps in the
>>> module system?s defences -- and we believe investing in them has a better security ROI overall.
>> Don't be rude.  These are not alternatives, some are complementary, but not one provides the missing functionality.
>>
>> And yuck, serialization, XML, vulnerable components should have been given un-privilged ProtectionDomains, so they couldn't do anything privileged while on the stack, like Perl Taint mode.   Or better yet alternative implementations created that practice data hygiene.
>>
>> Java Serialization is a good example of good money thrown after bad, that has a far greater development cost.   Why did you (yes you OpenJDK) make Lambda's serializable?  Inner classes?  Yuck! Put it in a separate library, let people that use it download it, then the platform isn't made insecure for those who don't want it, this is a good use case for your new module system.
>>
>> Once SecurityManager is gone, attackers will likely be able to bypass your feeble protections, such as whitelisting classes to be de-serialized; they only need to find a way to change a property prior to initialization, the first use of ObjectInputStream, which is quite easy if an application doesn't use it.  In future developers who don't use Java serialization will need to make sure it has been initialized so it can't be used as an attack vector, who will remember to do that?
>>
>>>> Other techniques that are yet to be developed.   OpenJDK is deprecating SecurityManager prior to the implementation of it's replacement, a little more notice would have been nice.   I'm ready for you to deprecate Serialization, we saw that coming, but this is just completely unexpected out of left field.
>>> First, any deprecation proposal could be said to be unexpected until it is proposed. But that is why
>>> we have a deprecation policy that makes the process gradual and gives people time to adjust. Second, I
>>> don?t think this is "out of left field" at all. The writing on the wall was pretty clear when, after twenty-five
>>> years, few projects use the Security Manager and few libraries are properly instrumented for it, other platforms
>>> have decided not to adopt a similar model, and those few that have have already abandoned it some years ago.
>> Library's don't need to be instrumented for it, the Java platform is already and provides the necessary protection for network connections, file access and class loading for example.
>>
>>
>> - Peter.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From alanb at openjdk.java.net  Sat May 22 07:00:03 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 22 May 2021 07:00:03 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
 <5tnvQYYadqs7toQbKQFgv66rQ6t3fDiddGR3wbyHGPY=.6f6fc94b-feb1-4e47-9541-278a446ffca4@github.com>
 
 
 <1piIKOes2IKRPqUi8coLGew5pSxmKKNmy352RMaEGWM=.57b7a23c-5666-48bc-8552-543533c0c683@github.com>
 
 
 
 <-X86Sk4TcDQvSExDP8kmQvZ-N-WhPxxlEr3NEeYa3X0=.ffddb434-2928-482d-bab6-e900d153439c@github.com>
 
 
 
Message-ID: 

On Fri, 21 May 2021 18:00:13 GMT, Phil Race  wrote:

> Are you suggesting that the patch doesn't need testing as it is ? It should be the same either way.
> It is very straight forward to run the automated tests across all platforms these days.
> I get the impression that no one is guaranteeing to do this straight after integration.
> It sounds like it is up for deferral if time runs out.
> 
> The amount of follow-on work that I am hearing about here, and may be for tests, does not make it sound
> like this JEP is nearly as done as first presented.
> 
> If there was some expectation that groups responsible for an area would get involved with this
> issue which I am assured was already known about, then why was it not raised before and made
> part of the plan ?

Sprinkling SuppressWarnings should be very low risk. Refactoring code to have the scope of the SW be as small as possible may be a bit more risky, esp. in areas where one doesn't know the code or the tests that exercise it. The tests may be good but it's not clear to me that we want to force Max to do significant refactoring in this PR.  PR 4138 has been created as the follow-on PR so I think we should help get that reviewed so that it can be integrated soon after this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From peter.tribble at gmail.com  Sat May 22 09:11:43 2021
From: peter.tribble at gmail.com (Peter Tribble)
Date: Sat, 22 May 2021 10:11:43 +0100
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
 <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
 <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>
 
 
Message-ID: 

On Sat, May 22, 2021 at 2:12 AM Ron Pressler 
wrote:

> Let me be very clear: the proposers of this JEP, some of whom have worked
> on the Security Manager for the
> last twenty years, strongly believe that not only will its removal not
> harm Java?s security, but considerably
> improve it, as do the maintainers of other platforms who have decided to
> either not try to offer security
> through the deep stack-dependent sandbox model or did but have since also
> removed it. Their view is backed
> by security experts, both those working on OpenJDK and outside it.
>

I understand that maintaining the Security Manager is a burden. I
understand the argument that not
having the Security Manager would allow resources to be better deployed
elsewhere. Yet here we're
only seeing the one side. It would be good to be able to see the ways in
which Java's security would
be improved by this JEP, because at the moment we're having to take that on
trust.


> While I seriously hope you don?t actually believe a decision was made
> before publication, it is also obviously
> true that this wouldn?t have been proposed in the first place without *a
> lot* of thought, study and discussion.
> The proposal was made only after it was clear this was a very, *very*
> strong case, and that the chances of finding
> fault with it are low. It wasn?t put up after someone just had an idea. It
> is, therefore, not entirely
> surprising that no one has been able to give any relevant arguments
> against it. Clearly, you have had far less
> time to think about it, but I can?t seem to steer your arguments in a
> direction that?s relevant to what is actually
> the issue.
>
> I understand you?re invested in the Security Manager and that its removal
> would impose real costs on you. I am even
> willing to believe that you actually believe that, despite what studies
> show, despite what experts say, despite
> what the developers of Java say, despite what the developers of *all*
> other mainstream software platforms with
> an emphasis on security, both new and old ?- from .NET to WebAssembly ?-
> have concluded after decades of experience,
> that the Security Manager is not only the best way to secure Java but
> apparently the only one. Maybe you?re right
> and those others are wrong, but please accept that we all want to improve
> Java?s security, we just disagree with you
> on the best way to do it.
>
> Yes, additional security measures, whatever they are, would provide
> additional security. But if the choice is
> between measure A and measure B -? you *can?t* have both ?- you pick the
> one that is *more* effective per cost.
>

And yet the proposal in front of us is to remove measure A, which *will*
reduce security for those using it.
Where's the proposal for measure B, so we can evaluate whether the tradeoff
between A and B is beneficial?


> None of your arguments so much as glance in that direction, and they don?t
> acknowledge the fact that Java security
> would be hardly affected by the Security Manager?s removal even without
> better protection elsewhere for the simple
> reason that it is hardly ever installed, including on the most
> security-critical applications, whose defences
> apparently aren?t so feeble even today. In any event, if the question is,
> do we want a perimeter fence and security
> cameras *XOR* locks on all room doors, the argument that they provide
> security through different mechanisms so we
> should have both completely misunderstands the question. I am also
> confused by your point about multi-user
> applications. Of course different users have different access, but surely
> you are aware that very few applications
> do that using the Security Manager, which isn?t needed ?- and is rarely
> used -? for that purpose.
>
> Short of making relevant arguments, I would urge you again to focus on
> suggestions to reduce the harm this proposal
> would cause you.
>
> ? Ron
>
>
>
> > On 22 May 2021, at 00:17, Peter Firmstone 
> wrote:
> >
> > I had hoped by end of this discussion, that there would at least be an
> understanding of what OpenJDK is so hastily choosing to destroy.
> >
> > Once it is gone, it will be irretrievable, it will never be possible to
> lock down the JVM so securely again.
> >
> >
> > On 21/05/2021 11:06 pm, Ron Pressler wrote:
> >>
> >>> On 21 May 2021, at 12:52, Peter Firmstone 
> wrote:
> >>>
> >>> It's quite clear this will be pushed through anyway,
> >>>
> >> No, not *anyway*, but given the fact that the community consists of
> millions of users, this
> >> proposal has been well-publicised,
> >
> >
> > I discovered the proposal on the 11th of the May on a mailing list I was
> subscribed to and I almost missed it.   Yes, it will be pushed through
> regardless, clearly the decision was made before publication.   Everyone
> saw applets coming, if the developers were serious about supporting
> applets, they would have designed a stripped down subset of Java, a JVM
> specifically suited that task which, didn't include things like XML or
> serialization.
> >
> > Just think, Applets were killed because of their atrocious security.
>  How ironic.
> >
> >
> >>> The granularity is not arbitrary, you said by class, which is
> incorrect.
> >>>
> >>> Granularity is by a combination of one or more of the following:
> >>>
> >>>     ? ProtectionDomain
> >>>     ? CodeSource
> >>>     ? Code signers
> >>>     ? ClassLoader
> >>>     ? Principals.
> >> What I said is correct. Assigning a ProtectionDomain to a class is
> possible, though not to a method
> >> (certainly not in code you can?t modify). In fact, ProtectionDomain is
> defined as ?a set of classes,?
> >> i.e. class granularity. In particular, that is the granularity that
> instrumentation with doPrivileged
> >> aims to address, and that is one of the Security Manager?s most
> defining features.
> >
> > It may be possible to assign a ProtectionDomain, to a single class, but
> that doesn't make your assertions correct, you should be quoting common use
> cases, I have never seen an example of assigning permissions to a single
> class, besides, it requires a dynamic policy to do that, and Java doesn't
> have one by default, so you can't use PolicyFile to assign it permissions.
>  Maybe you could use it to encapsulate ObjectInputStream with no
> permissions, then no one could grant it permissions, so that would be
> useful for Security.  It doesn't change class resolution or visibility. But
> OpenJDK didn't do that, why not?
> >
> >
> > What use case would there be to assign a ProtectionDomain to a method?
> >
> > Just use a permission check in the method, or wrap a sensitive class
> with a decorator before publication:
> >
> >
> https://urldefense.com/v3/__http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup__;!!GqivPVa7Brio!LdTftZDa5TWyQFfdIFBzHe3OFQMmnVFcIa0TeUz2kNlVyBaY475E1rWMksv_wkow7A$
> > But these are corner cases.
> >
> > More useful cases are for isolation, such as JEE.
> >
> >
> >>
> >> Restricting access by principal at the application level does not
> require the Security Manager, so that
> >> part is irrelevant, and, in fact, not only Principal, but also
> Permission, and even CodeSource and
> >> ProtectionDomain are *not* being proposed for terminal deprecation or
> even deprecation by this JEP.
> >
> >
> > I guess your use case is a desktop application running in a single
> process?
> >
> > What about a multi user server application running in a single process?
>  Now we have to spawn multiple processes for each user, that's hardly
> efficient or performant is it?
> >
> >
> >>
> >>> I would like to understand this pain that is being caused to a far
> greater number of people?   So far information has been scarce and it seems
> more of an excuse, as it's very light on detail.  I would guess it's the
> pain of having to update policy files and making sure tests pass with
> security enabled.
> >> The pain is that the high cost of maintaining the Security Manager
> comes at the expense of
> >> other security measures that, we believe, provide far more security
> value to the Java ecosystem
> >> as a whole.
> >
> >
> > Such as?
> >
> >
> >>> I think the results of locking down the JVM to principles of least
> privilege are totally worth it and a saleable commodity in the current
> global environment.
> >> I absolutely accept the principle of least privilege. I do not accept
> that the marginal cost/benefit
> >> of applying it at class granularity yields its best application.
> >
> >
> > I agree that there's little value for class granularity, but you are
> applying a corner case that although possible, is never applied in
> practice, and applying it with a broad brush, then using it as an argument
> against, please stop making this false assertion.   Just because you can do
> something, doesn't mean that you should.   Just because you can walk in
> front of a passing train, doesn't mean you should sir.
> >
> > There is however a significant benefit for applying the principle of
> least privilege.
> >
> > It can be assigned to Principal and Code signer granularity, that's
> actually quite coarse grained.  It's very flexible, unlike white listing
> Serializable classes.
> >
> >>> Sure, theoretical things might, but there's no implementation in
> existence.  It has been quite affordable for me, so I wish to understand
> this pain, because I currently don't, I'm already using the latest
> encryption, static analysis, secure coding practices, validating input,
> sanitizing data etc.
> >> There are, though. Here are some: JFR, the module system, crypto
> protocols and ad-hoc mechanisms for
> >> specific vulnerable components (serialization, XML etc.). Maintaining
> the Security Manager comes at their
> >> expense -- some require urgent improvements like adding more events to
> JFR and closing down gaps in the
> >> module system?s defences -- and we believe investing in them has a
> better security ROI overall.
> >
> > Don't be rude.  These are not alternatives, some are complementary, but
> not one provides the missing functionality.
> >
> > And yuck, serialization, XML, vulnerable components should have been
> given un-privilged ProtectionDomains, so they couldn't do anything
> privileged while on the stack, like Perl Taint mode.   Or better yet
> alternative implementations created that practice data hygiene.
> >
> > Java Serialization is a good example of good money thrown after bad,
> that has a far greater development cost.   Why did you (yes you OpenJDK)
> make Lambda's serializable?  Inner classes?  Yuck! Put it in a separate
> library, let people that use it download it, then the platform isn't made
> insecure for those who don't want it, this is a good use case for your new
> module system.
> >
> > Once SecurityManager is gone, attackers will likely be able to bypass
> your feeble protections, such as whitelisting classes to be de-serialized;
> they only need to find a way to change a property prior to initialization,
> the first use of ObjectInputStream, which is quite easy if an application
> doesn't use it.  In future developers who don't use Java serialization will
> need to make sure it has been initialized so it can't be used as an attack
> vector, who will remember to do that?
> >
> >>> Other techniques that are yet to be developed.   OpenJDK is
> deprecating SecurityManager prior to the implementation of it's
> replacement, a little more notice would have been nice.   I'm ready for you
> to deprecate Serialization, we saw that coming, but this is just completely
> unexpected out of left field.
> >> First, any deprecation proposal could be said to be unexpected until it
> is proposed. But that is why
> >> we have a deprecation policy that makes the process gradual and gives
> people time to adjust. Second, I
> >> don?t think this is "out of left field" at all. The writing on the wall
> was pretty clear when, after twenty-five
> >> years, few projects use the Security Manager and few libraries are
> properly instrumented for it, other platforms
> >> have decided not to adopt a similar model, and those few that have have
> already abandoned it some years ago.
> >
> >
> > Library's don't need to be instrumented for it, the Java platform is
> already and provides the necessary protection for network connections, file
> access and class loading for example.
> >
> >
> > - Peter.
> >
>
>

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ecki at zusammenkunft.net  Sat May 22 10:58:42 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Sat, 22 May 2021 10:58:42 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
 <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
 <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>
 
 ,
 
Message-ID: 

Hello,

I have to agree with Peter here, we do remove a very valuable asset of the JVM platform. It might not easy to be used and not the most popular technology, but after all it was in the DNA of Java. In this JEP/Discussion there is not a single hesitation  to remove it. Please tell me you tried to find maintainers?

This whole discussion about using only secure libraries really makes me wonder if you know the realities of modern applications with hundreds of dependencies and the state of those, like there is still no easy way to limit XXE in upstream xerces. (Or Have you ever tried to set FSP on a Transformer?), limit deserialisation, restrict url handlers, impersonate Users (local and remote filesystem), run chroot child?s or pass credentials over named pipes. All mechanisms which are easier to do in other programming environments. There is a big hesitation to even offer those platform specific features.

I do hope the result of this discussion really is a set of new replacement technologies which allow to use least priveledge methods from the operating environments (be able to run as a different User token, drop permissions, use chroot/jail, fsuid, capsetp,setgroups and other impersonation methods) as thread scopes. Also facilities for multi-process solutions (named pipe servers, shared memory) might help with doing proper low priveledged architectures in the future (in addition to stuffing everything into rootless containers)

But more importantly we do need to get a handle on Defense in depth for libraries. LFI and Remote connections is a big part of that, but not limited to it.

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: security-dev  im Auftrag von Peter Tribble 
Gesendet: Saturday, May 22, 2021 11:11:43 AM
An: Ron Pressler 
Cc: Peter Firmstone ; David Black ; Alan Bateman ; security-dev at openjdk.java.net 
Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On Sat, May 22, 2021 at 2:12 AM Ron Pressler > wrote:
Let me be very clear: the proposers of this JEP, some of whom have worked on the Security Manager for the
last twenty years, strongly believe that not only will its removal not harm Java?s security, but considerably
improve it, as do the maintainers of other platforms who have decided to either not try to offer security
through the deep stack-dependent sandbox model or did but have since also removed it. Their view is backed
by security experts, both those working on OpenJDK and outside it.

I understand that maintaining the Security Manager is a burden. I understand the argument that not
having the Security Manager would allow resources to be better deployed elsewhere. Yet here we're
only seeing the one side. It would be good to be able to see the ways in which Java's security would
be improved by this JEP, because at the moment we're having to take that on trust.

While I seriously hope you don?t actually believe a decision was made before publication, it is also obviously
true that this wouldn?t have been proposed in the first place without *a lot* of thought, study and discussion.
The proposal was made only after it was clear this was a very, *very* strong case, and that the chances of finding
fault with it are low. It wasn?t put up after someone just had an idea. It is, therefore, not entirely
surprising that no one has been able to give any relevant arguments against it. Clearly, you have had far less
time to think about it, but I can?t seem to steer your arguments in a direction that?s relevant to what is actually
the issue.

I understand you?re invested in the Security Manager and that its removal would impose real costs on you. I am even
willing to believe that you actually believe that, despite what studies show, despite what experts say, despite
what the developers of Java say, despite what the developers of *all* other mainstream software platforms with
an emphasis on security, both new and old ?- from .NET to WebAssembly ?- have concluded after decades of experience,
that the Security Manager is not only the best way to secure Java but apparently the only one. Maybe you?re right
and those others are wrong, but please accept that we all want to improve Java?s security, we just disagree with you
on the best way to do it.

Yes, additional security measures, whatever they are, would provide additional security. But if the choice is
between measure A and measure B -? you *can?t* have both ?- you pick the one that is *more* effective per cost.

And yet the proposal in front of us is to remove measure A, which *will* reduce security for those using it.
Where's the proposal for measure B, so we can evaluate whether the tradeoff between A and B is beneficial?

None of your arguments so much as glance in that direction, and they don?t acknowledge the fact that Java security
would be hardly affected by the Security Manager?s removal even without better protection elsewhere for the simple
reason that it is hardly ever installed, including on the most security-critical applications, whose defences
apparently aren?t so feeble even today. In any event, if the question is, do we want a perimeter fence and security
cameras *XOR* locks on all room doors, the argument that they provide security through different mechanisms so we
should have both completely misunderstands the question. I am also confused by your point about multi-user
applications. Of course different users have different access, but surely you are aware that very few applications
do that using the Security Manager, which isn?t needed ?- and is rarely used -? for that purpose.

Short of making relevant arguments, I would urge you again to focus on suggestions to reduce the harm this proposal
would cause you.

? Ron



> On 22 May 2021, at 00:17, Peter Firmstone > wrote:
>
> I had hoped by end of this discussion, that there would at least be an understanding of what OpenJDK is so hastily choosing to destroy.
>
> Once it is gone, it will be irretrievable, it will never be possible to lock down the JVM so securely again.
>
>
> On 21/05/2021 11:06 pm, Ron Pressler wrote:
>>
>>> On 21 May 2021, at 12:52, Peter Firmstone > wrote:
>>>
>>> It's quite clear this will be pushed through anyway,
>>>
>> No, not *anyway*, but given the fact that the community consists of millions of users, this
>> proposal has been well-publicised,
>
>
> I discovered the proposal on the 11th of the May on a mailing list I was subscribed to and I almost missed it.   Yes, it will be pushed through regardless, clearly the decision was made before publication.   Everyone saw applets coming, if the developers were serious about supporting applets, they would have designed a stripped down subset of Java, a JVM specifically suited that task which, didn't include things like XML or serialization.
>
> Just think, Applets were killed because of their atrocious security.   How ironic.
>
>
>>> The granularity is not arbitrary, you said by class, which is incorrect.
>>>
>>> Granularity is by a combination of one or more of the following:
>>>
>>>     ? ProtectionDomain
>>>     ? CodeSource
>>>     ? Code signers
>>>     ? ClassLoader
>>>     ? Principals.
>> What I said is correct. Assigning a ProtectionDomain to a class is possible, though not to a method
>> (certainly not in code you can?t modify). In fact, ProtectionDomain is defined as ?a set of classes,?
>> i.e. class granularity. In particular, that is the granularity that instrumentation with doPrivileged
>> aims to address, and that is one of the Security Manager?s most defining features.
>
> It may be possible to assign a ProtectionDomain, to a single class, but that doesn't make your assertions correct, you should be quoting common use cases, I have never seen an example of assigning permissions to a single class, besides, it requires a dynamic policy to do that, and Java doesn't have one by default, so you can't use PolicyFile to assign it permissions.   Maybe you could use it to encapsulate ObjectInputStream with no permissions, then no one could grant it permissions, so that would be useful for Security.  It doesn't change class resolution or visibility. But OpenJDK didn't do that, why not?
>
>
> What use case would there be to assign a ProtectionDomain to a method?
>
> Just use a permission check in the method, or wrap a sensitive class with a decorator before publication:
>
> https://urldefense.com/v3/__http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup__;!!GqivPVa7Brio!LdTftZDa5TWyQFfdIFBzHe3OFQMmnVFcIa0TeUz2kNlVyBaY475E1rWMksv_wkow7A$
> But these are corner cases.
>
> More useful cases are for isolation, such as JEE.
>
>
>>
>> Restricting access by principal at the application level does not require the Security Manager, so that
>> part is irrelevant, and, in fact, not only Principal, but also Permission, and even CodeSource and
>> ProtectionDomain are *not* being proposed for terminal deprecation or even deprecation by this JEP.
>
>
> I guess your use case is a desktop application running in a single process?
>
> What about a multi user server application running in a single process?   Now we have to spawn multiple processes for each user, that's hardly efficient or performant is it?
>
>
>>
>>> I would like to understand this pain that is being caused to a far greater number of people?   So far information has been scarce and it seems more of an excuse, as it's very light on detail.  I would guess it's the pain of having to update policy files and making sure tests pass with security enabled.
>> The pain is that the high cost of maintaining the Security Manager comes at the expense of
>> other security measures that, we believe, provide far more security value to the Java ecosystem
>> as a whole.
>
>
> Such as?
>
>
>>> I think the results of locking down the JVM to principles of least privilege are totally worth it and a saleable commodity in the current global environment.
>> I absolutely accept the principle of least privilege. I do not accept that the marginal cost/benefit
>> of applying it at class granularity yields its best application.
>
>
> I agree that there's little value for class granularity, but you are applying a corner case that although possible, is never applied in practice, and applying it with a broad brush, then using it as an argument against, please stop making this false assertion.   Just because you can do something, doesn't mean that you should.   Just because you can walk in front of a passing train, doesn't mean you should sir.
>
> There is however a significant benefit for applying the principle of least privilege.
>
> It can be assigned to Principal and Code signer granularity, that's actually quite coarse grained.  It's very flexible, unlike white listing Serializable classes.
>
>>> Sure, theoretical things might, but there's no implementation in existence.  It has been quite affordable for me, so I wish to understand this pain, because I currently don't, I'm already using the latest encryption, static analysis, secure coding practices, validating input, sanitizing data etc.
>> There are, though. Here are some: JFR, the module system, crypto protocols and ad-hoc mechanisms for
>> specific vulnerable components (serialization, XML etc.). Maintaining the Security Manager comes at their
>> expense -- some require urgent improvements like adding more events to JFR and closing down gaps in the
>> module system?s defences -- and we believe investing in them has a better security ROI overall.
>
> Don't be rude.  These are not alternatives, some are complementary, but not one provides the missing functionality.
>
> And yuck, serialization, XML, vulnerable components should have been given un-privilged ProtectionDomains, so they couldn't do anything privileged while on the stack, like Perl Taint mode.   Or better yet alternative implementations created that practice data hygiene.
>
> Java Serialization is a good example of good money thrown after bad, that has a far greater development cost.   Why did you (yes you OpenJDK) make Lambda's serializable?  Inner classes?  Yuck! Put it in a separate library, let people that use it download it, then the platform isn't made insecure for those who don't want it, this is a good use case for your new module system.
>
> Once SecurityManager is gone, attackers will likely be able to bypass your feeble protections, such as whitelisting classes to be de-serialized; they only need to find a way to change a property prior to initialization, the first use of ObjectInputStream, which is quite easy if an application doesn't use it.  In future developers who don't use Java serialization will need to make sure it has been initialized so it can't be used as an attack vector, who will remember to do that?
>
>>> Other techniques that are yet to be developed.   OpenJDK is deprecating SecurityManager prior to the implementation of it's replacement, a little more notice would have been nice.   I'm ready for you to deprecate Serialization, we saw that coming, but this is just completely unexpected out of left field.
>> First, any deprecation proposal could be said to be unexpected until it is proposed. But that is why
>> we have a deprecation policy that makes the process gradual and gives people time to adjust. Second, I
>> don?t think this is "out of left field" at all. The writing on the wall was pretty clear when, after twenty-five
>> years, few projects use the Security Manager and few libraries are properly instrumented for it, other platforms
>> have decided not to adopt a similar model, and those few that have have already abandoned it some years ago.
>
>
> Library's don't need to be instrumented for it, the Java platform is already and provides the necessary protection for network connections, file access and class loading for example.
>
>
> - Peter.
>



--
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From ron.pressler at oracle.com  Sat May 22 11:43:26 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Sat, 22 May 2021 11:43:26 +0000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
 <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
 <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>
 
 
 
 
Message-ID: <29DF6FBA-EAF7-418C-9964-A1CBD62DDCFD@oracle.com>

It is precisely because security is more important now than ever and both the threat environment and
security measure landscape are changing that this proposal is important. There have been several good
suggestions brought up ?- like platform-independent access to platform-specific defences ?- as well as
various security challenges, but none of them can be tackled with the vigour they deserve when the
resources of the security team are invested in maintaining a very costly mechanism that was not only
designed for a different threat environment, but, more importantly, isn?t deployed by the vast majority
of Java users, even those that care deeply about security.

All JEPs are usually submitted toward the *end* of a long deliberation process, and are intended to gather
information that might have been overlooked, so the nothing could be further from the truth that this is
done ?without hesitation?. Indeed, no such new information has come to light yet.

We believe that the principle of least privilege would be better served without the Security Manager, 
and that security overall be improved with mechanisms that people actually use, some are already in place 
but will continue to improve with more resources available, which include, but certainly aren?t limited
to, strong encapsulation which was turned on in JDK 16, remote JFR streaming also added in that version, 
access control which will be separated from the Security Manager, and OS-level sandboxes. 

When taken over the entire ecosystem, it is our informed opinion that the number of attacks actually stopped 
by the Security Manager over the past decade does not justify effort it costs, while other mechanisms do.
It doesn?t even serve as a deterrent to attacks, because attackers know that it is rarely installed. Therefore, 
to improve security we must shift resources from efforts that, however intrinsically effective, don?t have the 
intended and much needed impact in the security of the Java ecosystem to those that do and will.

- Ron

> On 22 May 2021, at 11:58, Bernd Eckenfels  wrote:
> 
> Hello,
> 
> I have to agree with Peter here, we do remove a very valuable asset of the JVM platform. It might not easy to be used and not the most popular technology, but after all it was in the DNA of Java. In this JEP/Discussion there is not a single hesitation  to remove it. Please tell me you tried to find maintainers?
> 
> This whole discussion about using only secure libraries really makes me wonder if you know the realities of modern applications with hundreds of dependencies and the state of those, like there is still no easy way to limit XXE in upstream xerces. (Or Have you ever tried to set FSP on a Transformer?), limit deserialisation, restrict url handlers, impersonate Users (local and remote filesystem), run chroot child?s or pass credentials over named pipes. All mechanisms which are easier to do in other programming environments. There is a big hesitation to even offer those platform specific features.
> 
> I do hope the result of this discussion really is a set of new replacement technologies which allow to use least priveledge methods from the operating environments (be able to run as a different User token, drop permissions, use chroot/jail, fsuid, capsetp,setgroups and other impersonation methods) as thread scopes. Also facilities for multi-process solutions (named pipe servers, shared memory) might help with doing proper low priveledged architectures in the future (in addition to stuffing everything into rootless containers)
> 
> But more importantly we do need to get a handle on Defense in depth for libraries. LFI and Remote connections is a big part of that, but not limited to it.
> 
> Gruss
> Bernd
> 
> 
> --
> http://bernd.eckenfels.net
> Von: security-dev  im Auftrag von Peter Tribble 
> Gesendet: Saturday, May 22, 2021 11:11:43 AM
> An: Ron Pressler 
> Cc: Peter Firmstone ; David Black ; Alan Bateman ; security-dev at openjdk.java.net 
> Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries
>  
> On Sat, May 22, 2021 at 2:12 AM Ron Pressler  wrote:
> Let me be very clear: the proposers of this JEP, some of whom have worked on the Security Manager for the
> last twenty years, strongly believe that not only will its removal not harm Java?s security, but considerably
> improve it, as do the maintainers of other platforms who have decided to either not try to offer security
> through the deep stack-dependent sandbox model or did but have since also removed it. Their view is backed
> by security experts, both those working on OpenJDK and outside it.
> 
> I understand that maintaining the Security Manager is a burden. I understand the argument that not
> having the Security Manager would allow resources to be better deployed elsewhere. Yet here we're
> only seeing the one side. It would be good to be able to see the ways in which Java's security would
> be improved by this JEP, because at the moment we're having to take that on trust.
>  
> While I seriously hope you don?t actually believe a decision was made before publication, it is also obviously
> true that this wouldn?t have been proposed in the first place without *a lot* of thought, study and discussion.
> The proposal was made only after it was clear this was a very, *very* strong case, and that the chances of finding
> fault with it are low. It wasn?t put up after someone just had an idea. It is, therefore, not entirely 
> surprising that no one has been able to give any relevant arguments against it. Clearly, you have had far less 
> time to think about it, but I can?t seem to steer your arguments in a direction that?s relevant to what is actually 
> the issue.
> 
> I understand you?re invested in the Security Manager and that its removal would impose real costs on you. I am even
> willing to believe that you actually believe that, despite what studies show, despite what experts say, despite
> what the developers of Java say, despite what the developers of *all* other mainstream software platforms with 
> an emphasis on security, both new and old ?- from .NET to WebAssembly ?- have concluded after decades of experience, 
> that the Security Manager is not only the best way to secure Java but apparently the only one. Maybe you?re right 
> and those others are wrong, but please accept that we all want to improve Java?s security, we just disagree with you 
> on the best way to do it.
> 
> Yes, additional security measures, whatever they are, would provide additional security. But if the choice is 
> between measure A and measure B -? you *can?t* have both ?- you pick the one that is *more* effective per cost.
> 
> And yet the proposal in front of us is to remove measure A, which *will* reduce security for those using it.
> Where's the proposal for measure B, so we can evaluate whether the tradeoff between A and B is beneficial?
>  
> None of your arguments so much as glance in that direction, and they don?t acknowledge the fact that Java security 
> would be hardly affected by the Security Manager?s removal even without better protection elsewhere for the simple 
> reason that it is hardly ever installed, including on the most security-critical applications, whose defences 
> apparently aren?t so feeble even today. In any event, if the question is, do we want a perimeter fence and security 
> cameras *XOR* locks on all room doors, the argument that they provide security through different mechanisms so we 
> should have both completely misunderstands the question. I am also confused by your point about multi-user
> applications. Of course different users have different access, but surely you are aware that very few applications
> do that using the Security Manager, which isn?t needed ?- and is rarely used -? for that purpose.
> 
> Short of making relevant arguments, I would urge you again to focus on suggestions to reduce the harm this proposal 
> would cause you.
> 
> ? Ron
> 
> 
> 
> > On 22 May 2021, at 00:17, Peter Firmstone  wrote:
> > 
> > I had hoped by end of this discussion, that there would at least be an understanding of what OpenJDK is so hastily choosing to destroy.
> > 
> > Once it is gone, it will be irretrievable, it will never be possible to lock down the JVM so securely again.
> > 
> > 
> > On 21/05/2021 11:06 pm, Ron Pressler wrote:
> >> 
> >>> On 21 May 2021, at 12:52, Peter Firmstone  wrote:
> >>> 
> >>> It's quite clear this will be pushed through anyway,
> >>> 
> >> No, not *anyway*, but given the fact that the community consists of millions of users, this
> >> proposal has been well-publicised,
> > 
> > 
> > I discovered the proposal on the 11th of the May on a mailing list I was subscribed to and I almost missed it.   Yes, it will be pushed through regardless, clearly the decision was made before publication.   Everyone saw applets coming, if the developers were serious about supporting applets, they would have designed a stripped down subset of Java, a JVM specifically suited that task which, didn't include things like XML or serialization.
> > 
> > Just think, Applets were killed because of their atrocious security.   How ironic.
> > 
> > 
> >>> The granularity is not arbitrary, you said by class, which is incorrect.
> >>> 
> >>> Granularity is by a combination of one or more of the following:
> >>> 
> >>>     ? ProtectionDomain
> >>>     ? CodeSource
> >>>     ? Code signers
> >>>     ? ClassLoader
> >>>     ? Principals.
> >> What I said is correct. Assigning a ProtectionDomain to a class is possible, though not to a method
> >> (certainly not in code you can?t modify). In fact, ProtectionDomain is defined as ?a set of classes,?
> >> i.e. class granularity. In particular, that is the granularity that instrumentation with doPrivileged
> >> aims to address, and that is one of the Security Manager?s most defining features.
> > 
> > It may be possible to assign a ProtectionDomain, to a single class, but that doesn't make your assertions correct, you should be quoting common use cases, I have never seen an example of assigning permissions to a single class, besides, it requires a dynamic policy to do that, and Java doesn't have one by default, so you can't use PolicyFile to assign it permissions.   Maybe you could use it to encapsulate ObjectInputStream with no permissions, then no one could grant it permissions, so that would be useful for Security.  It doesn't change class resolution or visibility. But OpenJDK didn't do that, why not?
> > 
> > 
> > What use case would there be to assign a ProtectionDomain to a method?
> > 
> > Just use a permission check in the method, or wrap a sensitive class with a decorator before publication:
> > 
> > https://urldefense.com/v3/__http://svn.apache.org/viewvc/river/permission_delegates/src/main/java/org/apache/river/api/delegates/package.html?view=markup__;!!GqivPVa7Brio!LdTftZDa5TWyQFfdIFBzHe3OFQMmnVFcIa0TeUz2kNlVyBaY475E1rWMksv_wkow7A$ 
> > But these are corner cases.
> > 
> > More useful cases are for isolation, such as JEE.
> > 
> > 
> >> 
> >> Restricting access by principal at the application level does not require the Security Manager, so that
> >> part is irrelevant, and, in fact, not only Principal, but also Permission, and even CodeSource and
> >> ProtectionDomain are *not* being proposed for terminal deprecation or even deprecation by this JEP.
> > 
> > 
> > I guess your use case is a desktop application running in a single process?
> > 
> > What about a multi user server application running in a single process?   Now we have to spawn multiple processes for each user, that's hardly efficient or performant is it?
> > 
> > 
> >> 
> >>> I would like to understand this pain that is being caused to a far greater number of people?   So far information has been scarce and it seems more of an excuse, as it's very light on detail.  I would guess it's the pain of having to update policy files and making sure tests pass with security enabled.
> >> The pain is that the high cost of maintaining the Security Manager comes at the expense of
> >> other security measures that, we believe, provide far more security value to the Java ecosystem
> >> as a whole.
> > 
> > 
> > Such as?
> > 
> > 
> >>> I think the results of locking down the JVM to principles of least privilege are totally worth it and a saleable commodity in the current global environment.
> >> I absolutely accept the principle of least privilege. I do not accept that the marginal cost/benefit
> >> of applying it at class granularity yields its best application.
> > 
> > 
> > I agree that there's little value for class granularity, but you are applying a corner case that although possible, is never applied in practice, and applying it with a broad brush, then using it as an argument against, please stop making this false assertion.   Just because you can do something, doesn't mean that you should.   Just because you can walk in front of a passing train, doesn't mean you should sir.
> > 
> > There is however a significant benefit for applying the principle of least privilege.
> > 
> > It can be assigned to Principal and Code signer granularity, that's actually quite coarse grained.  It's very flexible, unlike white listing Serializable classes.
> > 
> >>> Sure, theoretical things might, but there's no implementation in existence.  It has been quite affordable for me, so I wish to understand this pain, because I currently don't, I'm already using the latest encryption, static analysis, secure coding practices, validating input, sanitizing data etc.
> >> There are, though. Here are some: JFR, the module system, crypto protocols and ad-hoc mechanisms for
> >> specific vulnerable components (serialization, XML etc.). Maintaining the Security Manager comes at their
> >> expense -- some require urgent improvements like adding more events to JFR and closing down gaps in the
> >> module system?s defences -- and we believe investing in them has a better security ROI overall.
> > 
> > Don't be rude.  These are not alternatives, some are complementary, but not one provides the missing functionality.
> > 
> > And yuck, serialization, XML, vulnerable components should have been given un-privilged ProtectionDomains, so they couldn't do anything privileged while on the stack, like Perl Taint mode.   Or better yet alternative implementations created that practice data hygiene.
> > 
> > Java Serialization is a good example of good money thrown after bad, that has a far greater development cost.   Why did you (yes you OpenJDK) make Lambda's serializable?  Inner classes?  Yuck! Put it in a separate library, let people that use it download it, then the platform isn't made insecure for those who don't want it, this is a good use case for your new module system.
> > 
> > Once SecurityManager is gone, attackers will likely be able to bypass your feeble protections, such as whitelisting classes to be de-serialized; they only need to find a way to change a property prior to initialization, the first use of ObjectInputStream, which is quite easy if an application doesn't use it.  In future developers who don't use Java serialization will need to make sure it has been initialized so it can't be used as an attack vector, who will remember to do that?
> > 
> >>> Other techniques that are yet to be developed.   OpenJDK is deprecating SecurityManager prior to the implementation of it's replacement, a little more notice would have been nice.   I'm ready for you to deprecate Serialization, we saw that coming, but this is just completely unexpected out of left field.
> >> First, any deprecation proposal could be said to be unexpected until it is proposed. But that is why
> >> we have a deprecation policy that makes the process gradual and gives people time to adjust. Second, I
> >> don?t think this is "out of left field" at all. The writing on the wall was pretty clear when, after twenty-five
> >> years, few projects use the Security Manager and few libraries are properly instrumented for it, other platforms
> >> have decided not to adopt a similar model, and those few that have have already abandoned it some years ago.
> > 
> > 
> > Library's don't need to be instrumented for it, the Java platform is already and provides the necessary protection for network connections, file access and class loading for example.
> > 
> > 
> > - Peter.
> > 
> 
> 
> 
> -- 
> -Peter Tribble
> http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/


From mstjohns at comcast.net  Sat May 22 16:18:04 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Sat, 22 May 2021 12:18:04 -0400
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: 
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
 
Message-ID: <765fa247-ce3c-dad7-8240-1402790c8ba9@comcast.net>

In line

On 5/21/2021 5:01 PM, Xue-Lei Andrew Fan wrote:
> On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng  wrote:
>
>>> This change updates SunJCE provider as below:
>>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation.
>>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>>
>>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class.
>>>
>>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>>>
>>> Thanks,
>>> Valerie
>> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>>
>>   - Merge master into JDK-8248268
>>   - Minor update to address review comments.
>>   - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>>     KWParameters and KWPParameters.
>>   - Refactor code to reduce code duplication
>>     Address review comments
>>     Add more test vectors
>>   - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>     AES/KWP/NoPadding
>>   - Restored Iv algorithm parameters impl.
>>   - 8248268: Support KWP in addition to KW
>>     
>>     Updated existing AESWrap support with AES/KW/NoPadding cipher
>>     transformation. Added support for AES/KWP/NoPadding and
>>     AES/KW/PKCS5Padding support to SunJCE provider.
> src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
>
>> 48:
>> 49:     public AESParameters() {
>> 50:         core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);
> A cipher object may not take different IV sizes at the same time.  I was just wondering how it could be used in practice.  Maybe something like:

The mode is KW - it has a fixed length 8 byte non-iv integrity tag.??? 
KWP is a special case of KW where there's still an 8 byte tag, but part 
of it is interpreted by KWP to figure out how much padding was 
included.?? KW (AKA RFC3394) permits user (actually specification 
specified) IV values.? KWP (aka RFC5649) does not.

I'd treat KWP as a final (in the Java final sense) extension to KW with 
a fixed AIV flag value and a defined interpretation for the 8 byte AIV 
tag.? E.g. if you try to specify an IV for KWP, it should fail.?? If 
someone else wants to do something like KWP or even twiddle with the 4 
byte AIV, let them do their own KW wrap around - which they should be 
able to do that via the KW/NoPadding model by specifying their own AIV.? 
That should improve interoperability by preventing some monkey see 
monkey do errors.

This is sort of one reason I was arguing for AES/KW/KWPPadding rather 
than AES/KWP/NoPadding.


Mike



>
>
> AlgorithmParameters algParams = AlgorithmParameters.getInstance("AES");
> algParams.init(ivParameterSpec);
>
> The IV parameter is given with the init() method.  Then, it may be not necessary to construct the BlockCipherParamsCore object will all potential IV sizes.  See the comments in BlockCipherParamsCore.
>
> src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 52:
>
>> 50:     private byte[] iv = null;
>> 51:
>> 52:     private int[] moreSizes = null;
> The moreSizes is not used other than the init() method field.  It may be not easy to check the specific size if we cache all supported sized in the object.  For example, if the required IV size if 8 bytes, it may be a problem about how to make sure the iv size is 8 bytes exactly for a specific algorithm.
>
> Maybe, we could just have a ivSize filed.  The default value is block_size, which coupe be set with the init(ivParameterSpec) method.
>
>
>      ....
>      private int ivSize;
>      ...
>     BlockCipherParamsCore(int blkSize) {
>         block_size = blkSize;
>         ivSize = blkSize;
>      }
>      ...
>     void init(AlgorithmParameterSpec paramSpec) {
>          ivSize = ...;  // reset IV size.
>      }
>
>      // use ivSize while encoding and decoding.
>
> src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 81:
>
>> 79:                         expectedLen + " bytes long");
>> 80:         }
>> 81:         iv = tmpIv.clone();
> The moreSizes is not used after initialization.  The iv/tmpIv could be a value other than the block_size.   The getEncoded() method would use the iv value for the encoding.  While in the decoding method init(byte[]) method, the IV sizes other block_size is not considered, and IOE will be thrown.  Could this be a problem?
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2404




From xuelei at openjdk.java.net  Sat May 22 17:57:15 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Sat, 22 May 2021 17:57:15 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
Message-ID: <70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com>

On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng  wrote:

>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>> 
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
>> 
>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge master into JDK-8248268
>  - Minor update to address review comments.
>  - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>    KWParameters and KWPParameters.
>  - Refactor code to reduce code duplication
>    Address review comments
>    Add more test vectors
>  - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>    AES/KWP/NoPadding
>  - Restored Iv algorithm parameters impl.
>  - 8248268: Support KWP in addition to KW
>    
>    Updated existing AESWrap support with AES/KW/NoPadding cipher
>    transformation. Added support for AES/KWP/NoPadding and
>    AES/KW/PKCS5Padding support to SunJCE provider.

Good points, Mike!  Thank you!

> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
> > src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
> > > 48:
> > > 49:     public AESParameters() {
> > > 50:         core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);
> > > A cipher object may not take different IV sizes at the same time.  I was just wondering how it could be used in practice.  Maybe something like:
> 
> The mode is KW - it has a fixed length 8 byte non-iv integrity tag.???
> KWP is a special case of KW where there's still an 8 byte tag, but part
> of it is interpreted by KWP to figure out how much padding was
> included.?? KW (AKA RFC3394) permits user (actually specification
> specified) IV values.? KWP (aka RFC5649) does not.
> 
Hm, I missed this point.  KW (RFC 3394) supports Alternative IV (AIV), while KWP is just a case about how to construct the alternative IV for KWP operations.

> I'd treat KWP as a final (in the Java final sense) extension to KW with
> a fixed AIV flag value and a defined interpretation for the 8 byte AIV
> tag.? E.g. if you try to specify an IV for KWP, it should fail.?? If
> someone else wants to do something like KWP or even twiddle with the 4
> byte AIV, let them do their own KW wrap around - which they should be
> able to do that via the KW/NoPadding model by specifying their own AIV.?
> That should improve interoperability by preventing some monkey see
> monkey do errors.
> 

I agreed.  Maybe, we could do:
1. Support Alternative IV for KW, for the flexibility as described in section 2.2.3.2 of RFC 3394.
2. Use default IV if no AIV specified for KW, as described in section 2.2.3.1 of RFC 3394.
3. Use a fixed IV for KWP, as described in section 3of RFC 5649.

> This is sort of one reason I was arguing for AES/KW/KWPPadding rather
> than AES/KWP/NoPadding.
> 

I thought of the "AES/KW/KWPPadding" style as well.  The "AES/KWP/NoPadding" looks a little bit weird to me because there is padding while we call it with "NoPadding".

KWP is not exactly like the traditional AES/CBC/PKCS5Padding, where the components could be treated separately.  The padding scheme of KWP impact the IV as well.  So it was arguable to me.

Finally I feel better of the "AES/KWP/NoPadding" when I read the NIST SP title again, "Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping".  Maybe, it is an industry accepted notation to treat KWP as a block cipher mode.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From Alan.Bateman at oracle.com  Sat May 22 18:56:17 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 22 May 2021 19:56:17 +0100
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
 
 <3187A2DB-A41A-4661-8FBF-72E50AAC16A6@oracle.com>
 <4ed03c6c-b07d-4aef-b623-b9ac1b6ab0a9@zeus.net.au>
 <716AE357-591B-45DE-B5FE-D9C65A42099A@oracle.com>
 
 
 
 
Message-ID: <6519f502-52c7-311f-1cce-cd39b4f9ad87@oracle.com>

On 22/05/2021 11:58, Bernd Eckenfels wrote:
> :
>
> This whole discussion about using only secure libraries really makes 
> me wonder if you know the realities of modern applications with 
> hundreds of dependencies and the state of those, like there is still 
> no easy way to limit XXE in upstream xerces. (Or Have you ever tried 
> to set FSP on a Transformer?), limit deserialisation, restrict url 
> handlers, impersonate Users (local and remote filesystem), run chroot 
> child?s or pass credentials over named pipes. All mechanisms which are 
> easier to do in other programming environments. There is a big 
> hesitation to even offer those platform specific features.
>
You've touched on a number of topics here, some of them quite far away 
from JEP 411 but okay.

I think the issues with deploying an applications with hundreds of 
dependences and with a SM are well understood here. It tends to be 
whack-a-mole because so many libraries were developed without any 
consideration for the SM execution mode. The result is often granting 
AllPermission to many libraries just to get something working.

XXE and secure XML processing is something that needs to be decoupled 
from the SM. As the JEP lists, there is potential future work to enable 
FSP by default. Now might be the time to bring up usability and other 
issues with FSP as I think it will be tricky transition to move to 
secure by default.? I can't comment on Xerces as the code maintained in 
OpenJDK has diverged quite a bit, esp. with security features.

There has been significant efforts to limit deserialization.? JEP 415 is 
a candidate right now, as a follow from on JEP 290.

If integration with native code and system calls is part of your concern 
then looking at Project Panama's foreign function API as it has made 
great strides in the last year or so. JEP 412 is targeted to JDK 17 to 
continue the incubation of the API and trying it out with code that uses 
named pipes would be great. JEP 380 added Unix domain socket support in 
JDK 16 and that includes the ability to obtain peer credentials, maybe 
that is close to what you are looking for.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mstjohns at comcast.net  Sat May 22 23:32:43 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Sat, 22 May 2021 19:32:43 -0400
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: <70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com>
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
 <70_tsquse1yiy8-C82ZamQ_uTuIDbh2b-kp_yd7NYmM=.3ce2c9a8-616b-4042-9e24-804f6485ec1f@github.com>
Message-ID: <1333ac24-5a85-5c39-2694-7b580aa9a385@comcast.net>

On 5/22/2021 1:57 PM, Xue-Lei Andrew Fan wrote:
> On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng  wrote:
>
>>> This change updates SunJCE provider as below:
>>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation.
>>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>>>
>>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class.
>>>
>>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>>>
>>> Thanks,
>>> Valerie
>> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>>
>>   - Merge master into JDK-8248268
>>   - Minor update to address review comments.
>>   - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>>     KWParameters and KWPParameters.
>>   - Refactor code to reduce code duplication
>>     Address review comments
>>     Add more test vectors
>>   - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>     AES/KWP/NoPadding
>>   - Restored Iv algorithm parameters impl.
>>   - 8248268: Support KWP in addition to KW
>>     
>>     Updated existing AESWrap support with AES/KW/NoPadding cipher
>>     transformation. Added support for AES/KWP/NoPadding and
>>     AES/KW/PKCS5Padding support to SunJCE provider.
> Good points, Mike!  Thank you!
>
>> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
>>> src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
>>>> 48:
>>>> 49:     public AESParameters() {
>>>> 50:         core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);
>>>> A cipher object may not take different IV sizes at the same time.  I was just wondering how it could be used in practice.  Maybe something like:
>> The mode is KW - it has a fixed length 8 byte non-iv integrity tag.???
>> KWP is a special case of KW where there's still an 8 byte tag, but part
>> of it is interpreted by KWP to figure out how much padding was
>> included.?? KW (AKA RFC3394) permits user (actually specification
>> specified) IV values.? KWP (aka RFC5649) does not.
>>
> Hm, I missed this point.  KW (RFC 3394) supports Alternative IV (AIV), while KWP is just a case about how to construct the alternative IV for KWP operations.

Yes.? Sorry if I wasn't clearer in earlier emails.

>
>> I'd treat KWP as a final (in the Java final sense) extension to KW with
>> a fixed AIV flag value and a defined interpretation for the 8 byte AIV
>> tag.? E.g. if you try to specify an IV for KWP, it should fail.?? If
>> someone else wants to do something like KWP or even twiddle with the 4
>> byte AIV, let them do their own KW wrap around - which they should be
>> able to do that via the KW/NoPadding model by specifying their own AIV.?
>> That should improve interoperability by preventing some monkey see
>> monkey do errors.
>>
> I agreed.  Maybe, we could do:
> 1. Support Alternative IV for KW, for the flexibility as described in section 2.2.3.2 of RFC 3394.

I think that's acceptable.? Hmm... is it possible to make the set ICV 
call protected rather than public??? Generally, the defined ICVs match 
up with specific algorithm OIDS.? You shouldn't see a third one unless 
someone defines a brand new variant.? But you want to make it possible 
for someone to do an extension.

> 2. Use default IV if no AIV specified for KW, as described in section 2.2.3.1 of RFC 3394.
Works.? Or see the above.
> 3. Use a fixed IV for KWP, as described in section 3of RFC 5649.
Yes.
>
>> This is sort of one reason I was arguing for AES/KW/KWPPadding rather
>> than AES/KWP/NoPadding.
>>
> I thought of the "AES/KW/KWPPadding" style as well.  The "AES/KWP/NoPadding" looks a little bit weird to me because there is padding while we call it with "NoPadding".
>
> KWP is not exactly like the traditional AES/CBC/PKCS5Padding, where the components could be treated separately.  The padding scheme of KWP impact the IV as well.  So it was arguable to me.

We keep referring to it as an IV? - but it isn't - it's an Integrity 
Check Value.? Unlike an IV, it doesn't inform the decryption stage, it's 
only checked after the decryption is complete.? (E.g. in a mode with an 
IV, you need to know the IV before you encrypt and before you decrypt).? 
Then there's this from Section 6.3 of SP800-38F.

> Let S = ICV2|| [len(P)/8]32 || P|| PAD


Step 5 of the KWP-AE algorithm basically passes the A65959A6 value 
pre-prepended to the pad length both pre-pended to the padded data 
through to W().

The equivalent for KW-AE is step 2 which passes the ICV1 value in 
pre-pended to the plaintext.? (e.g. these are the inputs to W()).

The underlying function W() is doing what it does without any reference 
to the actual value of the ICV both on encrypt and decrypt.

So the differences between KWP and KW are actually in how the plain text 
data is marshalled? and unmarshalled and the checking they do on the 
decrypted ICVs, not in the actual cryptography.

>
> Finally I feel better of the "AES/KWP/NoPadding" when I read the NIST SP title again, "Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping".  Maybe, it is an industry accepted notation to treat KWP as a block cipher mode.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2404

Think of it this way:? W() and W'() are the actual cryptographic actions 
that implement key wrapping - the mode if you will.? KW-AE and KWP-AE 
are the NoPadding and KWPPadding instantiations of that mode.

Another way of looking at that - KW-AE can't use a variant ICV. (Or at 
least I can't find a place where it's permitted - I was mistaken in 
including it above as the same as RFC3394).? If you're going to call it 
KWP/NoPadding and KW/NoPadding, then maybe you shouldn't support the 
provision of a different ICV as this isn't supported by SP800-38F.

*shrug*

I don't think that Java nomenclature and NIST nomenclature have to match 
up.? But ideally, Java nomenclature should try to be consistent amongst 
itself.? AES/KWP/NoPadding just sounds less right than AES/KW/KWPPadding.

Mike





-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From mullan at openjdk.java.net  Sun May 23 16:40:59 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Sun, 23 May 2021 16:40:59 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v3]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
Message-ID: 

On Fri, 21 May 2021 15:27:39 GMT, Daniel Fuchs  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>
> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
> 
>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>> 103:  * {@systemProperty java.security.manager} system property is set to the
>> 104:  * special token "{@code allow}", then a security manager will not be set at
> 
> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.

Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, I would just keep the first one. (I think it's ok to have more than one, if they are defined in different APIs).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Sun May 23 20:52:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Sun, 23 May 2021 20:52:08 GMT
Subject: RFR: 8267584: The java.security.krb5.realm system property only needs
 to be defined once
Message-ID: <6aG3bNp9mUsl7earEpBeasgNVhkxiHbqogQhlsCks1M=.fb97e2e7-c7d2-4390-92fd-f702ffd13949@github.com>

A system property only needs to be put in a `{@systemProperty}` tag where it's first defined. For this one, it's https://github.com/openjdk/jdk/blob/cf21c5ef116c136f09ac5be0d68f02553d0c7a70/src/java.security.jgss/share/classes/javax/security/auth/kerberos/package-info.java#L41.

-------------

Commit messages:
 - 8267584: The java.security.krb5.realm system property only needs to be defined once

Changes: https://git.openjdk.java.net/jdk/pull/4159/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4159&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267584
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4159.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4159/head:pull/4159

PR: https://git.openjdk.java.net/jdk/pull/4159


From tvaleev at openjdk.java.net  Mon May 24 04:33:42 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 24 May 2021 04:33:42 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev  wrote:

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

src/java.base/share/classes/java/util/jar/JarFile.java line 201:

> 199:                 MULTI_RELEASE_FORCED = true;
> 200:             }
> 201:             default -> {

Here, explicit `case "true"` disappeared. Not sure if it's important to keep it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Mon May 24 04:33:40 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 24 May 2021 04:33:40 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
Message-ID: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>

Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.

I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

-------------

Commit messages:
 - 8267587: Update java.util to use enhanced switch

Changes: https://git.openjdk.java.net/jdk/pull/4161/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267587
  Stats: 887 lines in 17 files changed: 113 ins; 339 del; 435 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161


From dfuchs at openjdk.java.net  Mon May 24 09:03:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 09:03:10 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4138


From pconcannon at openjdk.java.net  Mon May 24 13:44:41 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 24 May 2021 13:44:41 GMT
Subject: RFR: 8267110: Update java.util to use instanceof pattern variable
 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Reverted changes made to files in java.util.concurrent
 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Reverted changes in java/util/Formatter as primitive to boxed types may have semantic/performance implications
 - Merge remote-tracking branch 'origin/master' into JDK-8267110
 - 8267110: Update java.util to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4088/files
  - new: https://git.openjdk.java.net/jdk/pull/4088/files/2c076a55..9bca9400

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4088&range=03-04

  Stats: 1931 lines in 65 files changed: 1061 ins; 429 del; 441 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4088.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4088/head:pull/4088

PR: https://git.openjdk.java.net/jdk/pull/4088


From dfuchs at openjdk.java.net  Mon May 24 13:50:12 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 24 May 2021 13:50:12 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev  wrote:

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

src/java.base/share/classes/java/util/regex/CharPredicates.java line 217:

> 215:             case "WORD" -> WORD();
> 216:             default -> null;
> 217:         };

This file has lots of changes which are difficult to review. Maybe it should be split out of this PR.

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 261:

> 259:             ZipEntry e = current.entry;
> 260:             switch (e.method) {
> 261:                 case DEFLATED -> {

Same remark here - it's not clear what's going on.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From weijun at openjdk.java.net  Mon May 24 13:53:34 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:34 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  keep only one systemProperty tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/c4221b5f..1f6ff6c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=02-03

  Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Mon May 24 13:53:37 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 13:53:37 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
 
 
Message-ID: 

On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan  wrote:

>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>> 
>>> 102:  * method will throw an {@code UnsupportedOperationException}). If the
>>> 103:  * {@systemProperty java.security.manager} system property is set to the
>>> 104:  * special token "{@code allow}", then a security manager will not be set at
>> 
>> Can/should the `{@systemProperty ...}` tag be used more than once for a given system property? I thought it should be used only once, at the place where the system property is defined. Maybe @jonathan-gibbons can offer some more guidance on this.
>
> Good point. I would remove the extra @systemProperty tags on lines 103, 106, and 113. Also, in `System.setSecurityManager` there are 3 @systemProperty java.security.manager tags, so we should remove those too.

New commit pushed. There is only one `@systemProperty` tag now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From mullan at openjdk.java.net  Mon May 24 14:00:03 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Mon, 24 May 2021 14:00:03 GMT
Subject: RFR: 8267584: The java.security.krb5.realm system property only
 needs to be defined once
In-Reply-To: <6aG3bNp9mUsl7earEpBeasgNVhkxiHbqogQhlsCks1M=.fb97e2e7-c7d2-4390-92fd-f702ffd13949@github.com>
References: <6aG3bNp9mUsl7earEpBeasgNVhkxiHbqogQhlsCks1M=.fb97e2e7-c7d2-4390-92fd-f702ffd13949@github.com>
Message-ID: 

On Sun, 23 May 2021 20:42:24 GMT, Weijun Wang  wrote:

> A system property only needs to be put in a `{@systemProperty}` tag where it's first defined. For this one, it's https://github.com/openjdk/jdk/blob/cf21c5ef116c136f09ac5be0d68f02553d0c7a70/src/java.security.jgss/share/classes/javax/security/auth/kerberos/package-info.java#L41.

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4159


From weijun at openjdk.java.net  Mon May 24 14:05:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 14:05:08 GMT
Subject: RFR: 8267184: Add -Djava.security.manager=allow to tests calling
 System.setSecurityManager [v4]
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: 

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:

 - Merge branch 'master' into 8267184
 - feedback from Phil
   
   reverted:
 - adjust order of VM options
 - test for awt
 - test for hotspot-gc
 - test for compiler
 - test for net
 - test for core-libs
 - test for beans
 - test for xml
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/37f74de7...412264a0

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4071/files
  - new: https://git.openjdk.java.net/jdk/pull/4071/files/9a3ec578..412264a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4071&range=02-03

  Stats: 12227 lines in 453 files changed: 6978 ins; 3721 del; 1528 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4071.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4071/head:pull/4071

PR: https://git.openjdk.java.net/jdk/pull/4071


From weijun at openjdk.java.net  Mon May 24 15:33:09 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 15:33:09 GMT
Subject: RFR: 8266400: importkeystore fails to a password less pkcs12
 keystore
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 May 2021 19:01:21 GMT, Hai-May Chao  wrote:

> Please review the fix to address keytool -importkeystore failure when importing to a password-less PKCS12 keystore.

Marked as reviewed by weijun (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4119


From hchao at openjdk.java.net  Mon May 24 15:43:07 2021
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Mon, 24 May 2021 15:43:07 GMT
Subject: Integrated: 8266400: importkeystore fails to a password less pkcs12
 keystore
In-Reply-To: 
References: 
Message-ID: 

On Wed, 19 May 2021 19:01:21 GMT, Hai-May Chao  wrote:

> Please review the fix to address keytool -importkeystore failure when importing to a password-less PKCS12 keystore.

This pull request has now been integrated.

Changeset: f2d880c1
Author:    Hai-May Chao 
URL:       https://git.openjdk.java.net/jdk/commit/f2d880c11a99ef587e7e7c0398f0834c32a22d63
Stats:     92 lines in 2 files changed: 89 ins; 0 del; 3 mod

8266400: importkeystore fails to a password less pkcs12 keystore

Reviewed-by: weijun

-------------

PR: https://git.openjdk.java.net/jdk/pull/4119


From weijun at openjdk.java.net  Mon May 24 15:48:08 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 15:48:08 GMT
Subject: Integrated: 8267584: The java.security.krb5.realm system property
 only needs to be defined once
In-Reply-To: <6aG3bNp9mUsl7earEpBeasgNVhkxiHbqogQhlsCks1M=.fb97e2e7-c7d2-4390-92fd-f702ffd13949@github.com>
References: <6aG3bNp9mUsl7earEpBeasgNVhkxiHbqogQhlsCks1M=.fb97e2e7-c7d2-4390-92fd-f702ffd13949@github.com>
Message-ID: 

On Sun, 23 May 2021 20:42:24 GMT, Weijun Wang  wrote:

> A system property only needs to be put in a `{@systemProperty}` tag where it's first defined. For this one, it's https://github.com/openjdk/jdk/blob/cf21c5ef116c136f09ac5be0d68f02553d0c7a70/src/java.security.jgss/share/classes/javax/security/auth/kerberos/package-info.java#L41.

This pull request has now been integrated.

Changeset: 838a0071
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/838a0071030e9c8b9ab57df39a4e0384d433a2bc
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8267584: The java.security.krb5.realm system property only needs to be defined once

Reviewed-by: mullan

-------------

PR: https://git.openjdk.java.net/jdk/pull/4159


From ascarpino at openjdk.java.net  Mon May 24 16:40:18 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 24 May 2021 16:40:18 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 17 May 2021 22:42:40 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - review comment updates
>>  - Fixed the lack of overlap detection with GCMEncrypt.update()
>
> src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 203:
> 
>> 201:         // allocating and copying for direct bytebuffers
>> 202:         if (!src.isDirect() && !dst.isDirect() &&
>> 203:             !src.isReadOnly() && !dst.isReadOnly()) {
> 
> Why do we need to check for src being isReadOnly() since we are not writing bytes into src? As for dst, if it's read only, then we should probably not proceed further? The other update method which takes ByteBuffer dst did not check if it's read only. A bit inconsistent?

src.array() throws an exception if it's read only

> src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 283:
> 
>> 281:         // allocating and copying for direct bytebuffers
>> 282:         if (!src.isDirect() && !dst.isDirect() &&
>> 283:             !src.isReadOnly() && !dst.isReadOnly()) {
> 
> Same question regarding the isReadOnly() calls as in the update(ByteBuffer, ByteBuffer) method.

src.array() throws an exception if it's read only

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Mon May 24 16:40:19 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 24 May 2021 16:40:19 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: 

On Tue, 18 May 2021 17:24:13 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 189:
> 
>> 187:             ct.position(ct.position());
>> 188:             return processed;
>> 189:         } else if (!ct.isReadOnly()) {
> 
> Maybe you meant "ct.hasArray()" instead of "!ct.isReadOnly()"?

hasArray() checks both isReadonly() and isDirect().  Since I already did isDirect() in the previous if, I just need to check readonly here

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From ascarpino at openjdk.java.net  Mon May 24 16:58:15 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 24 May 2021 16:58:15 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
Message-ID: <4QSTdoOQ-HlefjMITN2YHemvfUvKjoM9sSLZqMDDqws=.667a5f1b-7dfa-4d24-9ea1-ce5e112a10ee@github.com>

On Tue, 18 May 2021 18:38:40 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 338:
> 
>> 336:     public int doFinal(ByteBuffer src, ByteBuffer dst) {
>> 337:         return doFinal(src, src.remaining());
>> 338:     }
> 
> Have you considered changing the argument list of existing update/doFinal(...) methods? Less calls.

I had considered it, but there are a number of methods, particularly in the in decrypt operation, where the non-interface methods are called.  I didn't think it was right for all those calls to have "null" and "0" for output arguments they don't use.
It's possible this interface may be not needed with a future Intel intrinsic, so we shall see.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From weijun at openjdk.java.net  Mon May 24 17:02:13 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 17:02:13 GMT
Subject: Integrated: 8267184: Add -Djava.security.manager=allow to tests
 calling System.setSecurityManager
In-Reply-To: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
References: <9GkJHHNjRWV53FTpAfgcS7lF6sIAqXoaPRb7TlLwjY8=.fe57d8aa-de94-48b6-8026-7e5c30b01a4e@github.com>
Message-ID: <3rH0Qzq38uj4gzgkoDyLE_SnE47c8710ZvGAeSK6UA4=.e080d8bc-838b-4d62-87ff-ca8b12445c8a@github.com>

On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang  wrote:

> Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
> 
> With JEP 411 and the default value of `-Djava.security.manager` becoming `disallow`, tests calling `System.setSecurityManager()`  need `-Djava.security.manager=allow` when launched. This PR covers such changes for tier1 to tier3 (except for the JCK tests).
> 
> To make it easier to focus your review on the tests in your area, this PR is divided into multiple commits for different areas (~~serviceability~~, ~~hotspot-compiler~~, ~~i18n~~, ~~rmi~~, ~~javadoc~~, swing, 2d, ~~security~~, ~~hotspot-runtime~~, ~~nio~~, ~~xml~~, ~~beans~~, ~~core-libs~~, ~~net~~, ~~compiler~~, ~~hotspot-gc~~). Mostly the rule is the same as how Skara adds labels, but there are several small tweaks:
> 
> 1. When a file is covered by multiple labels, only one is chosen. I make my best to avoid putting too many tests into `core-libs`. If a file is covered by `core-libs` and another label, I categorized it into the other label.
> 2. If a file is in `core-libs` but contains `/xml/` in its name, it's in the `xml` commit.
> 3. If a file is in `core-libs` but contains `/rmi/` in its name, it's in the `rmi` commit.
> 4. One file not covered by any label -- `test/jdk/com/sun/java/accessibility/util/8051626/Bug8051626.java` -- is in the `swing` commit.
> 
> Due to the size of this PR, no attempt is made to update copyright years for all files to minimize unnecessary merge conflict.
> 
> Please note that this PR can be integrated before the source changes for JEP 411, as the possible values of this system property was already defined long time ago in JDK 9.
> 
> Most of the change in this PR is a simple adding of `-Djava.security.manager=allow` to the `@run main/othervm` line. Sometimes it was not `othervm` and we add one. Sometimes there's no `@run` at all and we add the line.
> 
> There are several tests that launch another Java process that needs to call the `System.setSecurityManager()` method, and the system property is added to `ProcessBuilder`, `ProcessTools`, or the java command line (if the test is a shell test).
> 
> 3 langtools tests are added into problem list due to [JDK-8265611](https://bugs.openjdk.java.net/browse/JDK-8265611).
> 
> 2 SQL tests are moved because they need different options on the `@run` line but they are inside a directory that has a `TEST.properties`:
> 
> rename test/jdk/java/sql/{testng/test/sql/othervm => permissionTests}/DriverManagerPermissionsTests.java (93%)
> rename test/jdk/javax/sql/{testng/test/rowset/spi => permissionTests}/SyncFactoryPermissionsTests.java (95%)
>  ```
> 
> The source change for JEP 411 is at https://github.com/openjdk/jdk/pull/4073.

This pull request has now been integrated.

Changeset: 640a2afd
Author:    Weijun Wang 
URL:       https://git.openjdk.java.net/jdk/commit/640a2afda36857410b7abf398af81e35430a62e7
Stats:     1028 lines in 852 files changed: 252 ins; 9 del; 767 mod

8267184: Add -Djava.security.manager=allow to tests calling System.setSecurityManager

Co-authored-by: Lance Andersen 
Co-authored-by: Weijun Wang 
Reviewed-by: dholmes, alanb, dfuchs, mchung, mullan, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/4071


From will.sargent at gmail.com  Mon May 24 17:53:23 2021
From: will.sargent at gmail.com (Will Sargent)
Date: Mon, 24 May 2021 10:53:23 -0700
Subject: RFR: 8236671: NullPointerException in JKS keystore [v2]
In-Reply-To: 
References: 
 
 <3XV3VBENLppWqupCwu5BFLwQ6IK2wOjqY2LZMXzFlJM=.57139075-5af8-4ce8-a302-6ca0aeec2bcf@github.com>
 
 
Message-ID: 

I have tried to sign up to the bug tracking system (through reset password
I think?) but I'm not getting an email out, so I can't add to the bug.

I have created a test case in Github:

https://github.com/wsargent/jca-key-failure/

The stack trace shows the invalid key store entry after saving and loading
it again.

https://github.com/wsargent/jca-key-failure/blob/main/src/main/java/com/tersesystems/jcakeyfailure/JcaKeyFailure.java#L68

On Fri, Apr 30, 2021 at 12:40 PM Se?n Coffey  wrote:

> Thanks for the feedback Will. It would be useful if you can provide a
> testcase and/or add comments to JDK-8266351
>  on your experience.
>
> regards,
> Sean.
> On 30/04/2021 17:54, Will Sargent wrote:
>
> > KeyStore specification will be tightened up via another bug record
>
> This would be super helpful, as one thing that confuses me is what the
> relationship is between a key entry and a key alias -- in particular, the
> existence alias doesn't seem to guarantee a valid entry that can be
> retrieved.
>
> In JDK 11 it's possible to create a private key with a keystore using
> pkcs12.setKeyEntry() (see link below):
>
>
> https://github.com/tersesystems/securitybuilder/blob/master/lib/src/test/java/com/tersesystems/securitybuilder/PrivateKeyStoreTest.java#L135
>
> and then have a null pointer exception when retrieving the entry from the
> alias because the certificate chain is null (see commented out "testSystem"
> use case):
>
>
> https://github.com/tersesystems/securitybuilder/blob/master/lib/src/test/java/com/tersesystems/securitybuilder/PrivateKeyStoreTest.java#L27
>
> I can write this up into a formal bug if that helps.
>
> On Fri, Apr 30, 2021 at 2:30 AM Sean Coffey 
> wrote:
>
>> On Wed, 28 Apr 2021 12:39:42 GMT, Sean Coffey 
>> wrote:
>>
>> >> Trivial enough change. Improved the exception thrown from JceKeyStore
>> also.
>> >
>> > Sean Coffey has updated the pull request with a new target base due to
>> a merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains four additional
>> commits since the last revision:
>> >
>> >  - Check for null before try block
>> >  - Merge branch 'master' of https://github.com/openjdk/jdk into
>> JDK-8236671-NPE
>> >  - Fix white space
>> >  - 8236671: NullPointerException in JKS keystore
>>
>> KeyStore specification will be tightened up via another bug record:
>> https://bugs.openjdk.java.net/browse/JDK-8266351
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/3588
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From valeriep at openjdk.java.net  Mon May 24 18:22:48 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 24 May 2021 18:22:48 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 24 May 2021 16:34:51 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 203:
>> 
>>> 201:         // allocating and copying for direct bytebuffers
>>> 202:         if (!src.isDirect() && !dst.isDirect() &&
>>> 203:             !src.isReadOnly() && !dst.isReadOnly()) {
>> 
>> Why do we need to check for src being isReadOnly() since we are not writing bytes into src? As for dst, if it's read only, then we should probably not proceed further? The other update method which takes ByteBuffer dst did not check if it's read only. A bit inconsistent?
>
> src.array() throws an exception if it's read only

Other files seem to use src.hasArray() call which also checked for read only. Maybe that's what you meant to use?

>> src/java.base/share/classes/com/sun/crypto/provider/GCTR.java line 283:
>> 
>>> 281:         // allocating and copying for direct bytebuffers
>>> 282:         if (!src.isDirect() && !dst.isDirect() &&
>>> 283:             !src.isReadOnly() && !dst.isReadOnly()) {
>> 
>> Same question regarding the isReadOnly() calls as in the update(ByteBuffer, ByteBuffer) method.
>
> src.array() throws an exception if it's read only

Same, meant to use src.hasArray()?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Mon May 24 18:22:48 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 24 May 2021 18:22:48 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v3]
In-Reply-To: <4QSTdoOQ-HlefjMITN2YHemvfUvKjoM9sSLZqMDDqws=.667a5f1b-7dfa-4d24-9ea1-ce5e112a10ee@github.com>
References: 
 
 <9s-KZLwTGjYoMjfLnODpwuhwnz1zndpgX0daRl0bw8M=.0b345cd0-dd17-4b75-be45-f5b9482092b9@github.com>
 <4QSTdoOQ-HlefjMITN2YHemvfUvKjoM9sSLZqMDDqws=.667a5f1b-7dfa-4d24-9ea1-ce5e112a10ee@github.com>
Message-ID: <1R8d-hqZ_HHRflLE7t6nWHLK0tqXurwc-gyjWayLUP0=.117d0794-58e9-4eed-9082-25dfe7491a4d@github.com>

On Mon, 24 May 2021 16:54:39 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GHASH.java line 338:
>> 
>>> 336:     public int doFinal(ByteBuffer src, ByteBuffer dst) {
>>> 337:         return doFinal(src, src.remaining());
>>> 338:     }
>> 
>> Have you considered changing the argument list of existing update/doFinal(...) methods? Less calls.
>
> I had considered it, but there are a number of methods, particularly in the in decrypt operation, where the non-interface methods are called.  I didn't think it was right for all those calls to have "null" and "0" for output arguments they don't use.
> It's possible this interface may be not needed with a future Intel intrinsic, so we shall see.

Ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Mon May 24 18:22:49 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 24 May 2021 18:22:49 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v4]
In-Reply-To: 
References: 
 
 
 
Message-ID: <6dzGuidw2haHkEoXMXGuIjtUlD_iG6pNLcz8Y1siBJg=.61dee81c-4724-4a13-97d3-52a71671621d@github.com>

On Fri, 21 May 2021 04:07:05 GMT, Anthony Scarpino  wrote:

>> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 640:
>> 
>>> 638:          * @return number of bytes used from 'in'
>>> 639:          */
>>> 640:         int mergeBlock(byte[] buffer, int bufOfs, int bufLen, byte[] in,
>> 
>> Can be made 'static'?
>
> mergeBlock contains blockSize which isn't static

I see...

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From weijun at openjdk.java.net  Mon May 24 21:51:32 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 21:51:32 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs  wrote:

> Thanks for taking in my suggestions for FtpClient. I have also reviewed the changes to java.util.logging and JMX. I wish there was a way to handle doPrivileged returning void more nicely. Maybe component maintainers will be able to deal with them on a case-by-case basis later on.

Assigning to a useless "dummy" variable looks ugly. Extracting the call to a method might make it faraway from its caller. In L114 of `FtpClient.java` I managed to invent a return value and I thought it was perfect. But you said it's "a bit strange". :-(

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From ascarpino at openjdk.java.net  Mon May 24 21:53:50 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 24 May 2021 21:53:50 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Mon, 24 May 2021 18:15:17 GMT, Valerie Peng  wrote:

>> src.array() throws an exception if it's read only
>
> Other files seem to use src.hasArray() call which also checked for read only. Maybe that's what you meant to use?

Yes, I could use hasArray().  I hadn't started using that until later in development and never went back and changed lines like these

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Mon May 24 22:09:51 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 24 May 2021 22:09:51 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v5]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 21:18:34 GMT, Anthony Scarpino  wrote:

>> Hi,
>> 
>> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
>> 
>> Thanks
>> 
>> Tony
>
> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments update

Here are comments for the test changes.
Thanks,
Valerie

test/jdk/com/sun/crypto/provider/Cipher/AEAD/Encrypt.java line 236:

> 234:             HexFormat hex = HexFormat.of().withUpperCase();
> 235:             if (!Arrays.equals(output, outputTexts.get(k))) {
> 236:                 System.out.println("Combination #" + k + 1 + "\nresult    " +

nit: Why "+1"? The number should match the exception message, otherwise, very confusing.

test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMBufferTest.java line 673:

> 671: 
> 672:         // Test update-update-doFinal with byte arrays and preset data sizes
> 673:         t = new GCMBufferTest("AES/GCM/NoPadding",

This change seems un-necessary? Why separating the declaration to line 631?

test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java line 34:

> 32: /*
> 33:  * @test
> 34:  * @summary Call decrypt doFinal() with different output values to see if the

Missing bug id?

test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java line 56:

> 54:             throw e;
> 55:         }
> 56:         c.doFinal(cipherText, 1, len, pt, 0);

Should check the return value of doFinal() to match the expected output size?

test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java line 78:

> 76:             throw e;
> 77:         }
> 78:         c.doFinal(ByteBuffer.wrap(cipherText, 1, len), out);

Should check the return value of doFinal() to match the expected output size?

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java line 90:

> 88:             i++;
> 89:         }
> 90:         return b;

The generated data seems too similar, all starts with 0 and increment. Maybe use i = len to start with? Or take some additional argument for starting value?

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java line 98:

> 96: 
> 97:         byte[] iv = makeData(16);
> 98:         AlgorithmParameterSpec aps = new GCMParameterSpec(128, new byte[16]);

Use the already generated iv instead of new byte[16]?

test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java line 117:

> 115:             //int offset = ci.update(plainText, 0, plainText.length, cipherText, 0);
> 116:             //ci.doFinal(cipherText, offset);
> 117:             ci.doFinal(plainText, 0, plainText.length, cipherText, 0);

This change seems un-necessary? I think it's better to not change it so multi-part enc/dec are tested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From weijun at openjdk.java.net  Mon May 24 22:37:23 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 24 May 2021 22:37:23 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security
Message-ID: 

For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/4073

Commit messages:
 - 8267543: Post JEP 411 refactoring: security

Changes: https://git.openjdk.java.net/jdk/pull/4172/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267543
  Stats: 111 lines in 19 files changed: 34 ins; 35 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4172.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4172/head:pull/4172

PR: https://git.openjdk.java.net/jdk/pull/4172


From ascarpino at openjdk.java.net  Mon May 24 22:39:13 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 24 May 2021 22:39:13 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 May 2021 20:38:29 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments update
>
> test/jdk/com/sun/crypto/provider/Cipher/AEAD/GCMShortBuffer.java line 34:
> 
>> 32: /*
>> 33:  * @test
>> 34:  * @summary Call decrypt doFinal() with different output values to see if the
> 
> Missing bug id?

Here is my logic
It's not a regression test to verify a specific bug id, it's just a general functionality test.  Therefore the bug id does not point to a previous failure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Mon May 24 22:40:22 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 24 May 2021 22:40:22 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: 
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
 
Message-ID: 

On Fri, 21 May 2021 19:15:49 GMT, Xue-Lei Andrew Fan  wrote:

>> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge master into JDK-8248268
>>  - Minor update to address review comments.
>>  - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>>    KWParameters and KWPParameters.
>>  - Refactor code to reduce code duplication
>>    Address review comments
>>    Add more test vectors
>>  - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>    AES/KWP/NoPadding
>>  - Restored Iv algorithm parameters impl.
>>  - 8248268: Support KWP in addition to KW
>>    
>>    Updated existing AESWrap support with AES/KW/NoPadding cipher
>>    transformation. Added support for AES/KWP/NoPadding and
>>    AES/KW/PKCS5Padding support to SunJCE provider.
>
> src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 81:
> 
>> 79:                         expectedLen + " bytes long");
>> 80:         }
>> 81:         iv = tmpIv.clone();
> 
> The moreSizes is not used after initialization.  The iv/tmpIv could be a value other than the block_size.   The getEncoded() method would use the iv value for the encoding.  While in the decoding method init(byte[]) method, the IV sizes other block_size is not considered, and IOE will be thrown.  Could this be a problem?

Right, good catch, I will fix it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From ascarpino at openjdk.java.net  Mon May 24 23:00:14 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Mon, 24 May 2021 23:00:14 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v5]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Mon, 24 May 2021 20:09:06 GMT, Valerie Peng  wrote:

>> Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments update
>
> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java line 90:
> 
>> 88:             i++;
>> 89:         }
>> 90:         return b;
> 
> The generated data seems too similar, all starts with 0 and increment. Maybe use i = len to start with? Or take some additional argument for starting value?

I wanted consistent data because it's harder to solve crypto failures when you cannot see consistent pattern in the data.  For example, the GCM case where the ciphertext is correct, but the tag is wrong.  It is easier to know that the problem is in GHASH and not GCTR.
I don't see any negatives to having similar data.

> test/jdk/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java line 117:
> 
>> 115:             //int offset = ci.update(plainText, 0, plainText.length, cipherText, 0);
>> 116:             //ci.doFinal(cipherText, offset);
>> 117:             ci.doFinal(plainText, 0, plainText.length, cipherText, 0);
> 
> This change seems un-necessary? I think it's better to not change it so multi-part enc/dec are tested.

Because it's commented out, I'm not sure I intended to change that.  I think I was debugging something and never reverted the code

-------------

PR: https://git.openjdk.java.net/jdk/pull/4072


From valeriep at openjdk.java.net  Mon May 24 23:01:46 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Mon, 24 May 2021 23:01:46 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: 
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
 
Message-ID: 

On Fri, 21 May 2021 20:44:57 GMT, Xue-Lei Andrew Fan  wrote:

>> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge master into JDK-8248268
>>  - Minor update to address review comments.
>>  - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>>    KWParameters and KWPParameters.
>>  - Refactor code to reduce code duplication
>>    Address review comments
>>    Add more test vectors
>>  - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>    AES/KWP/NoPadding
>>  - Restored Iv algorithm parameters impl.
>>  - 8248268: Support KWP in addition to KW
>>    
>>    Updated existing AESWrap support with AES/KW/NoPadding cipher
>>    transformation. Added support for AES/KWP/NoPadding and
>>    AES/KW/PKCS5Padding support to SunJCE provider.
>
> src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
> 
>> 48: 
>> 49:     public AESParameters() {
>> 50:         core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);
> 
> A cipher object may not take different IV sizes at the same time.  I was just wondering how it could be used in practice.  Maybe something like:
> 
> 
> AlgorithmParameters algParams = AlgorithmParameters.getInstance("AES");
> algParams.init(ivParameterSpec);
> 
> The IV parameter is given with the init() method.  Then, it may be not necessary to construct the BlockCipherParamsCore object will all potential IV sizes.  See the comments in BlockCipherParamsCore.

Cipher objects normally takes just one iv size. BlockCipherParamsCore is used by various impls of AlgorithmParametersSpi class which may be used with different block cipher algorithms. The iv parameter is given with the AlgorithmParametersSpi.init() method and invalid iv will lead to exceptions. Since there are iv size checks built in BlockCipherParamsCore already, it seems safer to relax the check a bit for AES (4 and 8 for KWP and KW). The other choice is to just remove the size check from BlockCipherParamsCore for AES algorithm, but then we'd not be able to reject invalid iv lengths as before.

> src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 52:
> 
>> 50:     private byte[] iv = null;
>> 51: 
>> 52:     private int[] moreSizes = null;
> 
> The moreSizes is not used other than the init() method field.  It may be not easy to check the specific size if we cache all supported sized in the object.  For example, if the required IV size if 8 bytes, it may be a problem about how to make sure the iv size is 8 bytes exactly for a specific algorithm.
> 
> Maybe, we could just have a ivSize filed.  The default value is block_size, which coupe be set with the init(ivParameterSpec) method.
> 
> 
>     ....
>     private int ivSize;
>     ...
>    BlockCipherParamsCore(int blkSize) {
>        block_size = blkSize;
>        ivSize = blkSize;
>     }
>     ...
>    void init(AlgorithmParameterSpec paramSpec) {
>         ivSize = ...;  // reset IV size.
>     }
> 
>     // use ivSize while encoding and decoding.

The problem with this is that this assumes that the specified paramSpec argument of the init() method is always valid.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From valeriep at openjdk.java.net  Tue May 25 00:15:11 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 25 May 2021 00:15:11 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: 
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
 
Message-ID: <0GGhLsZoadiB3ygXDTWzNoIDwbQt0tsKZ5hoLli3CtM=.a3ab8f26-6ab1-4e79-b804-c89c54541edf@github.com>

On Sat, 22 May 2021 00:45:27 GMT, Xue-Lei Andrew Fan  wrote:

>> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge master into JDK-8248268
>>  - Minor update to address review comments.
>>  - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>>    KWParameters and KWPParameters.
>>  - Refactor code to reduce code duplication
>>    Address review comments
>>    Add more test vectors
>>  - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>    AES/KWP/NoPadding
>>  - Restored Iv algorithm parameters impl.
>>  - 8248268: Support KWP in addition to KW
>>    
>>    Updated existing AESWrap support with AES/KW/NoPadding cipher
>>    transformation. Added support for AES/KWP/NoPadding and
>>    AES/KW/PKCS5Padding support to SunJCE provider.
>
> src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java line 190:
> 
>> 188:                 return constructKey(encoding, keyAlgorithm, keyType);
>> 189:             } else {
>> 190:                 byte[] encoding2 = Arrays.copyOfRange(encoding, ofs, ofs + len);
> 
> The array will be copied again in the X509EncodedKeySpec and PKCS8EncodedKeySpec.  It is out of this scope, but it may be a performance improvement if adding X509EncodedKeySpec and PKCS8EncodedKeySpec constructors that accept array offset, so that the array copy here could be avoid.

Right, maybe there is no constructor which takes offset and length due to trying to avoid the cost of validating them. I recall seeing other *Spec classes whose list of constructors are similar to X509EncodedKeySpec/PKCS8EncodedKeySpec as well.

> src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java line 192:
> 
>> 190:                 byte[] encoding2 = Arrays.copyOfRange(encoding, ofs, ofs + len);
>> 191:                 try {
>> 192:                     return constructKey(encoding2, keyAlgorithm, keyType);
> 
> The two constructKey methods are depended on each other.  It may improve the readability if only having one-way dependence, by moving the switch-block logic from the former constructKey() to the later one.
> 
> 
>  static final Key constructKey(byte[] encoding, String keyAlgorithm,
>        int keyType) throws InvalidKeyException, NoSuchAlgorithmException {
>     return constructKey(encoding, 0. encoding.length, keyAlgorithm, keyType);
> }
> 
> 
> With this re-org, the array copy could be avoid if the key type is unknown.

Yes, I will refactor the two constructKey() methods as you suggested.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From mstjohns at comcast.net  Tue May 25 00:58:38 2021
From: mstjohns at comcast.net (Michael StJohns)
Date: Mon, 24 May 2021 20:58:38 -0400
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: 
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
 
 
Message-ID: 

Some more general comments - related to the restructuring.

In AESKeyWrap at 152-155 - that check probably should be moved to W().?? 
KWP should do the formatting prior to passing the data to W().? Also at 
185-187 - move that to W_INV().

AESKeyWrap at 158 - shouldn't you be returning the cipher text length?? 
That's what the comment in FeedbackCipher says.? W() should probably be 
returning the final length.

The length of the final ciphertext data should be 8 bytes longer than 
the plaintext. decryptFinal() seems to do the right thing by decreasing 
the length returned.?? But again - shouldn't that be the purview of W_INV()?

The call in KeyWrapCipher.engineGetOutputSize() should probably also be 
passed into KWUtil rather than being? done in KeyWrapCipher.? And the 
more I look at this, the more I think that all of the engineUpdate 
operations should throw UnsupportedOperationException - it would 
certainly simplify the logic.? That would make the call return either? 
inputLength + 8 or inputLength - 8 depending on mode.

KWUtil.W() - should probably check that in.length >= inLen + 8 and throw 
a ShortBufferException if not.

Would it be useful to add a comment in KeyWrapCipher that? warns 
maintainers that? AESKeyWrap(Padded).encryptFinal() and decryptFinal() 
uses the input buffer as the output buffer? That's a reasonable approach 
for decryption, but I'm wondering if you might want to support in-place 
encryption as there's no spec prohibition requiring data to be held 
until the encryption is complete.

Mike









On 5/24/2021 7:01 PM, Valerie Peng wrote:
> On Fri, 21 May 2021 20:44:57 GMT, Xue-Lei Andrew Fan  wrote:
>
>>> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>>>
>>>   - Merge master into JDK-8248268
>>>   - Minor update to address review comments.
>>>   - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>>>     KWParameters and KWPParameters.
>>>   - Refactor code to reduce code duplication
>>>     Address review comments
>>>     Add more test vectors
>>>   - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>>     AES/KWP/NoPadding
>>>   - Restored Iv algorithm parameters impl.
>>>   - 8248268: Support KWP in addition to KW
>>>     
>>>     Updated existing AESWrap support with AES/KW/NoPadding cipher
>>>     transformation. Added support for AES/KWP/NoPadding and
>>>     AES/KW/PKCS5Padding support to SunJCE provider.
>> src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50:
>>
>>> 48:
>>> 49:     public AESParameters() {
>>> 50:         core = new BlockCipherParamsCore(AESConstants.AES_BLOCK_SIZE, 4, 8);
>> A cipher object may not take different IV sizes at the same time.  I was just wondering how it could be used in practice.  Maybe something like:
>>
>>
>> AlgorithmParameters algParams = AlgorithmParameters.getInstance("AES");
>> algParams.init(ivParameterSpec);
>>
>> The IV parameter is given with the init() method.  Then, it may be not necessary to construct the BlockCipherParamsCore object will all potential IV sizes.  See the comments in BlockCipherParamsCore.
> Cipher objects normally takes just one iv size. BlockCipherParamsCore is used by various impls of AlgorithmParametersSpi class which may be used with different block cipher algorithms. The iv parameter is given with the AlgorithmParametersSpi.init() method and invalid iv will lead to exceptions. Since there are iv size checks built in BlockCipherParamsCore already, it seems safer to relax the check a bit for AES (4 and 8 for KWP and KW). The other choice is to just remove the size check from BlockCipherParamsCore for AES algorithm, but then we'd not be able to reject invalid iv lengths as before.
>
>> src/java.base/share/classes/com/sun/crypto/provider/BlockCipherParamsCore.java line 52:
>>
>>> 50:     private byte[] iv = null;
>>> 51:
>>> 52:     private int[] moreSizes = null;
>> The moreSizes is not used other than the init() method field.  It may be not easy to check the specific size if we cache all supported sized in the object.  For example, if the required IV size if 8 bytes, it may be a problem about how to make sure the iv size is 8 bytes exactly for a specific algorithm.
>>
>> Maybe, we could just have a ivSize filed.  The default value is block_size, which coupe be set with the init(ivParameterSpec) method.
>>
>>
>>      ....
>>      private int ivSize;
>>      ...
>>     BlockCipherParamsCore(int blkSize) {
>>         block_size = blkSize;
>>         ivSize = blkSize;
>>      }
>>      ...
>>     void init(AlgorithmParameterSpec paramSpec) {
>>          ivSize = ...;  // reset IV size.
>>      }
>>
>>      // use ivSize while encoding and decoding.
> The problem with this is that this assumes that the specified paramSpec argument of the init() method is always valid.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2404




From valeriep at openjdk.java.net  Tue May 25 03:13:16 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 25 May 2021 03:13:16 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: 
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
 
Message-ID: 

On Sat, 22 May 2021 01:02:50 GMT, Xue-Lei Andrew Fan  wrote:

>> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge master into JDK-8248268
>>  - Minor update to address review comments.
>>  - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>>    KWParameters and KWPParameters.
>>  - Refactor code to reduce code duplication
>>    Address review comments
>>    Add more test vectors
>>  - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>>    AES/KWP/NoPadding
>>  - Restored Iv algorithm parameters impl.
>>  - 8248268: Support KWP in addition to KW
>>    
>>    Updated existing AESWrap support with AES/KW/NoPadding cipher
>>    transformation. Added support for AES/KWP/NoPadding and
>>    AES/KW/PKCS5Padding support to SunJCE provider.
>
> src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java line 176:
> 
>> 174:             return ConstructKeys.constructPublicKey(encoding, keyAlgorithm);
>> 175:         default:
>> 176:             throw new RuntimeException("Unsupported key type");
> 
> Good improvement to thrown an exception rather than return "null"!
> 
> Is NoSuchAlgorithmException fitted better the specification?  See also the comment in  KeyWrapCipher.engineUnwrap().

Yes, will change.

> src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java line 710:
> 
>> 708:             outLen = helperDecrypt(dataBuf, dataIdx);
>> 709:             return ConstructKeys.constructKey(dataBuf, 0, outLen,
>> 710:                     wrappedKeyAlgorithm, wrappedKeyType);
> 
> Per the specification of engineUnwrap,  maybe, the ConstructKeys.constructKey() implementation could throw NoSuchAlgorithmException if wrappedKeyType is unknown.  See the common in the the ConstructKeys.constructKey() implementation.

Sure, makes sense.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From tvaleev at openjdk.java.net  Tue May 25 03:52:06 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 03:52:06 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com>

On Mon, 24 May 2021 13:44:36 GMT, Daniel Fuchs  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> src/java.base/share/classes/java/util/regex/CharPredicates.java line 217:
> 
>> 215:             case "WORD" -> WORD();
>> 216:             default -> null;
>> 217:         };
> 
> This file has lots of changes which are difficult to review. Maybe it should be split out of this PR.

*sigh* GitHub diff tool is really poor and outdated. Here's how it looks in IntelliJ IDEA diff view:
![image](https://user-images.githubusercontent.com/5114450/119436474-6b455b80-bd46-11eb-8865-8b7f30826a8d.png)

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Tue May 25 03:56:07 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 03:56:07 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: 

On Mon, 24 May 2021 13:46:58 GMT, Daniel Fuchs  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 261:
> 
>> 259:             ZipEntry e = current.entry;
>> 260:             switch (e.method) {
>> 261:                 case DEFLATED -> {
> 
> Same remark here - it's not clear what's going on.

Here, it's mostly indentation change (+4 spaces). You can set "Hide whitespace changes" and see:
![image](https://user-images.githubusercontent.com/5114450/119436860-3259b680-bd47-11eb-92d8-f940493d08c2.png)
Alternatively, I can indent back this switch, placing `case` on the same indentation level as `switch`. I'm not sure about recommended code style in OpenJDK project, it looks like it's not very consistent.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Tue May 25 04:13:36 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 04:13:36 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v2]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Unindent switch cases to simplify the review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4161/files
  - new: https://git.openjdk.java.net/jdk/pull/4161/files/807d780d..2e966d0f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=00-01

  Stats: 64 lines in 1 file changed: 27 ins; 27 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161


From jpai at openjdk.java.net  Tue May 25 04:46:56 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 25 May 2021 04:46:56 GMT
Subject: RFR: 8255674: SSLEngine class description is missing "case" in switch
 statement
Message-ID: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>

Can I please get a review for this trivial fix in the code sample in javadoc comment of `javax.net.ssl.SSLEngine` class?

I've run `make docs-image` locally and the generated javadoc after this change looks fine.

-------------

Commit messages:
 - 8255674 SSLEngine class description is missing "case" in switch statement

Changes: https://git.openjdk.java.net/jdk/pull/4180/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4180&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255674
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4180.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4180/head:pull/4180

PR: https://git.openjdk.java.net/jdk/pull/4180


From xuelei at openjdk.java.net  Tue May 25 04:59:12 2021
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Tue, 25 May 2021 04:59:12 GMT
Subject: RFR: 8255674: SSLEngine class description is missing "case" in
 switch statement
In-Reply-To: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
References: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
Message-ID: <3oufWYMQuqhlFivO8BxbkU9uDFpCxIQYl6XIkhkXvU0=.dc673a0f-2553-4905-94aa-caebd640b041@github.com>

On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this trivial fix in the code sample in javadoc comment of `javax.net.ssl.SSLEngine` class?
> 
> I've run `make docs-image` locally and the generated javadoc after this change looks fine.

Marked as reviewed by xuelei (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4180


From fridrich.strba at suse.com  Tue May 25 05:12:26 2021
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Tue, 25 May 2021 07:12:26 +0200
Subject: TLS v1.3 extensions in TLS v1.2 handshake
Message-ID: 

Hello, good people,

The java 11 implementation of TLS v1.3 was backported into java 8 since 
some CPUs and it results sometimes in new handshake failures with 
hard-to-updage-firmware devices whose shell life might be still long.

We somehow debugged those failures and some devices bomb because of 
TLSv1.2 handshake containing the signature_algorihms_cert and 
supported_versions extensions.

I would love to propose for Java 8 the attached patch that would make 
the TLSv1.2 handshake to look exactly as it was looking in 8u252. The 
TLSv1.3 handshake still contains both extensions as it should. This 
could solve the differences of Java 8 behaviour between different update 
numbers.

Please, have a look and comment

Cheers

Fridrich

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tls13extensions.patch
Type: text/x-patch
Size: 1153 bytes
Desc: not available
URL: 

From tvaleev at openjdk.java.net  Tue May 25 06:01:49 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 06:01:49 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v3]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com>

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Indent some lines to make GitHub diff happier

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4161/files
  - new: https://git.openjdk.java.net/jdk/pull/4161/files/2e966d0f..07a998bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=01-02

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Tue May 25 06:06:05 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 06:06:05 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v3]
In-Reply-To: <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
 <4cPrOLZV8ybO_73OiaHFo3Yt8TwSRoJYvFMzeOBMQMo=.0c03c713-d4f8-4631-b485-e5f4d0441374@github.com>
Message-ID: 

On Tue, 25 May 2021 03:48:41 GMT, Tagir F. Valeev  wrote:

>> src/java.base/share/classes/java/util/regex/CharPredicates.java line 217:
>> 
>>> 215:             case "WORD" -> WORD();
>>> 216:             default -> null;
>>> 217:         };
>> 
>> This file has lots of changes which are difficult to review. Maybe it should be split out of this PR.
>
> *sigh* GitHub diff tool is really poor and outdated. Here's how it looks in IntelliJ IDEA diff view:
> ![image](https://user-images.githubusercontent.com/5114450/119436474-6b455b80-bd46-11eb-8865-8b7f30826a8d.png)

I played with indentations and found a way to make GitHub diff happier. Now, lines like `? UPPERCASE().union(LOWERCASE(), TITLECASE())` are probably a little bit too far to the right but it's still acceptable and diff looks much easier to review now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From jpai at openjdk.java.net  Tue May 25 07:44:09 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 25 May 2021 07:44:09 GMT
Subject: Integrated: 8255674: SSLEngine class description is missing "case" in
 switch statement
In-Reply-To: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
References: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
Message-ID: 

On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this trivial fix in the code sample in javadoc comment of `javax.net.ssl.SSLEngine` class?
> 
> I've run `make docs-image` locally and the generated javadoc after this change looks fine.

This pull request has now been integrated.

Changeset: 0a03fc84
Author:    Jaikiran Pai 
URL:       https://git.openjdk.java.net/jdk/commit/0a03fc84b3289cf8c8effca7324f71146270a8e2
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8255674: SSLEngine class description is missing "case" in switch statement

Reviewed-by: xuelei

-------------

PR: https://git.openjdk.java.net/jdk/pull/4180


From jpai at openjdk.java.net  Tue May 25 07:44:08 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 25 May 2021 07:44:08 GMT
Subject: RFR: 8255674: SSLEngine class description is missing "case" in
 switch statement
In-Reply-To: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
References: <7JScc3NvV-DCWKv16y4h66d0QyvN1UWGcb72f5b5CPg=.04846678-ce77-4b72-8923-dcb7bd1d1a9d@github.com>
Message-ID: 

On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai  wrote:

> Can I please get a review for this trivial fix in the code sample in javadoc comment of `javax.net.ssl.SSLEngine` class?
> 
> I've run `make docs-image` locally and the generated javadoc after this change looks fine.

Thank you Xuelei for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4180


From pconcannon at openjdk.java.net  Tue May 25 08:28:10 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 25 May 2021 08:28:10 GMT
Subject: Integrated: 8267110: Update java.util to use instanceof pattern
 variable
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 10:37:21 GMT, Patrick Concannon  wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.util` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: a52c4ede
Author:    Patrick Concannon 
URL:       https://git.openjdk.java.net/jdk/commit/a52c4ede2f043b7d4a234c7d06f91871312e9654
Stats:     267 lines in 29 files changed: 1 ins; 125 del; 141 mod

8267110: Update java.util to use instanceof pattern variable

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/4088


From sgehwolf at redhat.com  Tue May 25 10:18:15 2021
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 25 May 2021 12:18:15 +0200
Subject: TLS v1.3 extensions in TLS v1.2 handshake
In-Reply-To: 
References: 
Message-ID: 

CC'ing jdk8u-dev list.

Fridrich, is this an 8u-only problem you are observing? Would you have
some details about the problem so that I can file a bug for you?

Thanks,
Severin

On Tue, 2021-05-25 at 07:12 +0200, Fridrich Strba wrote:
> Hello, good people,
> 
> The java 11 implementation of TLS v1.3 was backported into java 8
> since some CPUs and it results sometimes in new handshake failures
> with hard-to-updage-firmware devices whose shell life might be still
> long.
> 
> We somehow debugged those failures and some devices bomb because of 
> TLSv1.2 handshake containing the signature_algorihms_cert and 
> supported_versions extensions.
> 
> TLSv1.3 handshake still contains both extensions as it should. This 
> could solve the differences of Java 8 behaviour between different
> update 
> numbers.
> 
> Please, have a look and comment
> 
> Cheers
> 
> Fridrich
> 




From pconcannon at openjdk.java.net  Tue May 25 10:36:00 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 25 May 2021 10:36:00 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v3]
In-Reply-To: <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com>
Message-ID: 

On Tue, 25 May 2021 06:01:49 GMT, Tagir F. Valeev  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Indent some lines to make GitHub diff happier

src/java.base/share/classes/java/util/GregorianCalendar.java line 1730:

> 1728:         int value = -1;
> 1729:         switch (field) {
> 1730:             case MONTH -> {

HI @amaembo, thanks for taking a look at this.

I think you should be careful here, and ask is introducing the enchanced switch adding any value? While I think the enchanced switch can be valuable when it makes the code more readable, it shouldn't be introduced just for the sake of using it.

src/java.base/share/classes/java/util/PropertyPermission.java line 337:

> 335:      */
> 336:     static String getActions(int mask) {
> 337:         return switch (mask & (READ | WRITE)) {

Just a suggestion, but it might be more readable if you align the lambda operators

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From fridrich.strba at suse.com  Tue May 25 10:52:01 2021
From: fridrich.strba at suse.com (Fridrich Strba)
Date: Tue, 25 May 2021 12:52:01 +0200
Subject: TLS v1.3 extensions in TLS v1.2 handshake
In-Reply-To: 
References: 
 
Message-ID: <56a7fb65-4985-a278-948a-c0167b4aab86@suse.com>

Hello, good people,

On 25/05/2021 12:18, Severin Gehwolf wrote:
> Fridrich, is this an 8u-only problem you are observing? Would you have
> some details about the problem so that I can file a bug for you?

The problem is not 8u-only strictly speaking, but in jdk11u, where it is 
surely also present, it is not a regression, because the handshake was 
working the same way at the 11.0.0 release time. In jdk8, we had the tls 
1.2 implementation until a year or half ago, and then we backported the 
jdk11 implementation to support tls1.3. Since then, a tls1.2 handshake 
emits the two new extensions and some servers out there have problem 
with those extensions for some reasons.

Users that communicate to those kind of devices gave up communicating 
using Java 11, and settled on the other LTS version that is active and 
was working until u252 at least.

One of problems one of our customer hit was when a particular version of 
erlang is doing the server side on a third party device. The problem is 
exactly the one that is outlined here https://bugs.erlang.org/browse/ERL-973

I agree that it is erlang's bug since they bomb on legacy ciphers 
instead of ignoring them in the signature_algorithms_cert extension. 
Nonetheless, this is not a system that is easy to deliver upgrade to and 
previously, jdk8's tls1.2 handshake was working for them. With the 
upgrade, it is not working any more. Even if they specify 
'-Djdk.tls.client.protocols=TLSv1.2' on command-line

So I looked into a solution on Java side. And the solution for me was to 
make the jdk8u292 handshake -- when we are not specifying the tlsv1.3 
support -- not emit those two tlsv1.3 extensions. That is basically 
solving the issue. Moreover, the tlsv1.3 handshake looks good too, 
because it is enough to specify the 
'-Djdk.tls.client.protocols=...,TLSv1.3' and the extensions are emitted.

Now, I looked into including a command-line option to make this 
behaviour configurable, but then the code to implement that would be 
much more intrusive then the two-line patch that I sent to the 
security-dev list.

We did not find the supported_versions extension to have any adverse 
effect whenever we were investigating the bugs, but I somehow tried to 
make the handshake to look like the old handshake was looking before.

I hope I was clear enough about the problem. Now, I need two kind of 
information:

1) Does this look like something that could be applied in jdk8u?

2) If not, is this patch harmful if a downstream builds? I don't think 
so as I read the code, but then I cannot claim universal knowledge either.

Cheers

Fridrich



From tvaleev at openjdk.java.net  Tue May 25 11:39:02 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 11:39:02 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v4]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  Vertical alignment for single-line switch rules

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4161/files
  - new: https://git.openjdk.java.net/jdk/pull/4161/files/07a998bc..82f40605

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=02-03

  Stats: 54 lines in 10 files changed: 2 ins; 0 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Tue May 25 11:39:45 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 11:39:45 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v3]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 <78LopXMnM-8NJkcJRbMIcJFSzAEpOvyOXuhA_4vr9gg=.3a1ed69b-99e0-4a0a-912f-57a861decd2d@github.com>
 
Message-ID: 

On Tue, 25 May 2021 10:31:33 GMT, Patrick Concannon  wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Indent some lines to make GitHub diff happier
>
> src/java.base/share/classes/java/util/GregorianCalendar.java line 1730:
> 
>> 1728:         int value = -1;
>> 1729:         switch (field) {
>> 1730:             case MONTH -> {
> 
> HI @amaembo, thanks for taking a look at this.
> 
> I think you should be careful here, and ask is introducing the enchanced switch adding any value? While I think the enchanced switch can be valuable when it makes the code more readable, it shouldn't be introduced just for the sake of using it.

@pconcannon thank you for review!

In this particular place, it makes the code more better in the following points:
- It removes `break;` operators at the end of each branch, which add nothing but a visual noise
- It makes the whole switch shorter by 22 lines
- Using `->` syntax clearly states that no branch in this switch has a fall-through behavior, so the code reader should not check every branch to ensure this. Just see very first `->` and you already know that no fallthrough is here.
- In case if new branches will appear in the future, the new-style switch will protect future maintainers from accidental fall-through, an error that often happens with old-style switches.

> src/java.base/share/classes/java/util/PropertyPermission.java line 337:
> 
>> 335:      */
>> 336:     static String getActions(int mask) {
>> 337:         return switch (mask & (READ | WRITE)) {
> 
> Just a suggestion, but it might be more readable if you align the lambda operators

Thank you for pointing to this. Actually, I just noticed that there was some kind of vertical alignment before my change. I added vertical alignment for single-line switch rules.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Tue May 25 11:49:18 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Tue, 25 May 2021 11:49:18 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v5]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:

  More vertical alignment

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4161/files
  - new: https://git.openjdk.java.net/jdk/pull/4161/files/82f40605..f4ad5f14

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161


From mullan at openjdk.java.net  Tue May 25 13:51:01 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 May 2021 13:51:01 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 May 2021 20:23:27 GMT, Weijun Wang  wrote:

> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 709:

> 707:                         }
> 708:                         if (GSSUtil.useSubjectCredsOnly(caller)) {
> 709:                             @SuppressWarnings("removal")

It looks like you missed removing the @SuppressWarnings("removal") from the initSecContext method above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172


From ascarpino at openjdk.java.net  Tue May 25 15:33:37 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Tue, 25 May 2021 15:33:37 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v6]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
> 
> Thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  Review comments update

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4072/files
  - new: https://git.openjdk.java.net/jdk/pull/4072/files/76a984a0..ccb7b357

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=04-05

  Stats: 109 lines in 6 files changed: 45 ins; 34 del; 30 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072

PR: https://git.openjdk.java.net/jdk/pull/4072


From chegar at openjdk.java.net  Tue May 25 15:54:57 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 25 May 2021 15:54:57 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v5]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: 

On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More vertical alignment

src/java.base/share/classes/java/util/Calendar.java line 1507:

> 1505:                 }
> 1506:                 case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true);
> 1507:                 default -> throw new IllegalArgumentException("unknown calendar type: " + type);

In this case, it would be good to yield the result of the switch expression and assign that to a local, rather than assigning in each of the case arms, e.g:

    final Calendar cal = switch (type) {
        case "gregory" -> new GregorianCalendar(zone, locale, true);
        case "iso8601" -> {
            GregorianCalendar gcal = new GregorianCalendar(zone, locale, true);
            // make gcal a proleptic Gregorian
            gcal.setGregorianChange(new Date(Long.MIN_VALUE));
            // and week definition to be compatible with ISO 8601
            setWeekDefinition(MONDAY, 4);
            yield gcal;
        }
        case "buddhist" -> {
            var buddhistCalendar = new BuddhistCalendar(zone, locale);
            buddhistCalendar.clear();
            yield buddhistCalendar;
        }
        case "japanese" -> new JapaneseImperialCalendar(zone, locale, true);
        default -> throw new IllegalArgumentException("unknown calendar type: " + type);
    };

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From weijun at openjdk.java.net  Tue May 25 16:20:35 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 25 May 2021 16:20:35 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: 
References: 
Message-ID: 

> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.
> 
> I'll add a copyright year update commit before integration.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  one more change

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4172/files
  - new: https://git.openjdk.java.net/jdk/pull/4172/files/b22fd7d7..176f44e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4172&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4172.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4172/head:pull/4172

PR: https://git.openjdk.java.net/jdk/pull/4172


From weijun at openjdk.java.net  Tue May 25 16:20:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 25 May 2021 16:20:38 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 May 2021 13:44:30 GMT, Sean Mullan  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   one more change
>
> src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 709:
> 
>> 707:                         }
>> 708:                         if (GSSUtil.useSubjectCredsOnly(caller)) {
>> 709:                             @SuppressWarnings("removal")
> 
> It looks like you missed removing the @SuppressWarnings("removal") from the initSecContext method above.

Oops. Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172


From briangoetz at openjdk.java.net  Tue May 25 16:49:59 2021
From: briangoetz at openjdk.java.net (Brian Goetz)
Date: Tue, 25 May 2021 16:49:59 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v5]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: 

On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More vertical alignment

src/java.base/share/classes/java/util/Calendar.java line 1507:

> 1505:                 }
> 1506:                 case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true);
> 1507:                 default -> throw new IllegalArgumentException("unknown calendar type: " + type);

Agree with Chris' suggestion here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From briangoetz at openjdk.java.net  Tue May 25 16:55:06 2021
From: briangoetz at openjdk.java.net (Brian Goetz)
Date: Tue, 25 May 2021 16:55:06 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v5]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: 

On Tue, 25 May 2021 11:49:18 GMT, Tagir F. Valeev  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More vertical alignment

src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1124:

> 1122:                 return Math.max(LEAST_MAX_VALUES[YEAR], d.getYear());
> 1123:             }
> 1124:         }

A switch with one element here is kind of weird.  I would turn this into "return switch (field) { ... }", with two cases, YEAR and default.

src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1371:

> 1369:                     }
> 1370:                 }
> 1371:             }

Pull value assignment out of switch?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From wetmore at openjdk.java.net  Tue May 25 19:41:37 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 25 May 2021 19:41:37 GMT
Subject: Integrated: 8267683: rfc7301Grease8F value not displayed correctly in
 SSLParameters javadoc
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 May 2021 18:03:51 GMT, Bradford Wetmore  wrote:

> Simple typo fix.  Somehow the trailing "u" got omitted, so the code won't parse when fed into the compiler.
> 
> Resulting javadoc output now compiles.

This pull request has now been integrated.

Changeset: e751b7b1
Author:    Bradford Wetmore 
URL:       https://git.openjdk.java.net/jdk/commit/e751b7b1b6f7269a1fe20c07748c726536388f6d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8267683: rfc7301Grease8F value not displayed correctly in SSLParameters javadoc

Reviewed-by: coffeys

-------------

PR: https://git.openjdk.java.net/jdk/pull/4193


From valeriep at openjdk.java.net  Tue May 25 19:57:42 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 25 May 2021 19:57:42 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v7]
In-Reply-To: <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
References: 
 <8OZKligWLnZVkQpszjvOwMB-HdOp6Oy0DzssxmrcIz0=.5b176aa1-d4e4-47cb-bd9b-58cdc5f706ff@github.com>
Message-ID: 

On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng  wrote:

>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>> 
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
>> 
>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge master into JDK-8248268
>  - Minor update to address review comments.
>  - Changed AESParameters to allow 4-byte, 8-byte IVs and removed
>    KWParameters and KWPParameters.
>  - Refactor code to reduce code duplication
>    Address review comments
>    Add more test vectors
>  - Changed AlgorithmParameters impls to register under AES/KW/NoPadding and
>    AES/KWP/NoPadding
>  - Restored Iv algorithm parameters impl.
>  - 8248268: Support KWP in addition to KW
>    
>    Updated existing AESWrap support with AES/KW/NoPadding cipher
>    transformation. Added support for AES/KWP/NoPadding and
>    AES/KW/PKCS5Padding support to SunJCE provider.

Current impl takes account into RFC 3394 (Sept 2002), RFC 5649 (Aug 2009), NIST 800-38F (Dec 2012) and PKCS#11 v3.0 Current Mech Spec (June 2020) and tries to support them all. If solely basing on RFC 3394/5649, then AES KW and KWP cipher should just supports key wrap/unwrap but not enc/dec. The main reason that I added the support for alternative iv and enc/dec is more for NIST 800-38F which states that KW/KWP can be used for general data protection as well and PKCS#11 v3.0 which lists 3 mechanisms mapping to java's AES using KW, AES using KW and PKCS5Padding and AES using KWP. These 3 mechanisms supports all 4, i.e. enc/dec/wrap/unwrap, as well custom IVs (8-byte for KW and 4-byte for KWP). Naming can be a very subjective matter and putting it aside, I don't see why KW and KWP should not allow custom IVs? Isn't hardcoded values less secure or fragile in general?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From valeriep at openjdk.java.net  Tue May 25 20:33:55 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Tue, 25 May 2021 20:33:55 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v8]
In-Reply-To: 
References: 
Message-ID: 

> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
> 
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
> 
> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Address review feedbacks

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2404/files
  - new: https://git.openjdk.java.net/jdk/pull/2404/files/e9c1ae18..77566a82

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=06-07

  Stats: 57 lines in 3 files changed: 21 ins; 18 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404

PR: https://git.openjdk.java.net/jdk/pull/2404


From mullan at openjdk.java.net  Tue May 25 21:28:35 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 May 2021 21:28:35 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: 
References: 
 
Message-ID: <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com>

On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang  wrote:

>> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more change

Update copyright dates to 2021, if applicable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172


From weijun at openjdk.java.net  Tue May 25 21:38:38 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 25 May 2021 21:38:38 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com>
References: 
 
 <6MXMOwoTFMlNVcPM_87-RhJ-J99JKyzY4PRFjx4SM1M=.fbc66aa4-e548-44e8-97c0-024a846af89d@github.com>
Message-ID: 

On Tue, 25 May 2021 21:25:54 GMT, Sean Mullan  wrote:

> Update copyright dates to 2021, if applicable.

Will do. Since this PR can only be integrated after its parent PR #4073 is integrated. I'll delay the copyright update by then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172


From mullan at openjdk.java.net  Tue May 25 21:53:04 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 25 May 2021 21:53:04 GMT
Subject: RFR: 8267543: Post JEP 411 refactoring: security [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 May 2021 16:20:35 GMT, Weijun Wang  wrote:

>> For all modified files in #4073 having "security", "crypto", or "ssl" in their names. Codes are refactored to bring a `@SuppressWarning` annotation nearer to the deprecated API usage and also shrink the size of its target.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   one more change

Marked as reviewed by mullan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4172


From wetmore at openjdk.java.net  Tue May 25 21:53:39 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 25 May 2021 21:53:39 GMT
Subject: RFR: 8267683: rfc7301Grease8F value not displayed correctly in
 SSLParameters javadoc
Message-ID: 

Simple typo fix.  Somehow the trailing "u" got omitted, so the code won't parse when fed into the compiler.

Resulting javadoc output now compiles.

-------------

Commit messages:
 - Codereview Comments.
 - 8267683: rfc7301Grease8F value not displayed correctly in SSLParameters javadoc

Changes: https://git.openjdk.java.net/jdk/pull/4193/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4193&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267683
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4193/head:pull/4193

PR: https://git.openjdk.java.net/jdk/pull/4193


From coffeys at openjdk.java.net  Tue May 25 21:53:42 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Tue, 25 May 2021 21:53:42 GMT
Subject: RFR: 8267683: rfc7301Grease8F value not displayed correctly in
 SSLParameters javadoc
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 May 2021 18:03:51 GMT, Bradford Wetmore  wrote:

> Simple typo fix.  Somehow the trailing "u" got omitted, so the code won't parse when fed into the compiler.
> 
> Resulting javadoc output now compiles.

Looks good!

-------------

Marked as reviewed by coffeys (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4193


From smarks at openjdk.java.net  Tue May 25 22:26:43 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 25 May 2021 22:26:43 GMT
Subject: RFR: 8267123: Remove RMI Activation
Message-ID: 

This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).

This is a fairly straightforward removal of this component.
 - Activation implementation classes removed
 - Activation tests removed
 - adjustments to various comments to remove references to Activation
 - adjustments to some code to remove special-case support for Activation from core RMI
 - adjustments to several tests to remove testing and support for, and mentions of Activation
 - remove `rmid` tool

(Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.)

-------------

Commit messages:
 - Merge branch 'master' into JDK-8267123-Remove-RMI-Activation
 - Merge branch 'master' into remove-rmi-activation
 - Clean up some old comments.
 - Small fixups.
 - First cut at removal of RMI Activation.

Changes: https://git.openjdk.java.net/jdk/pull/4194/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4194&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267123
  Stats: 21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4194.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4194/head:pull/4194

PR: https://git.openjdk.java.net/jdk/pull/4194


From erikj at openjdk.java.net  Tue May 25 22:41:16 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 25 May 2021 22:41:16 GMT
Subject: RFR: 8267123: Remove RMI Activation
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks  wrote:

> This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
> 
> This is a fairly straightforward removal of this component.
>  - Activation implementation classes removed
>  - Activation tests removed
>  - adjustments to various comments to remove references to Activation
>  - adjustments to some code to remove special-case support for Activation from core RMI
>  - adjustments to several tests to remove testing and support for, and mentions of Activation
>  - remove `rmid` tool
> 
> (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.)

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4194


From wetmore at openjdk.java.net  Wed May 26 01:19:23 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 26 May 2021 01:19:23 GMT
Subject: RFR: 8267750: Incomplete fix for JDK-8267683
Message-ID: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>

Missed updating today's changeset with the new variable name.

It's a "one character fix."

-------------

Commit messages:
 - 8267750: Incomplete fix for JDK-8267683

Changes: https://git.openjdk.java.net/jdk/pull/4196/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4196&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267750
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4196.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4196/head:pull/4196

PR: https://git.openjdk.java.net/jdk/pull/4196


From tvaleev at openjdk.java.net  Wed May 26 02:22:42 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 26 May 2021 02:22:42 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v6]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:

 - JapaneseImperialCalendar: use switch expressions
 - Use yield in java.util.Calendar.Builder.build

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4161/files
  - new: https://git.openjdk.java.net/jdk/pull/4161/files/f4ad5f14..e8cdf10e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=04-05

  Stats: 155 lines in 2 files changed: 56 ins; 61 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Wed May 26 02:22:43 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 26 May 2021 02:22:43 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v5]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
 
Message-ID: 

On Tue, 25 May 2021 15:51:38 GMT, Chris Hegarty  wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More vertical alignment
>
> src/java.base/share/classes/java/util/Calendar.java line 1507:
> 
>> 1505:                 }
>> 1506:                 case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true);
>> 1507:                 default -> throw new IllegalArgumentException("unknown calendar type: " + type);
> 
> In this case, it would be good to yield the result of the switch expression and assign that to a local, rather than assigning in each of the case arms, e.g:
> 
>     final Calendar cal = switch (type) {
>         case "gregory" -> new GregorianCalendar(zone, locale, true);
>         case "iso8601" -> {
>             GregorianCalendar gcal = new GregorianCalendar(zone, locale, true);
>             // make gcal a proleptic Gregorian
>             gcal.setGregorianChange(new Date(Long.MIN_VALUE));
>             // and week definition to be compatible with ISO 8601
>             setWeekDefinition(MONDAY, 4);
>             yield gcal;
>         }
>         case "buddhist" -> {
>             var buddhistCalendar = new BuddhistCalendar(zone, locale);
>             buddhistCalendar.clear();
>             yield buddhistCalendar;
>         }
>         case "japanese" -> new JapaneseImperialCalendar(zone, locale, true);
>         default -> throw new IllegalArgumentException("unknown calendar type: " + type);
>     };

Done, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Wed May 26 02:22:45 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 26 May 2021 02:22:45 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v5]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
 
Message-ID: 

On Tue, 25 May 2021 16:47:15 GMT, Brian Goetz  wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More vertical alignment
>
> src/java.base/share/classes/java/util/Calendar.java line 1507:
> 
>> 1505:                 }
>> 1506:                 case "japanese" -> cal = new JapaneseImperialCalendar(zone, locale, true);
>> 1507:                 default -> throw new IllegalArgumentException("unknown calendar type: " + type);
> 
> Agree with Chris' suggestion here.

Done!

> src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1124:
> 
>> 1122:                 return Math.max(LEAST_MAX_VALUES[YEAR], d.getYear());
>> 1123:             }
>> 1124:         }
> 
> A switch with one element here is kind of weird.  I would turn this into "return switch (field) { ... }", with two cases, YEAR and default.

Done, also at line 1169

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From iris at openjdk.java.net  Wed May 26 02:30:13 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 26 May 2021 02:30:13 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v6]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: 

On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JapaneseImperialCalendar: use switch expressions
>  - Use yield in java.util.Calendar.Builder.build

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Wed May 26 02:30:15 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 26 May 2021 02:30:15 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v6]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: 

On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JapaneseImperialCalendar: use switch expressions
>  - Use yield in java.util.Calendar.Builder.build

src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1316:

> 1314:         JapaneseImperialCalendar jc = getNormalizedCalendar();
> 1315:         LocalGregorianCalendar.Date date = jc.jdate;
> 1316:         int normalizedYear = date.getNormalizedYear();

This variable was unused

src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1423:

> 1421:             case WEEK_OF_MONTH -> {
> 1422:                 LocalGregorianCalendar.Date jd = jcal.getCalendarDate(Long.MAX_VALUE, getZone());
> 1423:                 if (date.getEra() == jd.getEra() && date.getYear() == jd.getYear()) {

I inverted the `if` condition here, as it was negated and a much shorter branch was in `else`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Wed May 26 02:30:16 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 26 May 2021 02:30:16 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v5]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
 
Message-ID: 

On Tue, 25 May 2021 16:52:06 GMT, Brian Goetz  wrote:

>> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More vertical alignment
>
> src/java.base/share/classes/java/util/JapaneseImperialCalendar.java line 1371:
> 
>> 1369:                     }
>> 1370:                 }
>> 1371:             }
> 
> Pull value assignment out of switch?

This is a much bigger change which is probably harder to review. I did it, please take a look. One point is whether to unwrap the final `else` after `yield`:

if (...) {
    ...
    yield ...
} else { // should we remove else?
    ...
}

I prefer unwrapping, as this reduces the indentation, so I did it. Please tell me if this contradicts with the preferred OpenJDK style.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From jnimeh at openjdk.java.net  Wed May 26 03:02:14 2021
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Wed, 26 May 2021 03:02:14 GMT
Subject: RFR: 8267750: Incomplete fix for JDK-8267683
In-Reply-To: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>
References: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>
Message-ID: 

On Wed, 26 May 2021 01:12:14 GMT, Bradford Wetmore  wrote:

> Missed updating today's changeset with the new variable name.
> 
> It's a "one character fix."

Looks good.

-------------

Marked as reviewed by jnimeh (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4196


From wetmore at openjdk.java.net  Wed May 26 03:21:17 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 26 May 2021 03:21:17 GMT
Subject: Integrated: 8267750: Incomplete fix for JDK-8267683
In-Reply-To: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>
References: <_nl5LPuAu97krJoiXNg0b9A7W_98JJUGpCaw79Gqzhk=.b9527835-7dde-499d-9677-d8fb4be24147@github.com>
Message-ID: 

On Wed, 26 May 2021 01:12:14 GMT, Bradford Wetmore  wrote:

> Missed updating today's changeset with the new variable name.
> 
> It's a "one character fix."

This pull request has now been integrated.

Changeset: b33b8bc8
Author:    Bradford Wetmore 
URL:       https://git.openjdk.java.net/jdk/commit/b33b8bc88da3afe4f9f6321673df061ea4196962
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8267750: Incomplete fix for JDK-8267683

Reviewed-by: jnimeh

-------------

PR: https://git.openjdk.java.net/jdk/pull/4196


From alanb at openjdk.java.net  Wed May 26 06:24:22 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 26 May 2021 06:24:22 GMT
Subject: RFR: 8267123: Remove RMI Activation
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks  wrote:

> This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
> 
> This is a fairly straightforward removal of this component.
>  - Activation implementation classes removed
>  - Activation tests removed
>  - adjustments to various comments to remove references to Activation
>  - adjustments to some code to remove special-case support for Activation from core RMI
>  - adjustments to several tests to remove testing and support for, and mentions of Activation
>  - remove `rmid` tool
> 
> (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.)

One other test that might need an update is test/jdk/sun/rmi/log/ReliableLog/LogAlignmentTest.java, it might be just the summary.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4194


From fguallini at openjdk.java.net  Wed May 26 10:03:13 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Wed, 26 May 2021 10:03:13 GMT
Subject: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain
 java tests and fix failures
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 13:19:53 GMT, Fernando Guallini  wrote:

> Refactor the following shell tests to Java:
> - security/pkcs11/KeyStore/Basic.sh
> - security/pkcs11/KeyStore/ClientAuth.sh
> - security/pkcs11/KeyStore/SecretKeysBasic.sh
> - security/pkcs11/Provider/ConfigQuotedString.sh
> - security/pkcs11/Provider/Login.sh
> - security/pkcs11/Config/ReadConfInUTF16Env.sh
> 
> Currently, most of the shell tests in the list may be ignored during execution time in most platforms since they are incorrectly filtered out by the OS name they are run on. For example, ClientAuth.sh is only run if the OS name is equal to ?Linux?, but OS name may also include the architecture such as ?Linux x86_64?. Those platform constraints are removed in this PR.
> 
> Additionally, further changes are introduced in the following test:
> 
> - ClientAuth: it was failing intermittently because the server side was binding to the wildcard address. The issue is fixed by binding to loopback address instead. Also, Thread.sleep is replaced with CountdownLatch to facilitate synchronization between client and server. Finally, a new ?user1? certificate was generated since the current one has expired.
> 
> - Basic: Remove redundant X509Certificate casting 
> 
> - SecretKeysBasic: it was already in the problem list since it reproduces the open bug JDK-8209398 and fails. Test is refactored to java and still reproduces the issue.
> 
> All the mentioned tests were run many times in multiple platforms to ensure stability

Please if someone could review and sponsor this PR. Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/4092


From github.com+42899633+eastig at openjdk.java.net  Wed May 26 14:19:25 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 26 May 2021 14:19:25 GMT
Subject: RFR: 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2
 AArch64
Message-ID: 

Tests sun/security/pkcs11 are skipped on AArch64 Linux when they cannot find NSS libraries in one of the directories {'/usr/lib/aarch64-linux-gnu/', '/usr/lib/aarch64-linux-gnu/nss/'}. On Amazon Linux 2 the libraries are in /usr/lib64. 

This patch adds '/usr/lib64' to the search list of directories.
Test:
- Before the patch

$ make run-test TEST=sun/security/pkcs11
$ cd build
$ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
129

- After the patch

$ make run-test TEST=sun/security/pkcs11
$ cd build
$ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
0

-------------

Commit messages:
 - 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2 AArch64

Changes: https://git.openjdk.java.net/jdk/pull/4207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4207&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267721
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4207/head:pull/4207

PR: https://git.openjdk.java.net/jdk/pull/4207


From hohensee at amazon.com  Wed May 26 14:43:55 2021
From: hohensee at amazon.com (Hohensee, Paul)
Date: Wed, 26 May 2021 14:43:55 +0000
Subject: RFR: 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2
 AArch64
Message-ID: <438BBCDF-F595-495B-8C55-67887801921D@amazon.com>

This looks fine (and safe) to me. There are probably other Linux distros where the NSS libraries are in /usr/lib64. Perhaps RHEL? "rpm -E %{rhel}" on AL2 produces "7", so there seems to be some RHEL DNA in AL2.

Thanks,
Paul

?-----Original Message-----
From: security-dev  on behalf of Evgeny Astigeevich 
Date: Wednesday, May 26, 2021 at 7:21 AM
To: "security-dev at openjdk.java.net" 
Subject: RFR: 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2 AArch64

Tests sun/security/pkcs11 are skipped on AArch64 Linux when they cannot find NSS libraries in one of the directories {'/usr/lib/aarch64-linux-gnu/', '/usr/lib/aarch64-linux-gnu/nss/'}. On Amazon Linux 2 the libraries are in /usr/lib64.

This patch adds '/usr/lib64' to the search list of directories.
Test:
- Before the patch

$ make run-test TEST=sun/security/pkcs11
$ cd build
$ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
129

- After the patch

$ make run-test TEST=sun/security/pkcs11
$ cd build
$ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
0

-------------

Commit messages:
 - 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2 AArch64

Changes: https://git.openjdk.java.net/jdk/pull/4207/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4207&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267721
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4207.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4207/head:pull/4207

PR: https://git.openjdk.java.net/jdk/pull/4207


From phh at openjdk.java.net  Wed May 26 14:55:17 2021
From: phh at openjdk.java.net (Paul Hohensee)
Date: Wed, 26 May 2021 14:55:17 GMT
Subject: RFR: 8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2
 AArch64
In-Reply-To: 
References: 
Message-ID: <_baDDIovlCcul0d3T2k0dqcurTnhaMBehPjzSMaWa1E=.c63ba167-1b51-415a-b9b4-5a85d34062be@github.com>

On Wed, 26 May 2021 14:11:18 GMT, Evgeny Astigeevich  wrote:

> Tests sun/security/pkcs11 are skipped on AArch64 Linux when they cannot find NSS libraries in one of the directories {'/usr/lib/aarch64-linux-gnu/', '/usr/lib/aarch64-linux-gnu/nss/'}. On Amazon Linux 2 the libraries are in /usr/lib64. 
> 
> This patch adds '/usr/lib64' to the search list of directories.
> Test:
> - Before the patch
> 
> $ make run-test TEST=sun/security/pkcs11
> $ cd build
> $ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
> 129
> 
> - After the patch
> 
> $ make run-test TEST=sun/security/pkcs11
> $ cd build
> $ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
> 0

Marked as reviewed by phh (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4207


From rriggs at openjdk.java.net  Wed May 26 18:35:21 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 26 May 2021 18:35:21 GMT
Subject: RFR: 8267123: Remove RMI Activation
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks  wrote:

> This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
> 
> This is a fairly straightforward removal of this component.
>  - Activation implementation classes removed
>  - Activation tests removed
>  - adjustments to various comments to remove references to Activation
>  - adjustments to some code to remove special-case support for Activation from core RMI
>  - adjustments to several tests to remove testing and support for, and mentions of Activation
>  - remove `rmid` tool
> 
> (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.)

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4194


From smarks at openjdk.java.net  Wed May 26 19:49:04 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 26 May 2021 19:49:04 GMT
Subject: RFR: 8267123: Remove RMI Activation
In-Reply-To: 
References: 
Message-ID: <6dMALeSEys26_TFkj3m4WSgOehMYVZuZzUHRQf9kp3I=.b3b00dab-9265-4522-88e6-fc0cb9593a3f@github.com>

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks  wrote:

> This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
> 
> This is a fairly straightforward removal of this component.
>  - Activation implementation classes removed
>  - Activation tests removed
>  - adjustments to various comments to remove references to Activation
>  - adjustments to some code to remove special-case support for Activation from core RMI
>  - adjustments to several tests to remove testing and support for, and mentions of Activation
>  - remove `rmid` tool
> 
> (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.)

AlanBateman wrote:

> test/jdk/sun/rmi/log/ReliableLog/LogAlignmentTest.java

Oh yes, this test mentions `rmid`, but it is basically a direct test of the `ReliableLog` stuff and it doesn't actually use or depend on Activation or `rmid`. The test still runs and passes.

I'll do a followup pass to see if anything in the system uses anything in the `sun.rmi.log` package. Maybe the only user was Activation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4194


From github.com+42899633+eastig at openjdk.java.net  Wed May 26 21:12:13 2021
From: github.com+42899633+eastig at openjdk.java.net (Evgeny Astigeevich)
Date: Wed, 26 May 2021 21:12:13 GMT
Subject: Integrated: 8267721: Enable sun/security/pkcs11 tests for Amazon
 Linux 2 AArch64
In-Reply-To: 
References: 
Message-ID: <06Ybu77pRTViDeBIS2sKTUoL6bEHq4Y__Uy8ZERixmo=.8a1fd3ad-c61d-41d3-877d-cb33f3addaa8@github.com>

On Wed, 26 May 2021 14:11:18 GMT, Evgeny Astigeevich  wrote:

> Tests sun/security/pkcs11 are skipped on AArch64 Linux when they cannot find NSS libraries in one of the directories {'/usr/lib/aarch64-linux-gnu/', '/usr/lib/aarch64-linux-gnu/nss/'}. On Amazon Linux 2 the libraries are in /usr/lib64. 
> 
> This patch adds '/usr/lib64' to the search list of directories.
> Test:
> - Before the patch
> 
> $ make run-test TEST=sun/security/pkcs11
> $ cd build
> $ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
> 129
> 
> - After the patch
> 
> $ make run-test TEST=sun/security/pkcs11
> $ cd build
> $ find . -name '*.jtr' -exec grep 'find NSS' {} ; | wc -l
> 0

This pull request has now been integrated.

Changeset: a859d87c
Author:    Evgeny Astigeevich 
Committer: Paul Hohensee 
URL:       https://git.openjdk.java.net/jdk/commit/a859d87cc1d0629609883968656f0187909a099d
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8267721: Enable sun/security/pkcs11 tests for Amazon Linux 2 AArch64

Reviewed-by: phh

-------------

PR: https://git.openjdk.java.net/jdk/pull/4207


From ascarpino at openjdk.java.net  Wed May 26 21:13:56 2021
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 26 May 2021 21:13:56 GMT
Subject: RFR: 8255557: Decouple GCM from CipherCore [v7]
In-Reply-To: 
References: 
Message-ID: 

> Hi,
> 
> I need a review of this rather large change to GCM.  GCM will no longer use CipherCore, and AESCrypt  to handle it's buffers and other objects.  It is also a major code redesign limits the amount of data copies and make some performance-based decisions.
> 
> Thanks
> 
> Tony

Anthony Scarpino has updated the pull request incrementally with one additional commit since the last revision:

  Remove GCTR reset() calls because GCTR is released after the operation
  some variable name consistency
  other small cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4072/files
  - new: https://git.openjdk.java.net/jdk/pull/4072/files/ccb7b357..d230e665

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4072&range=05-06

  Stats: 95 lines in 3 files changed: 19 ins; 22 del; 54 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4072/head:pull/4072

PR: https://git.openjdk.java.net/jdk/pull/4072


From dongbohe at openjdk.java.net  Thu May 27 02:19:17 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Thu, 27 May 2021 02:19:17 GMT
Subject: RFR: 8267817: [TEST] Remove unnecessary init in
 test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench:setup
Message-ID: 

decryptCipher will be reinitialized in decrypt, which will loses all previously-acquired state. Therefore, it's not necessary to initialize in setup.

-------------

Commit messages:
 - 8267817: [TEST] Remove unnecessary init in test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench:setup

Changes: https://git.openjdk.java.net/jdk/pull/4215/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4215&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267817
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4215.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4215/head:pull/4215

PR: https://git.openjdk.java.net/jdk/pull/4215


From alanb at openjdk.java.net  Thu May 27 05:53:14 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 27 May 2021 05:53:14 GMT
Subject: RFR: 8267123: Remove RMI Activation
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks  wrote:

> This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
> 
> This is a fairly straightforward removal of this component.
>  - Activation implementation classes removed
>  - Activation tests removed
>  - adjustments to various comments to remove references to Activation
>  - adjustments to some code to remove special-case support for Activation from core RMI
>  - adjustments to several tests to remove testing and support for, and mentions of Activation
>  - remove `rmid` tool
> 
> (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.)

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4194


From ssahoo at openjdk.java.net  Thu May 27 09:00:11 2021
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Thu, 27 May 2021 09:00:11 GMT
Subject: RFR: 8179880: Refactor javax/security shell tests to plain java tests
Message-ID: <6D0YuwvankICr5b9piuXuWPHQNX7jpVqmcLsZvnNj_o=.0b8591a9-9cc1-4609-9e47-72b280089a65@github.com>

This change converts JTREG shell Test scripts to Java equivalent.

-------------

Commit messages:
 - 8179880: Refactor javax/security shell tests to plain java tests

Changes: https://git.openjdk.java.net/jdk/pull/4220/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4220&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8179880
  Stats: 99 lines in 2 files changed: 11 ins; 80 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4220.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4220/head:pull/4220

PR: https://git.openjdk.java.net/jdk/pull/4220


From ssahoo at openjdk.java.net  Thu May 27 09:59:04 2021
From: ssahoo at openjdk.java.net (Sibabrata Sahoo)
Date: Thu, 27 May 2021 09:59:04 GMT
Subject: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain
 java tests and fix failures
In-Reply-To: 
References: 
Message-ID: 

On Tue, 18 May 2021 13:19:53 GMT, Fernando Guallini  wrote:

> Refactor the following shell tests to Java:
> - security/pkcs11/KeyStore/Basic.sh
> - security/pkcs11/KeyStore/ClientAuth.sh
> - security/pkcs11/KeyStore/SecretKeysBasic.sh
> - security/pkcs11/Provider/ConfigQuotedString.sh
> - security/pkcs11/Provider/Login.sh
> - security/pkcs11/Config/ReadConfInUTF16Env.sh
> 
> Currently, most of the shell tests in the list may be ignored during execution time in most platforms since they are incorrectly filtered out by the OS name they are run on. For example, ClientAuth.sh is only run if the OS name is equal to ?Linux?, but OS name may also include the architecture such as ?Linux x86_64?. Those platform constraints are removed in this PR.
> 
> Additionally, further changes are introduced in the following test:
> 
> - ClientAuth: it was failing intermittently because the server side was binding to the wildcard address. The issue is fixed by binding to loopback address instead. Also, Thread.sleep is replaced with CountdownLatch to facilitate synchronization between client and server. Finally, a new ?user1? certificate was generated since the current one has expired.
> 
> - Basic: Remove redundant X509Certificate casting 
> 
> - SecretKeysBasic: it was already in the problem list since it reproduces the open bug JDK-8209398 and fails. Test is refactored to java and still reproduces the issue.
> 
> All the mentioned tests were run many times in multiple platforms to ensure stability

test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java line 25:

> 23: 
> 24: /* @test
> 25:  * @bug 8187023

Should it have the enhancement bug id too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4092


From redestad at openjdk.java.net  Thu May 27 10:01:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 27 May 2021 10:01:09 GMT
Subject: RFR: 8267817: [TEST] Remove unnecessary init in
 test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench:setup
In-Reply-To: 
References: 
Message-ID: 

On Thu, 27 May 2021 02:11:59 GMT, Dongbo He  wrote:

> decryptCipher will be reinitialized in decrypt, which will loses all previously-acquired state. Therefore, it's not necessary to initialize in setup.

Looks good.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4215


From mcimadamore at openjdk.java.net  Thu May 27 10:11:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 27 May 2021 10:11:43 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v25]
In-Reply-To: 
References: 
Message-ID: 

> 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:

  * Add missing `final` in some static fields
  * Downgrade native methods in ProgrammableUpcallHandler to package-private

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3699/files
  - new: https://git.openjdk.java.net/jdk/pull/3699/files/e927c235..e1fcd2d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=23-24

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 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


From fguallini at openjdk.java.net  Thu May 27 10:31:05 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Thu, 27 May 2021 10:31:05 GMT
Subject: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain
 java tests and fix failures
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 27 May 2021 09:55:10 GMT, Sibabrata Sahoo  wrote:

>> Refactor the following shell tests to Java:
>> - security/pkcs11/KeyStore/Basic.sh
>> - security/pkcs11/KeyStore/ClientAuth.sh
>> - security/pkcs11/KeyStore/SecretKeysBasic.sh
>> - security/pkcs11/Provider/ConfigQuotedString.sh
>> - security/pkcs11/Provider/Login.sh
>> - security/pkcs11/Config/ReadConfInUTF16Env.sh
>> 
>> Currently, most of the shell tests in the list may be ignored during execution time in most platforms since they are incorrectly filtered out by the OS name they are run on. For example, ClientAuth.sh is only run if the OS name is equal to ?Linux?, but OS name may also include the architecture such as ?Linux x86_64?. Those platform constraints are removed in this PR.
>> 
>> Additionally, further changes are introduced in the following test:
>> 
>> - ClientAuth: it was failing intermittently because the server side was binding to the wildcard address. The issue is fixed by binding to loopback address instead. Also, Thread.sleep is replaced with CountdownLatch to facilitate synchronization between client and server. Finally, a new ?user1? certificate was generated since the current one has expired.
>> 
>> - Basic: Remove redundant X509Certificate casting 
>> 
>> - SecretKeysBasic: it was already in the problem list since it reproduces the open bug JDK-8209398 and fails. Test is refactored to java and still reproduces the issue.
>> 
>> All the mentioned tests were run many times in multiple platforms to ensure stability
>
> test/jdk/sun/security/pkcs11/Config/ReadConfInUTF16Env.java line 25:
> 
>> 23: 
>> 24: /* @test
>> 25:  * @bug 8187023
> 
> Should it have the enhancement bug id too.

My understanding is that we should only include the id of product bugs, no test enhancements. That was a comment somebody added in a previous PR. The reason is that you can track changes in the test file with git history, whereas it is only possible to track the related product bug id by adding it manually to the class header

-------------

PR: https://git.openjdk.java.net/jdk/pull/4092


From mcimadamore at openjdk.java.net  Thu May 27 10:37:38 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 27 May 2021 10:37:38 GMT
Subject: RFR: 8264774: Implementation of Foreign Function and Memory API
 (Incubator) [v26]
In-Reply-To: 
References: 
Message-ID: <9sO-moMQsSpzVGkmQ50SQAS1dcBNpC0EyO83lwDGFNI=.a4c737f0-7d4f-43a7-a5f8-2a504b20690f@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'master' into JEP-412
 - * Add missing `final` in some static fields
   * Downgrade native methods in ProgrammableUpcallHandler to package-private
 - Add sealed modifiers in morally sealed API interfaces
 - Merge branch 'master' into JEP-412
 - Fix VaList test
   Remove unused code in Utils
 - Merge pull request #11 from JornVernee/JEP-412-MXCSR
   
   Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Add MXCSR save and restore to upcall stubs for non-windows platforms
 - Merge branch 'master' into JEP-412
 - Fix issue with bounded arena allocator
 - Rename is_entry_blob to is_optimized_entry_blob
   Rename as_entry_blob to as_optimized_entry_blob
   Fix misc typos and indentation issues
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/7278f56b...8bbddfc2

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3699/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=25
  Stats: 14501 lines in 219 files changed: 8847 ins; 3642 del; 2012 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


From dongbohe at openjdk.java.net  Thu May 27 11:53:09 2021
From: dongbohe at openjdk.java.net (Dongbo He)
Date: Thu, 27 May 2021 11:53:09 GMT
Subject: Integrated: 8267817: [TEST] Remove unnecessary init in
 test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench:setup
In-Reply-To: 
References: 
Message-ID: <2P6aFHqjJLe_eCipBFqdxPLaASa1fxJC-q4vEtHpWF0=.cc0b570e-62bf-4240-9a37-fff2c1b26da6@github.com>

On Thu, 27 May 2021 02:11:59 GMT, Dongbo He  wrote:

> decryptCipher will be reinitialized in decrypt, which will loses all previously-acquired state. Therefore, it's not necessary to initialize in setup.

This pull request has now been integrated.

Changeset: 85f61652
Author:    Dongbo He 
Committer: Claes Redestad 
URL:       https://git.openjdk.java.net/jdk/commit/85f616522b2dc8e7b4c31d760c3171ac74a5490f
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8267817: [TEST] Remove unnecessary init in test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench:setup

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/4215


From sean.mullan at oracle.com  Thu May 27 12:35:01 2021
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 27 May 2021 08:35:01 -0400
Subject: Fuzzing for java.security.* (and other libraries)
In-Reply-To: 
References: 
Message-ID: <0b8c32c3-3f97-f84d-1fea-ba1e51b3016d@oracle.com>

Hi Fabian,

Thanks for posting this and your interest in helping to test and improve 
the quality of the Java core libraries. One comment/request below:

On 5/17/21 9:09 AM, Fabian Meumertzheim wrote:
> (Crosspost from core-libs-dev@: 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077483.html 
> )
>
> I'm one of the maintainers of Jazzer 
> (https://github.com/CodeIntelligenceTesting/jazzer 
> ), a new 
> open-source fuzzer for the JVM platform. Jazzer has recently been 
> integrated into Google's OSS-Fuzz (https://google.github.io/oss-fuzz/ 
> ) to allow for free continuous 
> fuzzing of important open-source Java projects. Jazzer has already 
> found over a hundred bugs and eight security issues in libraries such 
> as Apache Commons, PDFBox and the OWASP json-sanitizer.
>
> Jazzer finds unexpected exceptions and infinite loops by default, but 
> can also be used to check domain-specific properties such as 
> decrypt(encrypt(data)) == data. Since it tracks the coverage it 
> achieves using instrumentation applied by a Java agent, it can 
> synthesize interesting test data from scratch.
>
> If there is interest from your side, I could set up the Java core 
> libraries themselves for fuzzing in OSS-Fuzz. Especially the parts 
> that are frequently applied to untrusted input, such as 
> java.security.* and javax.imageio.*, would benefit from fuzz tests. I 
> have prepared basic fuzz tests for some of the classes in these 
> packages at 
> https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk 
> , 
> which has already resulted in a few bug reports by running it locally 
> (JDK-8267086 is one of them affecting java.security.*).
>
> All I would need from you is:
>
> * a list of email addresses to which the fuzzer findings should be 
> sent (ideally associated with Google accounts for authentication to 
> full reports on oss-fuzz.com ),
All fuzzer findings with security implications should be sent to the 
OpenJDK Vulnerability Group. See 
https://openjdk.java.net/groups/vulnerability/report 
 for more 
information. Please send the detailed information (description, impacted 
release, and PoC) to /vuln-report at openjdk.java.net 
/.

Thanks,
Sean
> * ideas for additional fuzz tests, in particular those where there are 
> interesting properties to verify.
>
> The technical?questions about setting up the OpenJDK in OSS-Fuzz have 
> already been resolved (see also 
> https://github.com/google/oss-fuzz/issues/5757 
> ).
>
> If you need more information on OSS-Fuzz or fuzzing in general, I am 
> happy to help.
>
> Fabian (@fmeum on GitHub)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From meumertzheim at code-intelligence.com  Thu May 27 13:12:35 2021
From: meumertzheim at code-intelligence.com (Fabian Meumertzheim)
Date: Thu, 27 May 2021 15:12:35 +0200
Subject: Fuzzing for java.security.* (and other libraries)
In-Reply-To: <0b8c32c3-3f97-f84d-1fea-ba1e51b3016d@oracle.com>
References: 
 <0b8c32c3-3f97-f84d-1fea-ba1e51b3016d@oracle.com>
Message-ID: 

Hi Sean,


On Thu, May 27, 2021 at 2:35 PM Sean Mullan  wrote:

> Hi Fabian,
>
> Thanks for posting this and your interest in helping to test and improve
> the quality of the Java core libraries. One comment/request below:
>
> On 5/17/21 9:09 AM, Fabian Meumertzheim wrote:
>
> (Crosspost from core-libs-dev@:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077483.html
> )
>
> I'm one of the maintainers of Jazzer (
> https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
> fuzzer for the JVM platform. Jazzer has recently been integrated into
> Google's OSS-Fuzz (https://google.github.io/oss-fuzz/) to allow for free
> continuous fuzzing of important open-source Java projects. Jazzer has
> already found over a hundred bugs and eight security issues in libraries
> such as Apache Commons, PDFBox and the OWASP json-sanitizer.
>
> Jazzer finds unexpected exceptions and infinite loops by default, but can
> also be used to check domain-specific properties such as
> decrypt(encrypt(data)) == data. Since it tracks the coverage it achieves
> using instrumentation applied by a Java agent, it can synthesize
> interesting test data from scratch.
>
> If there is interest from your side, I could set up the Java core
> libraries themselves for fuzzing in OSS-Fuzz. Especially the parts that are
> frequently applied to untrusted input, such as java.security.* and
> javax.imageio.*, would benefit from fuzz tests. I have prepared basic fuzz
> tests for some of the classes in these packages at
> https://github.com/CodeIntelligenceTesting/oss-fuzz/tree/openjdk/projects/openjdk,
> which has already resulted in a few bug reports by running it locally
> (JDK-8267086 is one of them affecting java.security.*).
>
> All I would need from you is:
>
> * a list of email addresses to which the fuzzer findings should be sent
> (ideally associated with Google accounts for authentication to full reports
> on oss-fuzz.com),
>
> All fuzzer findings with security implications should be sent to the
> OpenJDK Vulnerability Group. See
> https://openjdk.java.net/groups/vulnerability/report for more
> information. Please send the detailed information (description, impacted
> release, and PoC) to *vuln-report at openjdk.java.net
> *.
>

Just to clarify the role of OSS-Fuzz: The fuzzing and report filing would
be performed automatically. Since not every finding will necessarily have
security implications (but all will be actual bugs), I'm hesitant to have
these reports submitted to vuln-report at . Ideally, we would find two or
three humans that agree to receive the findings reports and forward those
deemed security issues to that list.

Best,
Fabian

>
> Thanks,
> Sean
>
> * ideas for additional fuzz tests, in particular those where there are
> interesting properties to verify.
>
> The technical questions about setting up the OpenJDK in OSS-Fuzz have
> already been resolved (see also
> https://github.com/google/oss-fuzz/issues/5757).
>
> If you need more information on OSS-Fuzz or fuzzing in general, I am happy
> to help.
>
> Fabian (@fmeum on GitHub)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From dfuchs at openjdk.java.net  Thu May 27 13:58:13 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 27 May 2021 13:58:13 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v6]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
Message-ID: 

On Wed, 26 May 2021 02:22:42 GMT, Tagir F. Valeev  wrote:

>> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
>> 
>> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?
>
> Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - JapaneseImperialCalendar: use switch expressions
>  - Use yield in java.util.Calendar.Builder.build

Globally looks good.
I haven't reviewed `src/java.base/share/classes/java/util/regex/Pattern.java` due to formatting issues. See also my other remark about `java.util.concurrent`.

src/java.base/share/classes/java/util/concurrent/FutureTask.java line 495:

> 493:      * @return a string representation of this FutureTask
> 494:      */
> 495:     public String toString() {

Classes in java.util.concurrent are handled upstream. It would probably be better to leave them out of this patch. Or synchronize with @DougLea to see how to bring these changes in the upstream repo.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From smarks at openjdk.java.net  Thu May 27 15:23:10 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 27 May 2021 15:23:10 GMT
Subject: Integrated: 8267123: Remove RMI Activation
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 May 2021 18:04:45 GMT, Stuart Marks  wrote:

> This is the implementation of [JEP 407](https://openjdk.java.net/jeps/407).
> 
> This is a fairly straightforward removal of this component.
>  - Activation implementation classes removed
>  - Activation tests removed
>  - adjustments to various comments to remove references to Activation
>  - adjustments to some code to remove special-case support for Activation from core RMI
>  - adjustments to several tests to remove testing and support for, and mentions of Activation
>  - remove `rmid` tool
> 
> (Personally, I found that reviewing using the webrev was easier than navigating github's diff viewer.)

This pull request has now been integrated.

Changeset: 7c85f351
Author:    Stuart Marks 
URL:       https://git.openjdk.java.net/jdk/commit/7c85f3510cb84881ff232548fbcc933ef4b34972
Stats:     21982 lines in 243 files changed: 0 ins; 21930 del; 52 mod

8267123: Remove RMI Activation

Reviewed-by: erikj, rriggs, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/4194


From prr at openjdk.java.net  Thu May 27 17:15:06 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:15:06 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v4]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep only one systemProperty tag

Marked as reviewed by prr (Reviewer).

I'm OK with this now given that the refactoring is already underway at https://github.com/openjdk/jdk/pull/4138

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From prr at openjdk.java.net  Thu May 27 17:46:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 27 May 2021 17:46:07 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

src/java.desktop/share/classes/java/awt/Component.java line 630:

> 628:         }
> 629: 
> 630:         @SuppressWarnings("removal")

I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
that was needed because of the usage in this static block and you could not apply the annotation here.
Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
Can you explain ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From weijun at openjdk.java.net  Thu May 27 20:16:25 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 27 May 2021 20:16:25 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: 

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04
  Stats: 2022 lines in 825 files changed: 1884 ins; 10 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073


From chap at anastigmatix.net  Fri May 28 01:35:53 2021
From: chap at anastigmatix.net (Chapman Flack)
Date: Thu, 27 May 2021 21:35:53 -0400
Subject: JEP 411: Missing use-case: user functions in an RDBMS
Message-ID: <60B048F9.7090105@anastigmatix.net>

Hello, I see I am another person relatively late to stumble on this
"well publicized" JEP. (I am not sure how to recommend the publicity
could have been better handled, but apparently the avenues that were
used aren't ones that reached me.)

I maintain, on a volunteer basis, the extension for Java server-side
functions in the PostgreSQL RDBMS [1].

I got the news of this JEP through occasionally visiting the JDK 17
page to see what JEPs are proposed and targeted that might be of use
in the project, and one day I visited (could have been as late as May 17
according to the Wayback Machine) and there was nothing of great
interest (though I have some pleasant ideas for sealed classes and I
really wish JEP 412 were done incubating!), and I didn't check back
until just recently, and then I looked and saw this JEP.

I've read through the very long "Missing use-case: monitoring/
restricting libraries" thread, and some of the points raised there
have echoes here.

Any PostgreSQL server-side function implementation for a language foo
will be expected to say it is a "trusted" or "untrusted" language (or
provide both) as defined in the PostgreSQL docs [2].

A "trusted" one is expected to restrict certain actions (access to the
server filesystem, perhaps network connections, etc.).

OS-level controls are too coarse because the RDBMS process that the
language extension gets dlopened into certainly has reasons of its own
to manipulate files and sockets.

It might, perhaps, be shown that every available trusted language for
PostgreSQL could be imperfect or exploitable in some way; I think that's
beside the point, which is that they all are meant to take credible
steps to supply the expected layer of cheese with whatever small holes
may be present.

In the current architecture, Java backend functions can be restricted
with very fine grain, anything that a PolicyFile can specify.

It looks as if I will have to do a maintenance release, which will
have to supply the extra -Djava.security.manager=allow when running
on 17 (and spam the RDBMS log file with the apparently unsuppressable
warning every time a JVM starts [3]), and then I will have to detect
whatever subsequent Java release "degrades" the classes, and refuse to
execute trusted functions on that release or later.

Beyond that, I'll need to begin on some rearchitected major release
to be able to meet the requirements some other way.

Suppose I relax the requirements to merely restricting filesystem
and network operations. Will there be any simple, reliable way for
me to install some handler to filter those? I have seen JVMTI
instrumentation suggested. I suppose an interposing FileSystemProvider
could be an option for filesystem operations. SocketFactory and
ServerSocketFactory might offer ways to interpose on network
operations, except that there seems to be no documentation of how
the default factories are to be set: "specified by environment-specific
configuration mechanisms ... a framework could use a factory customized
for its own purposes" doesn't seem quite sufficient. I could be considered
to be providing a framework: is the expectation that I must read the
source and then JNI-poke an undocumented static in order to set a factory?

Assuming that hurdle cleared, socket restrictions might not be too bad.
The JRE probably doesn't do a lot of network operations on its own behalf,
so a "simple deep sandbox" in Ron's taxonomy is sufficient there; whatever
operations are being initiated will be coming from the application code.

That's not even remotely true for file operations though: the Java runtime
does stuff with files! Early PL/Java versions that tried to make do with a
"simple" SecurityManager (devoid of the AccessController and stack
awareness) clearly demonstrated the problem, falling over because the
runtime needed to open /dev/random to make an SSL connection, or timezone
files to print a date, or write temporary files in compiling a Templates
object, or load agent classes to accept a visualvm connection.

Those problems all were solved by axing the "simple" SecurityManager and
reverting to the J2SE one with stack awareness. All those things then
Just Worked.

The reason, of course, is that those doPrivileged calls throughout
the implementation are carriers of vital information about which operations
are "taint-free" Java runtime internal details and which ones are coming
from the application. It isn't the application developer's business to know
that TransformerFactory.newTemplates() needs to scribble transparently
in some files. That vital information is known by the developers working
on the JDK and is still needed for any sane out-of-JDK reimplementation
of filesystem access controls.

I'm sensitive to the argument that lots of third-partly libraries have
always whiffed on putting their own doPrivileged calls in the right
places, so application developers have had to clean up after them anyway,
and that will only get worse after this JEP. But it still seems to me that
the JDK itself is a different story.

Suppose we simplify the problem to only preserving the information needed
to enable implementation of filesystem access controls. All the doPrivileged
calls in there because of other obscure permissions that will be abandoned,
never mind those. Can there be some way to retain the information that's
represented by the ones around taint-free filesystem operations?

- some kind of annotation?

- some very lightweight doPrivileged replacement that sets a thread-local
  flag that a filesystem-access filter, if present, could check?

- a set of openTaintFree()/deleteTaintFree()/... methods added to the
  filesystem APIs and used in place of the methods currently called within
  doPrivileged? Some mechanism like JEP 412's --enable-native-access could
  allow selected modules to call those methods, and a filter, if supplied,
  could just leave those alone.

Could some idea like this be a manageably-small burden for the JDK devs
to keep up to date? Much of the affected code is already very mature and
has the doPrivileged()s in the right places. It would be a sort of
mechanical transformation of those sites, plus a simple need to be aware
in new API development of where the file operations are on tainted values
or not. Isn't that already something devs need to be aware of?

Regards,
Chapman Flack


[1] https://tada.github.io/pljava/use/policy.html

[2]
https://www.postgresql.org/docs/13/sql-createlanguage.html#SQL-CREATELANGUAGE-PARAMETERS

[3] Say ... will that unsuppressable warning be written via the vfprintf
    hook? That would be nice, I could suppress it there then.


From weijun at openjdk.java.net  Fri May 28 02:01:19 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:01:19 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v5]
In-Reply-To: 
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 
Message-ID: 

On Thu, 27 May 2021 20:16:25 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - 8266459: Implement JEP 411: Deprecate the Security Manager for Removal

Two files were removed by JEP 403 and JEP 407, respectively. One method in `XMLSchemaFactory.java` got [its own](https://github.com/openjdk/jdk/commit/8c4719a58834dddcea39d69b199abf1aabf780e2#diff-593a224979eaff03e2a3df1863fcaf865364a31a2212cc0d1fe67a8458057857R429) `@SuppressWarnings` and have to be merged with the one here. Another file `ResourceBundle.java` had a portion of a method extracted into a [new method](https://github.com/openjdk/jdk/commit/a4c46e1e4f4f2f05c8002b2af683a390fc46b424#diff-59caf1a68085064b4b3eb4f6e33e440bb85ea93719f34660970e2d4eaf8ce469R3175) and the annotation must be moved there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Fri May 28 02:54:05 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 02:54:05 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
 
Message-ID: 

On Thu, 27 May 2021 17:42:56 GMT, Phil Race  wrote:

>> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update FtpClient.java
>
> src/java.desktop/share/classes/java/awt/Component.java line 630:
> 
>> 628:         }
>> 629: 
>> 630:         @SuppressWarnings("removal")
> 
> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
> that was needed because of the usage in this static block and you could not apply the annotation here.
> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
> Can you explain ?

There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From prr at openjdk.java.net  Fri May 28 03:15:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 28 May 2021 03:15:12 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Fri, 28 May 2021 02:50:55 GMT, Weijun Wang  wrote:

>> src/java.desktop/share/classes/java/awt/Component.java line 630:
>> 
>>> 628:         }
>>> 629: 
>>> 630:         @SuppressWarnings("removal")
>> 
>> I'm confused. I thought the reason this wasn't done in the JEP implementation PR is because of refactoring
>> that was needed because of the usage in this static block and you could not apply the annotation here.
>> Yet it seems you are doing exactly what was supposed to be impossible with no refactoring.
>> Can you explain ?
>
> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.

Ok. But I will quote you
"This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"

So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.

Why has the explanation changed ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From weijun at openjdk.java.net  Fri May 28 03:22:03 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Fri, 28 May 2021 03:22:03 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Fri, 28 May 2021 03:12:35 GMT, Phil Race  wrote:

>> There *is* a tiny refactoring here: a new variable `s2` is introduced so the 2nd `doPrivileged` call on line 636 is now also in a declaration statement (for `s2`) and therefore annotatable. Without this I cannot add the annotation on line 635.
>
> Ok. But I will quote you
> "This happens when a deprecated method is called inside a static block. The annotation can only be added to a declaration and here it must be the whole class"
> 
> So the way you explained this before made it sound like any time there was any SM API usage in a static block, the entire class needed to be annotated.
> 
> Why has the explanation changed ?

I should have been more precise. An annotation can only be added on a declaration, whether it's a variable, a method, or a class. Static block is not a declaration and the only one covers it is the class. But then if it's on a local variable declaration inside a static block, we certainly can annotate on that variable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From neliasso at openjdk.java.net  Fri May 28 09:52:06 2021
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 28 May 2021 09:52:06 GMT
Subject: RFR: 8267125: AES Galois CounterMode (GCM) interleaved
 implementation using AVX512 + VAES instructions
In-Reply-To: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
References: <0a7b_-PDU_JYXR7OrJRK8Z8QPRwLlV2vcHbBbW06SO8=.f0d61fd3-0205-40a7-b1a1-58caa2ea0f45@github.com>
Message-ID: 

On Fri, 14 May 2021 00:42:35 GMT, Smita Kamath  wrote:

> I would like to submit AES-GCM optimization for x86_64 architectures supporting AVX3+VAES (Evex encoded AES). This optimization interleaves AES and GHASH operations.
> Performance gain of ~1.5x - 2x for message sizes 8k and above.

Added hotspot-compiler label

-------------

PR: https://git.openjdk.java.net/jdk/pull/4019


From ron.pressler at oracle.com  Fri May 28 10:09:52 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 28 May 2021 10:09:52 +0000
Subject: JEP 411: Missing use-case: user functions in an RDBMS
In-Reply-To: <60B048F9.7090105@anastigmatix.net>
References: <60B048F9.7090105@anastigmatix.net>
Message-ID: 

Hi.

Before getting into alternatives and the vision for what would be possible
post-SecurityManager, it would help to explain what the use-case and 
requirements are.

When we talk about untrusted code we usually mean code that you believe
might be malicious and intentionally try to break through any restrictions
you place on it and attack you by any means, including denial-of-service,
while trusted code is assumed to not be malicious.

From what you?ve written I gather that you only intend to run trusted
?plugins", but wish to restrict their operations so that they don?t break
some application invariants and accidentally interfere with its operation.

If that is the case, would a ?shallow? sandbox, that restricts which APIs
are available to the plugin (e.g. only expose special APIs to interact
with files that go through filtering mechanisms) rather than restrict 
low-level operations where they ?bottom out? before being passed to the OS, 
suffice (*not* the one in my article, which is just intended for inspiration, 
and allows reflection without actually fully isolating it)?

Deep sandboxes, simple or stack-dependent, are useful for very ?rich? code,
that is potentially very big and possibly contains arbitrary third-party
libraries, while shallow sandboxes are more suitable to limited plugins.

While a complex, stack-dependent, deep sandbox *could* be used for plugins,
permissions that don?t specify what is forbidden but what is allowed
effectively also severely limit the use of third-party libraries, that
for example, might want to do benign operations with their own files,
and so effectively only allow very limited plugins. The result is a costly
mechanism that is overkill for what it?s used for.

? Ron

> On 28 May 2021, at 02:35, Chapman Flack  wrote:
> 
> Hello, I see I am another person relatively late to stumble on this
> "well publicized" JEP. (I am not sure how to recommend the publicity
> could have been better handled, but apparently the avenues that were
> used aren't ones that reached me.)
> 
> I maintain, on a volunteer basis, the extension for Java server-side
> functions in the PostgreSQL RDBMS [1].
> 
> I got the news of this JEP through occasionally visiting the JDK 17
> page to see what JEPs are proposed and targeted that might be of use
> in the project, and one day I visited (could have been as late as May 17
> according to the Wayback Machine) and there was nothing of great
> interest (though I have some pleasant ideas for sealed classes and I
> really wish JEP 412 were done incubating!), and I didn't check back
> until just recently, and then I looked and saw this JEP.
> 
> I've read through the very long "Missing use-case: monitoring/
> restricting libraries" thread, and some of the points raised there
> have echoes here.
> 
> Any PostgreSQL server-side function implementation for a language foo
> will be expected to say it is a "trusted" or "untrusted" language (or
> provide both) as defined in the PostgreSQL docs [2].
> 
> A "trusted" one is expected to restrict certain actions (access to the
> server filesystem, perhaps network connections, etc.).
> 
> OS-level controls are too coarse because the RDBMS process that the
> language extension gets dlopened into certainly has reasons of its own
> to manipulate files and sockets.
> 
> It might, perhaps, be shown that every available trusted language for
> PostgreSQL could be imperfect or exploitable in some way; I think that's
> beside the point, which is that they all are meant to take credible
> steps to supply the expected layer of cheese with whatever small holes
> may be present.
> 
> In the current architecture, Java backend functions can be restricted
> with very fine grain, anything that a PolicyFile can specify.
> 
> It looks as if I will have to do a maintenance release, which will
> have to supply the extra -Djava.security.manager=allow when running
> on 17 (and spam the RDBMS log file with the apparently unsuppressable
> warning every time a JVM starts [3]), and then I will have to detect
> whatever subsequent Java release "degrades" the classes, and refuse to
> execute trusted functions on that release or later.
> 
> Beyond that, I'll need to begin on some rearchitected major release
> to be able to meet the requirements some other way.
> 
> Suppose I relax the requirements to merely restricting filesystem
> and network operations. Will there be any simple, reliable way for
> me to install some handler to filter those? I have seen JVMTI
> instrumentation suggested. I suppose an interposing FileSystemProvider
> could be an option for filesystem operations. SocketFactory and
> ServerSocketFactory might offer ways to interpose on network
> operations, except that there seems to be no documentation of how
> the default factories are to be set: "specified by environment-specific
> configuration mechanisms ... a framework could use a factory customized
> for its own purposes" doesn't seem quite sufficient. I could be considered
> to be providing a framework: is the expectation that I must read the
> source and then JNI-poke an undocumented static in order to set a factory?
> 
> Assuming that hurdle cleared, socket restrictions might not be too bad.
> The JRE probably doesn't do a lot of network operations on its own behalf,
> so a "simple deep sandbox" in Ron's taxonomy is sufficient there; whatever
> operations are being initiated will be coming from the application code.
> 
> That's not even remotely true for file operations though: the Java runtime
> does stuff with files! Early PL/Java versions that tried to make do with a
> "simple" SecurityManager (devoid of the AccessController and stack
> awareness) clearly demonstrated the problem, falling over because the
> runtime needed to open /dev/random to make an SSL connection, or timezone
> files to print a date, or write temporary files in compiling a Templates
> object, or load agent classes to accept a visualvm connection.
> 
> Those problems all were solved by axing the "simple" SecurityManager and
> reverting to the J2SE one with stack awareness. All those things then
> Just Worked.
> 
> The reason, of course, is that those doPrivileged calls throughout
> the implementation are carriers of vital information about which operations
> are "taint-free" Java runtime internal details and which ones are coming
> from the application. It isn't the application developer's business to know
> that TransformerFactory.newTemplates() needs to scribble transparently
> in some files. That vital information is known by the developers working
> on the JDK and is still needed for any sane out-of-JDK reimplementation
> of filesystem access controls.
> 
> I'm sensitive to the argument that lots of third-partly libraries have
> always whiffed on putting their own doPrivileged calls in the right
> places, so application developers have had to clean up after them anyway,
> and that will only get worse after this JEP. But it still seems to me that
> the JDK itself is a different story.
> 
> Suppose we simplify the problem to only preserving the information needed
> to enable implementation of filesystem access controls. All the doPrivileged
> calls in there because of other obscure permissions that will be abandoned,
> never mind those. Can there be some way to retain the information that's
> represented by the ones around taint-free filesystem operations?
> 
> - some kind of annotation?
> 
> - some very lightweight doPrivileged replacement that sets a thread-local
>  flag that a filesystem-access filter, if present, could check?
> 
> - a set of openTaintFree()/deleteTaintFree()/... methods added to the
>  filesystem APIs and used in place of the methods currently called within
>  doPrivileged? Some mechanism like JEP 412's --enable-native-access could
>  allow selected modules to call those methods, and a filter, if supplied,
>  could just leave those alone.
> 
> Could some idea like this be a manageably-small burden for the JDK devs
> to keep up to date? Much of the affected code is already very mature and
> has the doPrivileged()s in the right places. It would be a sort of
> mechanical transformation of those sites, plus a simple need to be aware
> in new API development of where the file operations are on tainted values
> or not. Isn't that already something devs need to be aware of?
> 
> Regards,
> Chapman Flack
> 
> 
> [1] https://tada.github.io/pljava/use/policy.html
> 
> [2]
> https://www.postgresql.org/docs/13/sql-createlanguage.html#SQL-CREATELANGUAGE-PARAMETERS
> 
> [3] Say ... will that unsuppressable warning be written via the vfprintf
>    hook? That would be nice, I could suppress it there then.


From martin.doerr at sap.com  Fri May 28 12:52:18 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 28 May 2021 12:52:18 +0000
Subject: [11u] RFR: 8267599: Revert the change to the default PKCS12
 macAlgorithm and macIterationCount props for 11u/8u/7u
Message-ID: 

Hi,

Oracle has reverted the changes from JDK-8153005 backport in 11.0.12-oracle for interoperability reasons. See:
https://bugs.openjdk.java.net/browse/JDK-8267599
and CSR:
https://bugs.openjdk.java.net/browse/JDK-8267701

I had to adapt the small test addition from JDK-8266293 (see "// 8266293" comment in ParamsPreferences.java):
http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/

Please review.
Comments?

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From chegar at openjdk.java.net  Fri May 28 13:18:19 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 28 May 2021 13:18:19 GMT
Subject: RFR: 8267938: SCTP channel factory methods should check platform
 support
Message-ID: 

The SCTP channel factory methods, namely SctpChannel::open, SctpServerChannel::open, and SctpMultiChannel::open, are specified to throw UnsupportedOperationException, if the SCTP protocol is not supported. Currently, underlying platform support is assumed once the appropriate libsctp.so.1 library is present (along with its supported interface functions). This may not always be the case, e.g. if the Linux sctp kernel module is not present or loaded. In which case a SocketException is thrown.

It would be more appropriate to check for EPROTONOSUPPORT and ESOCKTNOSUPPORT, and throw UOE rather than SE.

The existing java/net/SctpSanity.java tests already covers this case, when run on platforms without support.

-------------

Commit messages:
 - Initial changes

Changes: https://git.openjdk.java.net/jdk/pull/4246/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4246&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267938
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4246.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4246/head:pull/4246

PR: https://git.openjdk.java.net/jdk/pull/4246


From sean.coffey at oracle.com  Fri May 28 13:40:45 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 28 May 2021 14:40:45 +0100
Subject: [11u] RFR: 8267599: Revert the change to the default PKCS12
 macAlgorithm and macIterationCount props for 11u/8u/7u
In-Reply-To: 
References: 
Message-ID: 

Martin,

you seem to be suggesting a full revert of the JDK-8153005 changes. Note 
that the Oracle JDK changes only relate to to the default PKCS12 
macAlgorithm and macIterationCount (back to HmacPBESHA1 and 100000 
respectively). While there are other interoperability concerns with the 
keystore.pkcs12.certProtectionAlgorithm and 
keystore.pkcs12.keyProtectionAlgorithm values [1], they relate to JDK 
8u/7u where PKCS12 is not the default keystore type.

regards,
Sean.

[1] https://bugs.openjdk.java.net/browse/JDK-8267837

On 28/05/2021 13:52, Doerr, Martin wrote:
> Hi,
>
> Oracle has reverted the changes from JDK-8153005 backport in 11.0.12-oracle for interoperability reasons. See:
> https://bugs.openjdk.java.net/browse/JDK-8267599
> and CSR:
> https://bugs.openjdk.java.net/browse/JDK-8267701
>
> I had to adapt the small test addition from JDK-8266293 (see "// 8266293" comment in ParamsPreferences.java):
> http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/
>
> Please review.
> Comments?
>
> Best regards,
> Martin
>


From martin.doerr at sap.com  Fri May 28 14:02:53 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 28 May 2021 14:02:53 +0000
Subject: AW: [11u] RFR: 8267599: Revert the change to the default PKCS12
 macAlgorithm and macIterationCount props for 11u/8u/7u
In-Reply-To: 
References: ,
 
Message-ID: 

Hi Sean,

thank you for your quick reply. I was already hoping to get such feedback.

I had read the CSR and I had already thought that you guys didn?t revert the complete change.
My problem is that I can?t see what exactly you have done.
I?m concerned about making it insecure by creating a mixture of old and new behavior. How can I ensure to get the same behavior as 11.0.12-oracle?
Would it be possible to publish your security file and PKCS12KeyStore.java?
Otherwise, wouldn?t it be safer to stick with the old behavior until we switch to the new one in a future release?

Best regards,
Martin


Von: Se?n Coffey 
Datum: Freitag, 28. Mai 2021 um 15:42
An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev , Hohensee, Paul 
Betreff: Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u
Martin,

you seem to be suggesting a full revert of the JDK-8153005 changes. Note
that the Oracle JDK changes only relate to to the default PKCS12
macAlgorithm and macIterationCount (back to HmacPBESHA1 and 100000
respectively). While there are other interoperability concerns with the
keystore.pkcs12.certProtectionAlgorithm and
keystore.pkcs12.keyProtectionAlgorithm values [1], they relate to JDK
8u/7u where PKCS12 is not the default keystore type.

regards,
Sean.

[1] https://bugs.openjdk.java.net/browse/JDK-8267837

On 28/05/2021 13:52, Doerr, Martin wrote:
> Hi,
>
> Oracle has reverted the changes from JDK-8153005 backport in 11.0.12-oracle for interoperability reasons. See:
> https://bugs.openjdk.java.net/browse/JDK-8267599
> and CSR:
> https://bugs.openjdk.java.net/browse/JDK-8267701
>
> I had to adapt the small test addition from JDK-8266293 (see "// 8266293" comment in ParamsPreferences.java):
> http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/
>
> Please review.
> Comments?
>
> Best regards,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From chap at anastigmatix.net  Fri May 28 14:03:30 2021
From: chap at anastigmatix.net (Chapman Flack)
Date: Fri, 28 May 2021 10:03:30 -0400
Subject: JEP 411: Missing use-case: user functions in an RDBMS
In-Reply-To: 
References: <60B048F9.7090105@anastigmatix.net>
 
Message-ID: <60B0F832.60805@anastigmatix.net>

Hi,

On 05/28/21 06:09, Ron Pressler wrote:
> Before getting into alternatives and the vision for what would be possible
> post-SecurityManager, it would help to explain what the use-case and 
> requirements are.
> 
> When we talk about untrusted code we usually mean code that you believe
> might be malicious and intentionally try to break through any restrictions
> you place on it and attack you by any means, including denial-of-service,
> while trusted code is assumed to not be malicious.
> 
> From what you?ve written I gather that you only intend to run trusted
> ?plugins", but wish to restrict their operations so that they don?t break
> some application invariants and accidentally interfere with its operation.

It seems to me that PostgreSQL's trusted/untrusted distinction (which is
a distinction baked into the core PostgreSQL project and therefore common
to all of the different programming-language supporting extensions like
the Java one that I maintain) is aimed at a sort of intermediate threat
model.

The key consequence of whether a PL is declared to PostgreSQL with or
without the TRUSTED keyword is which database user identities will be
able to CREATE FUNCTION in that language. If it is not declared trusted,
only the database superuser can create functions using it. If it is
declared trusted, the database superuser will be able to GRANT USAGE ON
LANGUAGE ... to other database user identities, and they will then be
able to CREATE FUNCTION in that language.

Here it matters that "database user identities" are usually a pretty small
set. Acme Corp's customers won't all have database logins; they probably
interact with it through a web app that uses its own credentials for a db
connection. The few people with database logins are probably all on Acme
payroll, and relatively trusted. If Acme's DBA has said GRANT USAGE ON
LANGUAGE java TO bob; then probably Bob is not expected to go installing
malicious Java functions. Bob is probably a developer and expected to
apply reasonable skill at writing safe ones.

The functions, once installed, may be /executed/ by a larger number of
database IDs, including possibly via the web apps, so might be executed
with /inputs/ crafted as maliciously as external attackers can dream up.

So I think it might be said (perhaps the core PostgreSQL devs would hold
otherwise) that it's /essential/ for the mechanism to be adequate to
protect against oversights and mistakes in Bob's code or the libraries
he relies on, including mistakes that might be exposed to malicious
external inputs. It's /desirable/ for the mechanism to be robust
against a malicious Bob himself, but I'm not sure how many, if any, of
PostgreSQL's available PLs could be rigorously proven to be so.

> If that is the case, would a ?shallow? sandbox, that restricts which APIs
> are available to the plugin (e.g. only expose special APIs to interact
> with files that go through filtering mechanisms) rather than restrict 
> low-level operations where they ?bottom out? before being passed to the OS, 
> suffice

It's possible a new design in a green field would be able to take that
approach. One thing I should have mentioned, and forgot to, is that there's
an actual ISO standard, ISO 9075-13, SQL Routines and Types Using the
Java? Programming Language, constraining how this stuff has to work.
That's kind of unique among the extension languages; the maintainers of
PL/Python or PL/Ruby, lucky devils, can follow their own visions of what
SQL functions in those languages should look like.

9075-13 certainly doesn't say anything about a limited or special API
that the function will be required to use. That would be a disruptive
change to arbitrary amounts of standard-compliant code. (Naturally, as
the standard was developed back when nobody thought the J2SE security
architecture would be going away, it would have been assumed that the
regular API could be used and permissions would control it.)

That said, it might be about time for working group 3 to convene for
another look at 9075-13; it hasn't been updated in a while, and I don't
think it groks JPMS yet either; user code is treated as classpath code.
The PostgreSQL core team has a rep on that working group, so maybe it
will be possible to plant that idea. I don't think these things move
very quickly.

Still, I think a change as drastic as "you must now change the API you
use to be some different limited version" could be a tough sell.

> While a complex, stack-dependent, deep sandbox *could* be used for plugins,
> permissions that don?t specify what is forbidden but what is allowed
> effectively also severely limit the use of third-party libraries, that
> for example, might want to do benign operations with their own files,

Well, the chief cause of that problem has historically been that the
third-party library devs have been sloppy about getting doPrivileged
where it belongs ... or, to put it more charitably, they haven't been
given any way less cumbersome than doPrivileged to indicate which of
their file operations, for example, are taint-free and which aren't.

This might be the time to think about what a less-cumbersome way to
do /that/ might look like.

Perhaps it might still suffer from less-than-perfect uptake among
library devs, and would still leave app devs having to make some
nuisance permission adjustments (though perhaps with the de-facto
standard policy and permission design going away, there's also an
opportunity to set something up that could deny as well as grant).

I still think it would be highly desirable for the JDK itself to
adopt some such mechanism, if it can be made sufficiently non-cumbersome,
and perhaps limited just to file operations, just as a way to usably
preserve all the vital information that now exists in the code base in
the form of doPrivileged blocks and will inevitably disappear or begin
to rot following this JEP.

That's the information that will make it possible to really say "we're
not providing an enforcement mechanism anymore but one can be practically
developed outside the JDK if it is needed."

Having to make policy adjustments around third-party libraries
might always be an occasional nuisance, but I think it would be a huge
destruction of existing critical information if suddenly that nuisance
became needed for all of the incidental taint-free file operations
inside the JDK itself, when they are, at the moment, properly marked.

Regards,
-Chap


From sean.coffey at oracle.com  Fri May 28 14:30:31 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 28 May 2021 15:30:31 +0100
Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v2]
In-Reply-To: 
References: 
 
 
Message-ID: 

Thanks for the review Valerie. I've gone ahead and updated the test. 
You've a good point in that the PKCS11Test framework didn't suit the 
test that I needed. The new test no longer extends PKCS11Test as a 
result. I have kept the refactoring in PKCS11Test thought since it can 
offer up some useful helper static methods. I did clean up the 
testNSS(..) static methods. You're right that the 2nd Provider parameter 
was redundant. Removed that.

Changes pushed.

regards,
Sean.

On 12/05/2021 19:55, Valerie Peng wrote:
> On Fri, 7 May 2021 13:51:05 GMT, Sean Coffey  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
>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Initial corrections from RFR
> The update changes look good. Will wait for your test edit then.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/3544


From coffeys at openjdk.java.net  Fri May 28 14:31:25 2021
From: coffeys at openjdk.java.net (Sean Coffey)
Date: Fri, 28 May 2021 14:31:25 GMT
Subject: RFR: 8240256: Better resource cleaning for SunPKCS11 Provider [v3]
In-Reply-To: 
References: 
Message-ID: 

> 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 with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - whitespace
 - Further 8240256 test clean up
 - Merge branch 'master' into JDK-8240256-pkcs11
 - Initial corrections from RFR
 - 8240256: Better resource cleaning for SunPKCS11 Provider

-------------

Changes: https://git.openjdk.java.net/jdk/pull/3544/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3544&range=02
  Stats: 574 lines in 11 files changed: 467 ins; 68 del; 39 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


From sean.coffey at oracle.com  Fri May 28 14:35:51 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 28 May 2021 15:35:51 +0100
Subject: [External] : AW: [11u] RFR: 8267599: Revert the change to the
 default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u
In-Reply-To: 
References: 
 
 
Message-ID: 

here are the main changes that we pushed for JDK 11u:

> diff --git a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
> index a62452bdcd..441f2b651e 100644
> --- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
> +++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java
> @@ -101,10 +101,10 @@ public final class PKCS12KeyStore extends KeyStoreSpi {
>               = "PBEWithHmacSHA256AndAES_256";
>       private static final String DEFAULT_KEY_PBE_ALGORITHM
>               = "PBEWithHmacSHA256AndAES_256";
> -    private static final String DEFAULT_MAC_ALGORITHM = "HmacPBESHA256";
> +    private static final String DEFAULT_MAC_ALGORITHM = "HmacPBESHA1";
>       private static final int DEFAULT_CERT_PBE_ITERATION_COUNT = 10000;
>       private static final int DEFAULT_KEY_PBE_ITERATION_COUNT = 10000;
> -    private static final int DEFAULT_MAC_ITERATION_COUNT = 10000;
> +    private static final int DEFAULT_MAC_ITERATION_COUNT = 100000;
>   
>       // Legacy settings. Used when "keystore.pkcs12.legacy" is set.
>       private static final String LEGACY_CERT_PBE_ALGORITHM
> diff --git a/src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security
> index b0c5beccf6..893567071c 100644
> --- a/src/java.base/share/conf/security/java.security
> +++ b/src/java.base/share/conf/security/java.security
> @@ -1200,12 +1200,12 @@ jceks.key.serialFilter = java.base/java.lang.Enum;java.base/java.security.KeyRep
>   # The algorithm used to calculate the optional MacData at the end of a PKCS12
>   # file. This can be any HmacPBE algorithm defined in the Mac section of the
>   # Java Security Standard Algorithm Names Specification. When set to "NONE",
> -# no Mac is generated. The default value is "HmacPBESHA256".
> -#keystore.pkcs12.macAlgorithm = HmacPBESHA256
> +# no Mac is generated. The default value is "HmacPBESHA1".
> +#keystore.pkcs12.macAlgorithm = HmacPBESHA1
>   
>   # The iteration count used by the MacData algorithm. This value must be a
> -# positive integer. The default value is 10000.
> -#keystore.pkcs12.macIterationCount = 10000
> +# positive integer. The default value is 100000.
> +#keystore.pkcs12.macIterationCount = 100000
>   
>   #
>   # Enhanced exception message information

regards,
Sean.

On 28/05/2021 15:02, Doerr, Martin wrote:
>
> Hi Sean,
>
> thank you for your quick reply. I was already hoping to get such feedback.
>
> I had read the CSR and I had already thought that you guys didn?t 
> revert the complete change.
>
> My problem is that I can?t see what exactly you have done.
>
> I?m concerned about making it insecure by creating a mixture of old 
> and new behavior. How can I ensure to get the same behavior as 
> 11.0.12-oracle?
>
> Would it be possible to publish your security file and 
> PKCS12KeyStore.java?
>
> Otherwise, wouldn?t it be safer to stick with the old behavior until 
> we switch to the new one in a future release?
>
> Best regards,
>
> Martin
>
> *Von: *Se?n Coffey 
> *Datum: *Freitag, 28. Mai 2021 um 15:42
> *An: *Doerr, Martin , 
> jdk-updates-dev at openjdk.java.net , 
> security-dev , Hohensee, Paul 
> 
> *Betreff: *Re: [11u] RFR: 8267599: Revert the change to the default 
> PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u
>
> Martin,
>
> you seem to be suggesting a full revert of the JDK-8153005 changes. Note
> that the Oracle JDK changes only relate to to the default PKCS12
> macAlgorithm and macIterationCount (back to HmacPBESHA1 and 100000
> respectively). While there are other interoperability concerns with the
> keystore.pkcs12.certProtectionAlgorithm and
> keystore.pkcs12.keyProtectionAlgorithm values [1], they relate to JDK
> 8u/7u where PKCS12 is not the default keystore type.
>
> regards,
> Sean.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8267837 
> 
>
> On 28/05/2021 13:52, Doerr, Martin wrote:
> > Hi,
> >
> > Oracle has reverted the changes from JDK-8153005 backport in 
> 11.0.12-oracle for interoperability reasons. See:
> > https://bugs.openjdk.java.net/browse/JDK-8267599 
> 
> > and CSR:
> > https://bugs.openjdk.java.net/browse/JDK-8267701 
> 
> >
> > I had to adapt the small test addition from JDK-8266293 (see "// 
> 8266293" comment in ParamsPreferences.java):
> > 
> http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/ 
> 
> >
> > Please review.
> > Comments?
> >
> > Best regards,
> > Martin
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From chap at anastigmatix.net  Fri May 28 14:43:05 2021
From: chap at anastigmatix.net (Chapman Flack)
Date: Fri, 28 May 2021 10:43:05 -0400
Subject: JEP 411: Missing use-case: user functions in an RDBMS
In-Reply-To: <60B0F832.60805@anastigmatix.net>
References: <60B048F9.7090105@anastigmatix.net>
 
 <60B0F832.60805@anastigmatix.net>
Message-ID: <60B10179.4030502@anastigmatix.net>

On 05/28/21 10:03, Chapman Flack wrote:
> I still think it would be highly desirable for the JDK itself to
> adopt some such mechanism, if it can be made sufficiently non-cumbersome,
> and perhaps limited just to file operations

... and Process / ProcessHandle operations ....


I am trying to enumerate, in my head, how many kinds of operations
there really needs to be some API for applying filters to, in a post-SM,
JPMS encapsulated world.

As far as effects a JVM can have on the observable outside world,
there are: native actions (and --enable-native-access), file operations
(and there is -Djava.nio.file.spi.DefaultFileSystemProvider), socket
operations (and there are SocketFactories, though how to set them is
undocumented and might fall victim to JEP 403), and process operations
(how to filter those? only instrumentation?).

Am I missing some?

It seems to me that a lot of the complexity of the permission model
in the pre-JPMS-encapsulation world involved protecting actions that
you might not otherwise care about except that they were all needed
to make "self-protecting managers" possible, without which the manager
could be defeated and then allow actions you'd care about.

If JPMS encapsulation can take over most of that busy-work, does that
perhaps mean the set of JDK operations that an application might
want/need to intercept and filter shrinks down to some concisely-enumerable
set of operations that have external effects?

I am not sure ... thinking aloud.

Regards,
-Chap


From martin.doerr at sap.com  Fri May 28 15:03:20 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 28 May 2021 15:03:20 +0000
Subject: AW: [External] : AW: [11u] RFR: 8267599: Revert the change to the
 default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u
In-Reply-To: 
References: 
 
 ,
 
Message-ID: 

Hi Sean,

thank you very much!

I was concerned to miss anything. But it is really that simple ?
I?ll prepare a new webrev.

Best regards,
Martin


Von: Se?n Coffey 
Datum: Freitag, 28. Mai 2021 um 16:36
An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev , Hohensee, Paul 
Betreff: Re: [External] : AW: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u
here are the main changes that we pushed for JDK 11u:



diff --git a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java

index a62452bdcd..441f2b651e 100644

--- a/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java

+++ b/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java

@@ -101,10 +101,10 @@ public final class PKCS12KeyStore extends KeyStoreSpi {

             = "PBEWithHmacSHA256AndAES_256";

     private static final String DEFAULT_KEY_PBE_ALGORITHM

             = "PBEWithHmacSHA256AndAES_256";

-    private static final String DEFAULT_MAC_ALGORITHM = "HmacPBESHA256";

+    private static final String DEFAULT_MAC_ALGORITHM = "HmacPBESHA1";

     private static final int DEFAULT_CERT_PBE_ITERATION_COUNT = 10000;

     private static final int DEFAULT_KEY_PBE_ITERATION_COUNT = 10000;

-    private static final int DEFAULT_MAC_ITERATION_COUNT = 10000;

+    private static final int DEFAULT_MAC_ITERATION_COUNT = 100000;



     // Legacy settings. Used when "keystore.pkcs12.legacy" is set.

     private static final String LEGACY_CERT_PBE_ALGORITHM

diff --git a/src/java.base/share/conf/security/java.security b/src/java.base/share/conf/security/java.security

index b0c5beccf6..893567071c 100644

--- a/src/java.base/share/conf/security/java.security

+++ b/src/java.base/share/conf/security/java.security

@@ -1200,12 +1200,12 @@ jceks.key.serialFilter = java.base/java.lang.Enum;java.base/java.security.KeyRep

 # The algorithm used to calculate the optional MacData at the end of a PKCS12

 # file. This can be any HmacPBE algorithm defined in the Mac section of the

 # Java Security Standard Algorithm Names Specification. When set to "NONE",

-# no Mac is generated. The default value is "HmacPBESHA256".

-#keystore.pkcs12.macAlgorithm = HmacPBESHA256

+# no Mac is generated. The default value is "HmacPBESHA1".

+#keystore.pkcs12.macAlgorithm = HmacPBESHA1



 # The iteration count used by the MacData algorithm. This value must be a

-# positive integer. The default value is 10000.

-#keystore.pkcs12.macIterationCount = 10000

+# positive integer. The default value is 100000.

+#keystore.pkcs12.macIterationCount = 100000



 #

 # Enhanced exception message information

regards,
Sean.
On 28/05/2021 15:02, Doerr, Martin wrote:
Hi Sean,

thank you for your quick reply. I was already hoping to get such feedback.

I had read the CSR and I had already thought that you guys didn?t revert the complete change.
My problem is that I can?t see what exactly you have done.
I?m concerned about making it insecure by creating a mixture of old and new behavior. How can I ensure to get the same behavior as 11.0.12-oracle?
Would it be possible to publish your security file and PKCS12KeyStore.java?
Otherwise, wouldn?t it be safer to stick with the old behavior until we switch to the new one in a future release?

Best regards,
Martin


Von: Se?n Coffey 
Datum: Freitag, 28. Mai 2021 um 15:42
An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev , Hohensee, Paul 
Betreff: Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u
Martin,

you seem to be suggesting a full revert of the JDK-8153005 changes. Note
that the Oracle JDK changes only relate to to the default PKCS12
macAlgorithm and macIterationCount (back to HmacPBESHA1 and 100000
respectively). While there are other interoperability concerns with the
keystore.pkcs12.certProtectionAlgorithm and
keystore.pkcs12.keyProtectionAlgorithm values [1], they relate to JDK
8u/7u where PKCS12 is not the default keystore type.

regards,
Sean.

[1] https://bugs.openjdk.java.net/browse/JDK-8267837

On 28/05/2021 13:52, Doerr, Martin wrote:
> Hi,
>
> Oracle has reverted the changes from JDK-8153005 backport in 11.0.12-oracle for interoperability reasons. See:
> https://bugs.openjdk.java.net/browse/JDK-8267599
> and CSR:
> https://bugs.openjdk.java.net/browse/JDK-8267701
>
> I had to adapt the small test addition from JDK-8266293 (see "// 8266293" comment in ParamsPreferences.java):
> http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.00/
>
> Please review.
> Comments?
>
> Best regards,
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sean.coffey at oracle.com  Fri May 28 15:32:05 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 28 May 2021 16:32:05 +0100
Subject: (JDK-8266351) Re: [External] : Re: RFR: 8236671: NullPointerException
 in JKS keystore [v2]
In-Reply-To: 
References: 
 
 <3XV3VBENLppWqupCwu5BFLwQ6IK2wOjqY2LZMXzFlJM=.57139075-5af8-4ce8-a302-6ca0aeec2bcf@github.com>
 
 
 
Message-ID: <0ad921e4-2268-22c1-459f-79bb541b15a2@oracle.com>

Thanks for the pointers Will.

I've added your details to the JDK-8266351 bug report.
https://bugs.openjdk.java.net/browse/JDK-8266351

regards,
Sean.

On 24/05/2021 18:53, Will Sargent wrote:
> I have tried to sign up to the bug tracking system (through reset 
> password I think?) but I'm not getting an email out, so I can't add to 
> the bug.
>
> I have created a test case in Github:
>
> https://github.com/wsargent/jca-key-failure/ 
> 
>
> The stack trace shows the invalid key store entry after saving and 
> loading it again.
>
> https://github.com/wsargent/jca-key-failure/blob/main/src/main/java/com/tersesystems/jcakeyfailure/JcaKeyFailure.java#L68 
> 
>
> On Fri, Apr 30, 2021 at 12:40 PM Se?n Coffey  > wrote:
>
>     Thanks for the feedback Will. It would be useful if you can
>     provide a testcase and/or add comments to JDK-8266351
>      on your experience.
>
>     regards,
>     Sean.
>
>     On 30/04/2021 17:54, Will Sargent wrote:
>>     > KeyStore specification will be tightened up via another bug record
>>
>>     This would be super helpful, as one thing that confuses me is
>>     what the relationship is between a key entry and a key alias --
>>     in particular, the existence alias doesn't seem to guarantee a
>>     valid entry that can be retrieved.
>>
>>     In JDK 11 it's possible to create a private key with a keystore
>>     using pkcs12.setKeyEntry() (see link below):
>>
>>     https://github.com/tersesystems/securitybuilder/blob/master/lib/src/test/java/com/tersesystems/securitybuilder/PrivateKeyStoreTest.java#L135
>>     
>>
>>     and then have a null pointer exception when retrieving the entry
>>     from the alias because the certificate chain is null (see
>>     commented out "testSystem" use case):
>>
>>     https://github.com/tersesystems/securitybuilder/blob/master/lib/src/test/java/com/tersesystems/securitybuilder/PrivateKeyStoreTest.java#L27
>>     
>>
>>     I can write this up into a formal bug if that helps.
>>
>>     On Fri, Apr 30, 2021 at 2:30 AM Sean Coffey
>>     > wrote:
>>
>>         On Wed, 28 Apr 2021 12:39:42 GMT, Sean Coffey
>>         > wrote:
>>
>>         >> Trivial enough change. Improved the exception thrown from
>>         JceKeyStore also.
>>         >
>>         > Sean Coffey has updated the pull request with a new target
>>         base due to a merge or a rebase. The incremental webrev
>>         excludes the unrelated changes brought in by the
>>         merge/rebase. The pull request contains four additional
>>         commits since the last revision:
>>         >
>>         >? - Check for null before try block
>>         >? - Merge branch 'master' of https://github.com/openjdk/jdk
>>         
>>         into JDK-8236671-NPE
>>         >? - Fix white space
>>         >? - 8236671: NullPointerException in JKS keystore
>>
>>         KeyStore specification will be tightened up via another bug
>>         record: https://bugs.openjdk.java.net/browse/JDK-8266351
>>         
>>
>>         -------------
>>
>>         PR: https://git.openjdk.java.net/jdk/pull/3588
>>         
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From fguallini at openjdk.java.net  Fri May 28 15:50:23 2021
From: fguallini at openjdk.java.net (Fernando Guallini)
Date: Fri, 28 May 2021 15:50:23 GMT
Subject: RFR: 8180571: Refactor sun/security/pkcs11 shell tests to plain
 java tests and fix failures [v2]
In-Reply-To: 
References: 
Message-ID: 

> Refactor the following shell tests to Java:
> - security/pkcs11/KeyStore/Basic.sh
> - security/pkcs11/KeyStore/ClientAuth.sh
> - security/pkcs11/KeyStore/SecretKeysBasic.sh
> - security/pkcs11/Provider/ConfigQuotedString.sh
> - security/pkcs11/Provider/Login.sh
> - security/pkcs11/Config/ReadConfInUTF16Env.sh
> 
> Currently, most of the shell tests in the list may be ignored during execution time in most platforms since they are incorrectly filtered out by the OS name they are run on. For example, ClientAuth.sh is only run if the OS name is equal to ?Linux?, but OS name may also include the architecture such as ?Linux x86_64?. Those platform constraints are removed in this PR.
> 
> Additionally, further changes are introduced in the following test:
> 
> - ClientAuth: it was failing intermittently because the server side was binding to the wildcard address. The issue is fixed by binding to loopback address instead. Also, Thread.sleep is replaced with CountdownLatch to facilitate synchronization between client and server. Finally, a new ?user1? certificate was generated since the current one has expired.
> 
> - Basic: Remove redundant X509Certificate casting 
> 
> - SecretKeysBasic: it was already in the problem list since it reproduces the open bug JDK-8209398 and fails. Test is refactored to java and still reproduces the issue.
> 
> All the mentioned tests were run many times in multiple platforms to ensure stability

Fernando Guallini has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into 8180571
 - removed tab in comment
 - Merge branch 'master' into 8180571
 - fixed summary in ClientAuth
 - refactor tests
 - refactored shell tests to java

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4092/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4092&range=01
  Stats: 1076 lines in 18 files changed: 195 ins; 820 del; 61 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4092.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4092/head:pull/4092

PR: https://git.openjdk.java.net/jdk/pull/4092


From david.lloyd at redhat.com  Fri May 28 16:08:32 2021
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 28 May 2021 11:08:32 -0500
Subject: JEP 411: Missing use-case: user functions in an RDBMS
In-Reply-To: <60B048F9.7090105@anastigmatix.net>
References: <60B048F9.7090105@anastigmatix.net>
Message-ID: 

On Thu, May 27, 2021 at 8:36 PM Chapman Flack  wrote:

> Hello, I see I am another person relatively late to stumble on this
> "well publicized" JEP. (I am not sure how to recommend the publicity
> could have been better handled, but apparently the avenues that were
> used aren't ones that reached me.)
>
> I maintain, on a volunteer basis, the extension for Java server-side
> functions in the PostgreSQL RDBMS [1].
>

I posted this alternative proposal over on jdk-dev, I suppose I should
have CC'd this list as well. The idea is that maybe the SecurityManager
could stay with enough scaffolding for a third party  (say, your extension)
to be able to use their own stack-based access checker (made practical
thanks to the new-ish StackWalker API).

Anyway here it is:

---------- Forwarded message ---------
From: David Lloyd 
Date: Sat, May 22, 2021 at 9:11 AM
Subject: Re: JEP proposed to target JDK 17: 411: Deprecate the Security
Manager for Removal
To: 
Cc: jdk-dev 



On Fri, May 21, 2021 at 6:04 PM  wrote:

> The following JEP is proposed to target JDK 17:
>
>   411: Deprecate the Security Manager for Removal
>        https://openjdk.java.net/jeps/411


I'm not a committer or reviewer, so perhaps my feedback is unwelcome - but
one can't help but note the amount of heated discussion on this topic, and
the determination of whether or not the problematic points have been
addressed satisfactorily is probably pretty subjective.  I have a bit of
experience in this area, having either designed or having had a major part
of the design of the authentication and authorization APIs presently in use
in WildFly [1], as well as the WildFly security manager [2] (and a
significant number of other security-related APIs), so I thought I'd give
some feedback and also offer a possible compromise.

The security manager defines a variety of behaviors.  Some of these have
clearly been supplanted by other APIs (like getClassContext() vs
StackWalker) or security mechanisms (checkPackageAccess() and friends vs
the new encapsulation protections).  There are also however other APIs on
the security manager which clearly have no replacement.  These include
socket and file access checking APIs, and of course the general permission
check methods.  In addition, the JEP proposes deprecation of the access
controller and policy classes which are the mechanism of stack-based access
checking, and finally unavoidably bumps against JAAS, which itself is a
very difficult and problematic API which also uses the same stack-based
access mechanism (and which we here at Red Hat have for the most part long
since abandoned).

A large part of this deprecated machinery relates to the stack-based access
controller (not to mention, I believe, a nontrivial number of CVEs).  The
idea, of course, was that one can authenticate untrusted or semi-trusted
code.  It is definitely clear through years of experience on all sides
though that one cannot truly rely on this mechanism to protect against
malicious code; it is as easy as an infinite loop to cause massive
undesired CPU usage (and, in this modern $/cpu world, cost) for example.

However, one other undeniably useful function of the security manager is to
authorize basic native operations *not* in the context of what code is
executing, but what person or principal is executing it.  In other words,
the use case of *trusted* code running on behalf of one of many potentially
untrusted users - probably the widest application of server-side Java in
existence today.  It cannot be argued that removing all of the above
security checks does not weaken security of such users, when they could
have a narrower authorization applied to them to limit the possibility of
impact of server exploitation.

On the other hand, the cost of the SecurityManager mechanism as it stands
is undeniably too high; there is absolutely no point in arguing
otherwise, in my view.  Leaving aside the substantial CVE load, the access
controller and policy APIs are very difficult to use correctly by
containers and frameworks, for one thing, and are cumbersome for users as
well.  Many users and frameworks get doPrivileged() wrong, and combining
JAAS subjects into the same mechanism historically doesn't even work
consistently between otherwise-compliant JDK implementations.

What I would propose then is a compromise aimed at maximizing the amount of
value retained and minimizing the amount of cost incurred, by *only*
retaining permission checks that specifically pertain to or are useful for
user authorization, while *also* deprecating (for removal) the existing
problem-prone stack-based access checking mechanism, policy, and security
manager implementation.

Thus I would suggest not deprecating all of SecurityManager, rather just
the following:

* java.lang.SecurityManager#getClassContext - it is replaced by StackWalker
* java.lang.SecurityManager#getSecurityContext
* java.lang.SecurityManager#checkCreateClassLoader
* java.lang.SecurityManager#checkPermission(java.security.Permission,
java.lang.Object) - the overload which accepts a "security context"
* java.lang.SecurityManager#checkPackageAccess
* java.lang.SecurityManager#checkPackageDefinition
* java.lang.SecurityManager#checkSecurityAccess
* java.lang.SecurityManager#getThreadGroup

...as well as their dependent methods and security checks.  These checks
generally pertain to determining whether the application or its frameworks
are trusted to perform certain operations, but are far less useful for user
authorization, as far as I can determine.  I would probably even include
the system property access methods as well - though I saw Peter arguing
that those in particular were useful, I have my doubts, but that could
obviously be worked out.

Further I would recommend the following change: make
java.lang.SecurityManager#checkPermission(java.security.Permission) either
a no-op or throw UnsupportedOperationException.  Ideally, SecurityManager
and checkPermission() would be made abstract (and, for completeness, the
SecurityManager constructor); perhaps after the deprecation period, such a
change could be made.  It's a bit tricky here, because the deprecation
policy doesn't seem to cover the case of making a concrete class or method
abstract.

The remaining proposal would need slight modification in certain ways: for
example, the security manager allow/forbid flags would still make sense and
need to be retained, and the permission checks in socket and file system
code would need to be retained.

After this change, SecurityManager would be decoupled from the stack-based
access controller.  This means that any implementation of authorization
would be the responsibility of third-party libraries.  The remaining JDK
authorization checks would then be easily testable - much more so than
today, because the contract becomes substantially simpler in the absence of
AccessController - and still usable by third party security managers to
perform user authorization checks on these native operations. And, it would
still be possible for third parties to provide stack-based access control
checks using StackWalker for an extra level of security with absolutely
zero additional cost to JDK maintenance (and the burden of coping with the
lack of doPrivileged would reside squarely on the third party).

As for JAAS, nobody would be happier than us to see it just go away, though
that may be beyond the scope of this change.  The proposed scope locals
give what is potentially a very good opportunity to employ a vastly
superior means of propagating security context between tasks.  Under this
proposal, a third-party security manager which uses a scope local security
context for authorization would not only be a useful and measurable
security improvement over an "unsecured" JDK, but would also likely be
substantially more performant (and, if I may say so, reliable) than
anything using JAAS today.  It should even be possible, in the future, to
standardize on a new authentication and authorization identity propagation
API using these mechanisms - at least in Jakarta EE and/or MicroProfile, if
not in the JDK itself.

Essentially what I propose is only slightly departed from the current JEP
411 proposal, by introducing the exception of retaining certain permission
checks and the security manager class itself.

Please give this compromise some consideration. Thanks!

[1] https://github.com/wildfly-security/wildfly-elytron
[2] originally:
https://github.com/wildfly-security/security-manager/blob/master/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java
     - which is now:
https://github.com/wildfly-security/wildfly-elytron/blob/1.x/manager/base/src/main/java/org/wildfly/security/manager/WildFlySecurityManager.java

-- 
- DML ? he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Fri May 28 16:17:33 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 28 May 2021 16:17:33 +0000
Subject: [11u] RFR: 8267599: Revert the change to the default PKCS12
 macAlgorithm and macIterationCount props for 11u/8u/7u
In-Reply-To: 
References: 
 
 ,
 ,
 
Message-ID: 

Hi,

here?s my new webrev for reverting the pkcs12.macAlgorithm and macIterationCount changes from the JDK-8153005 backport:
http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.01/

Oracle?s JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8267599
and CSR:
https://bugs.openjdk.java.net/browse/JDK-8267701

Thanks to Sean for confirming that there?s nothing else to do in the security file and PKCS12KeyStore.java.
So, I only had to adapt the tests.

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sean.coffey at oracle.com  Fri May 28 16:50:54 2021
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 28 May 2021 17:50:54 +0100
Subject: [External] : Re: [11u] RFR: 8267599: Revert the change to the
 default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u
In-Reply-To: 
References: 
 
 
 
 
 
Message-ID: <8a62a00d-f843-5ee4-4b17-2fede01ef703@oracle.com>

Looks good!

regards,
Sean.

On 28/05/2021 17:17, Doerr, Martin wrote:
>
> Hi,
>
> here?s my new webrev for reverting the pkcs12.macAlgorithm and 
> macIterationCount changes from the JDK-8153005 
> backport:
>
> http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.01/ 
> 
>
> Oracle?s JBS issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8267599 
> 
>
> and CSR:
>
> https://bugs.openjdk.java.net/browse/JDK-8267701 
> 
>
> Thanks to Sean for confirming that there?s nothing else to do in the 
> security file and PKCS12KeyStore.java.
>
> So, I only had to adapt the tests.
>
> Please review.
>
> Best regards,
>
> Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From martin.doerr at sap.com  Fri May 28 16:52:22 2021
From: martin.doerr at sap.com (Doerr, Martin)
Date: Fri, 28 May 2021 16:52:22 +0000
Subject: AW: [External] : Re: [11u] RFR: 8267599: Revert the change to the
 default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u
In-Reply-To: <8a62a00d-f843-5ee4-4b17-2fede01ef703@oracle.com>
References: 
 
 
 
 
 ,
 <8a62a00d-f843-5ee4-4b17-2fede01ef703@oracle.com>
Message-ID: 

Thank you, Sean, for your review and all your help!

Best regards,
Martin


Von: Se?n Coffey 
Datum: Freitag, 28. Mai 2021 um 18:51
An: Doerr, Martin , jdk-updates-dev at openjdk.java.net , security-dev , Hohensee, Paul 
Betreff: Re: [External] : Re: [11u] RFR: 8267599: Revert the change to the default PKCS12 macAlgorithm and macIterationCount props for 11u/8u/7u

Looks good!

regards,
Sean.
On 28/05/2021 17:17, Doerr, Martin wrote:
Hi,

here?s my new webrev for reverting the pkcs12.macAlgorithm and macIterationCount changes from the JDK-8153005 backport:
http://cr.openjdk.java.net/~mdoerr/8267599_revert_8153005_11u/webrev.01/

Oracle?s JBS issue:
https://bugs.openjdk.java.net/browse/JDK-8267599
and CSR:
https://bugs.openjdk.java.net/browse/JDK-8267701

Thanks to Sean for confirming that there?s nothing else to do in the security file and PKCS12KeyStore.java.
So, I only had to adapt the tests.

Please review.

Best regards,
Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From valeriep at openjdk.java.net  Fri May 28 20:14:25 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Fri, 28 May 2021 20:14:25 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v8]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 May 2021 20:33:55 GMT, Valerie Peng  wrote:

>> This change updates SunJCE provider as below:
>> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
>> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
>> 
>> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
>> 
>> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
>> 
>> Thanks,
>> Valerie
>
> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review feedbacks

> 
> 
> _Mailing list message from [Michael StJohns](mailto:mstjohns at comcast.net) on [security-dev](mailto:security-dev at mail.openjdk.java.net):_
> 
> Some more general comments - related to the restructuring.
> 
> In AESKeyWrap at 152-155 - that check probably should be moved to W().??
> KWP should do the formatting prior to passing the data to W().? Also at
> 185-187 - move that to W_INV().
> 
> AESKeyWrap at 158 - shouldn't you be returning the cipher text length??
> That's what the comment in FeedbackCipher says.? W() should probably be
> returning the final length.
> 
> The length of the final ciphertext data should be 8 bytes longer than
> the plaintext. decryptFinal() seems to do the right thing by decreasing
> the length returned.?? But again - shouldn't that be the purview of W_INV()?
> 
> The call in KeyWrapCipher.engineGetOutputSize() should probably also be
> passed into KWUtil rather than being? done in KeyWrapCipher.? And the
> more I look at this, the more I think that all of the engineUpdate
> operations should throw UnsupportedOperationException - it would
> certainly simplify the logic.? That would make the call return either?
> inputLength + 8 or inputLength - 8 depending on mode.
> 
> KWUtil.W() - should probably check that in.length >= inLen + 8 and throw
> a ShortBufferException if not.
> 
> Would it be useful to add a comment in KeyWrapCipher that? warns
> maintainers that? AESKeyWrap(Padded).encryptFinal() and decryptFinal()
> uses the input buffer as the output buffer? That's a reasonable approach
> for decryption, but I'm wondering if you might want to support in-place
> encryption as there's no spec prohibition requiring data to be held
> until the encryption is complete.
> 
> Mike
> 
> On 5/24/2021 7:01 PM, Valerie Peng wrote:

Hi Mike,

Thanks for chiming in and review. Please find my comments below:
1) regarding the data length checks in AESKeyWrap/AESKeyWrapPadded class, it's better to check them before formatting the data and passing them to W(). This way, the error message can be clear and fail fast. I added assert statement to W()/W_INV() so the assumption on data sizes are clear.
2) regarding the returned text length of encryptFinal()/decryptFinal() calls, the returned value is correct in that 'ptLen' is the length of the formatted input to W() which contains both the first semiblock and user-supplied data. The name of the variable probably caused the confusion. For better readability, I changed W()/W_INV() to return an int. The javadoc explains what the returned int means. Hope this is clearer now.
3) regarding KWUtil, it's just a state-less class holding utility methods which are used by both AESKeyWrap (KW impl) and AESKeyWrapPadded (KWP impl). So I don't see why it should handle engineGetOutputSize() calls.
4) as for engineUpdate(...) throwing UnsupportedOperationException, I see the point that you are trying to make. Currently we are bound by the Cipher/CipherSpi javadoc spec. Another concern is that existing apps which are using multi-part enc/dec, may be caught off guard with this. So, that's how it is.

I need to do a system update and will get to your other comments once it's finished.
Thanks,
Valerie

-------------

PR: https://git.openjdk.java.net/jdk/pull/2404


From peter.firmstone at zeus.net.au  Fri May 28 22:03:41 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sat, 29 May 2021 08:03:41 +1000
Subject: JEP 411: Missing use-case: user functions in an RDBMS
In-Reply-To: 
References: <60B048F9.7090105@anastigmatix.net>
 
Message-ID: <3c24236f-40c9-ebbd-4d11-291ba778a0aa@zeus.net.au>

While I accept that my particular use case will no longer be supported 
in future, it's difficult to see the value of a sandbox, because 
developers will always want to relax it in some way and people fall into 
the trap of thinking that trust is black and white; this is trusted, 
that is not.

Nowadays, there's a lot more interest in the Principle of Least 
Privilege, especially in health care regulations, now I'm going to use 
the meaning implied in "Inside Java 2 Platform Security, Second 
Edition", so that we aren't arguing whether that applies with the JVM or 
external to it.

The reason POLP is simpler, is that it can be automated with tooling, 
then the development / deployment team may choose to relax it, they can 
certainly test it and validate it.?? Then we are simply focused on what 
we need to do, rather than what we might want to restrict, which is 
always unknown and subject to change.

The problem is that this is not how developers have been taught to use 
SecurityManager, instead they are told that trusted code can be given 
AllPermission because it's trusted and that's an approach which has 
proven largely ineffective and the OpenJDK development team carry's the 
cost as a result, with little benefit.

I just thought I'd provide you with a different perspective, so 
hopefully the mistake isn't repeated.

Peter.

On 28/05/2021 8:09 pm, Ron Pressler wrote:
>
> Deep sandboxes, simple or stack-dependent, are useful for very ?rich? code,
> that is potentially very big and possibly contains arbitrary third-party
> libraries, while shallow sandboxes are more suitable to limited plugins.
>
> While a complex, stack-dependent, deep sandbox *could* be used for plugins,
> permissions that don?t specify what is forbidden but what is allowed
> effectively also severely limit the use of third-party libraries, that
> for example, might want to do benign operations with their own files,
> and so effectively only allow very limited plugins. The result is a costly
> mechanism that is overkill for what it?s used for.
>
> ? Ron



From peter.firmstone at zeus.net.au  Sat May 29 23:22:00 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 30 May 2021 09:22:00 +1000
Subject: JEP: 411 How JGDMS utilises the Java platform
Message-ID: <61549a8d-59dd-7162-9d15-8c60792bf92c@zeus.net.au>

This is provided as information only I'm not looking for arguments, 
debate or even requesting functionality, I'm just documenting what JGDMS 
does now, unfortunately JGDMS appears to be too entangled with current 
security API's at its foundations to be easily migrated, I guess that 
will depend on the new API's, but it might provide some insights into 
the next security architecture's design.? My fear is this JEP is focused 
on removal, more than replacement.

There is no limit on the number of nodes that may participate, nor the 
number of principals.

JGDMS is a service based architecture, these services are discovered 
dynamically, I'm not going to go into the details of discovery here, but 
instead to focus on the architecture of the service and its components.

Firstly while the service itself is a "Server - Client" model, the JVM's 
or compute nodes are peer to peer and doesn't directly translate to a 
distinction between server and client compute nodes, Swing is supported 
for graphical API's, it would also be possible to use JavaFX also 
(untested).

When a node wants to participate, it discovers lookup services, that 
belong to particular groups, these lookup services contain services 
available, the node may register services with these lookup services, 
and it may search for other services and utilise them.

So back to focusing on the Service:

Below is a diagram of a service in a modular environment, where Bundle 
is an OSGi module, but it could also be a JPMS module (future version) 
for arguments sake.? Here the COM link is a remote invocation protocol, 
but may be any of a number of protocols, the protocol can be replaced 
without modification to the service implementation via configuration.? 
It is possible make use of, but doesn't require RMI or Java 
Serialization, any number of protocols may be used.? These are Remote 
Invocation protocols. The most commonly used communication protocol is 
called JERI, or Jini Extensible Remote Invocation,? JGDMS provides a 
JERI implementation with an Atomic Invocation Layer, where it supports 
failure atomicity.

Unlike RMI, Atomic JERI assigns ClassLoader's at each endpoint for class 
resolution and it doesn't append CodeSource URL's into the stream.

Before the Client JVM can load the Proxy Bundle, it must first designate 
a ClassLoader, this ClassLoader has an identity, which is made up of, 
RFC3986 URI CodeSource's, The Servers Endpoint identity (which includes 
the servers IPv6 address and the security constraints made) and the type 
of connection used (eg TLS, or Kerberos).

Permissions are granted statically using POLP, statically by policy 
files (or remote policy services) to each ProtectionDomain, based on 
CodeSource and Principals,? and dynamically to the ClassLoader of the 
ProxyBundle in the Client JVM, following server and client authentication.

Different services may even use the same CodeSource, however their 
classes are loaded by different ClassLoader's based on the Server's 
identity and security constraints.

So while OpenJDK devs claim the ProtectionDomains on the stack represent 
Code and Principles, we use it to represent the difference services on 
the call stack, not code.

In our case spawning hundreds of processes to manage the permissions of 
each service used by a client isn't practical.

I hope this helps people understand how we are using Java, this is only 
scratching the service, we are not the only ones who do this, I am aware 
of companies and military, who use POLP also.

|SERVER JVM ============================================================ 
______________ | | | Service | | API Bundle | |______________| | | 
Imports API Packages | | ____________________ ______|_______ | | Imports 
packages | | | Service Bundle |<--------------------| Proxy Bundle 
|--SEP | Implements | from proxy |______________| | | Proxy API | | 
|____________________| | | 
============================================================ | | | | C O 
CLIENT JVM M 
============================================================ | L 
____________________ ______________ I | | | | N | Distribution | Imports 
packages | Service | K | Provider |<--------------------| API Bundle | | 
| Discovers & | from API |______________| | | Registers service | | | 
|____________________| | | Imports | API | Packages | | | | | 
______|_______ | | | | | Proxy Bundle |---EP |______________| 
============================================================ |

-- 
Regards,
  
Peter Firmstone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From peter.firmstone at zeus.net.au  Sun May 30 01:15:54 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 30 May 2021 11:15:54 +1000
Subject: JEP: 411 How JGDMS utilises the Java platform
In-Reply-To: <61549a8d-59dd-7162-9d15-8c60792bf92c@zeus.net.au>
References: <61549a8d-59dd-7162-9d15-8c60792bf92c@zeus.net.au>
Message-ID: 

Something else that JERI does that RMI doesn't is transfer the Subject 
from a calling thread in one JVM to the thread invoked in another JVM, 
so you have user principles, and service principles mixing in numerous 
JVM, all while only granting the minimal permissions required to perform 
role / task.

On 30/05/2021 9:22 am, Peter Firmstone wrote:
>
> This is provided as information only I'm not looking for arguments, 
> debate or even requesting functionality, I'm just documenting what 
> JGDMS does now, unfortunately JGDMS appears to be too entangled with 
> current security API's at its foundations to be easily migrated, I 
> guess that will depend on the new API's, but it might provide some 
> insights into the next security architecture's design.? My fear is 
> this JEP is focused on removal, more than replacement.
>
> There is no limit on the number of nodes that may participate, nor the 
> number of principals.
>
> JGDMS is a service based architecture, these services are discovered 
> dynamically, I'm not going to go into the details of discovery here, 
> but instead to focus on the architecture of the service and its 
> components.
>
> Firstly while the service itself is a "Server - Client" model, the 
> JVM's or compute nodes are peer to peer and doesn't directly translate 
> to a distinction between server and client compute nodes, Swing is 
> supported for graphical API's, it would also be possible to use JavaFX 
> also (untested).
>
> When a node wants to participate, it discovers lookup services, that 
> belong to particular groups, these lookup services contain services 
> available, the node may register services with these lookup services, 
> and it may search for other services and utilise them.
>
> So back to focusing on the Service:
>
> Below is a diagram of a service in a modular environment, where Bundle 
> is an OSGi module, but it could also be a JPMS module (future version) 
> for arguments sake.? Here the COM link is a remote invocation 
> protocol, but may be any of a number of protocols, the protocol can be 
> replaced without modification to the service implementation via 
> configuration.? It is possible make use of, but doesn't require RMI or 
> Java Serialization, any number of protocols may be used.? These are 
> Remote Invocation protocols.? The most commonly used communication 
> protocol is called JERI, or Jini Extensible Remote Invocation,? JGDMS 
> provides a JERI implementation with an Atomic Invocation Layer, where 
> it supports failure atomicity.
>
> Unlike RMI, Atomic JERI assigns ClassLoader's at each endpoint for 
> class resolution and it doesn't append CodeSource URL's into the stream.
>
> Before the Client JVM can load the Proxy Bundle, it must first 
> designate a ClassLoader, this ClassLoader has an identity, which is 
> made up of, RFC3986 URI CodeSource's, The Servers Endpoint identity 
> (which includes the servers IPv6 address and the security constraints 
> made) and the type of connection used (eg TLS, or Kerberos).
>
> Permissions are granted statically using POLP, statically by policy 
> files (or remote policy services) to each ProtectionDomain, based on 
> CodeSource and Principals,? and dynamically to the ClassLoader of the 
> ProxyBundle in the Client JVM, following server and client authentication.
>
> Different services may even use the same CodeSource, however their 
> classes are loaded by different ClassLoader's based on the Server's 
> identity and security constraints.
>
> So while OpenJDK devs claim the ProtectionDomains on the stack 
> represent Code and Principles, we use it to represent the difference 
> services on the call stack, not code.
>
> In our case spawning hundreds of processes to manage the permissions 
> of each service used by a client isn't practical.
>
> I hope this helps people understand how we are using Java, this is 
> only scratching the service, we are not the only ones who do this, I 
> am aware of companies and military, who use POLP also.
>
> |SERVER JVM 
> ============================================================ 
> ______________ | | | Service | | API Bundle | |______________| | | 
> Imports API Packages | | ____________________ ______|_______ | | 
> Imports packages | | | Service Bundle |<--------------------| Proxy 
> Bundle |--SEP | Implements | from proxy |______________| | | Proxy API 
> | | |____________________| | | 
> ============================================================ | | | | C 
> O CLIENT JVM M 
> ============================================================ | L 
> ____________________ ______________ I | | | | N | Distribution | 
> Imports packages | Service | K | Provider |<--------------------| API 
> Bundle | | | Discovers & | from API |______________| | | Registers 
> service | | | |____________________| | | Imports | API | Packages | | 
> | | | ______|_______ | | | | | Proxy Bundle |---EP |______________| 
> ============================================================ |
> -- 
> Regards,
>   
> Peter Firmstone

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From valeriep at openjdk.java.net  Sun May 30 07:25:54 2021
From: valeriep at openjdk.java.net (Valerie Peng)
Date: Sun, 30 May 2021 07:25:54 GMT
Subject: RFR: 8248268: Support KWP in addition to KW [v9]
In-Reply-To: 
References: 
Message-ID: 

> This change updates SunJCE provider as below:
> - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. 
> - added support for AES/KWP/NoPadding and AES/KW/PKCS5Padding.
> 
> Existing AESWrap impl, i.e. AESWrapCipher class, is re-factored and renamed to KeyWrapCipher class. The W and W_inverse functions are moved to KWUtil class. The KW and KWP support are in the new AESKeyWrap and AESKeyWrapPadded classes which extend FeedbackCipher and used in KeyWrapCipher class. To minimize data copying, AESKeyWrap and AESKeyWrapPadded will do the crypto operation over the same input buffer which is allocated and managed by KeyWrapCipher class. 
> 
> Also note that existing AESWrap impl does not take IV. However, the corresponding PKCS#11 mechanisms do, so I added support for accepting IVs to both KW and KWP.
> 
> Thanks,
> Valerie

Valerie Peng has updated the pull request incrementally with one additional commit since the last revision:

  Update to address review feedbacks and minor optimizations.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2404/files
  - new: https://git.openjdk.java.net/jdk/pull/2404/files/77566a82..cfe66d54

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2404&range=07-08

  Stats: 168 lines in 4 files changed: 60 ins; 19 del; 89 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2404.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2404/head:pull/2404

PR: https://git.openjdk.java.net/jdk/pull/2404


From prr at openjdk.java.net  Sun May 30 17:44:23 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 30 May 2021 17:44:23 GMT
Subject: RFR: 8267521: Post JEP 411 refactoring: maximum covering > 50K
 [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang  wrote:

>> The code change refactors classes that have a `SuppressWarnings("removal")` annotation that covers more than 50KB of code. The big annotation is often quite faraway from the actual deprecated API usage it is suppressing, and with the annotation covering too big a portion it's easy to call other deprecated methods without being noticed.
>> 
>> The code change shows some common solutions to avoid such too wide annotations:
>> 
>> 1. Extract calls into a method and add annotation on that method
>> 2. Assign the return value of a deprecated method call to a new local variable and add annotation on the declaration, and then assign that value to the original l-value if not void. The local variable will be called `tmp` if later reassigned or `dummy` if it will be discarded.
>> 3. Put declaration and assignment into a single statement if possible.
>> 4. Rewrite code to achieve #3 above.
>> 
>> I'll add a copyright year update commit before integration.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update FtpClient.java

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4138


From tvaleev at openjdk.java.net  Mon May 31 03:44:32 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 31 May 2021 03:44:32 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v6]
In-Reply-To: 
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
 
 
Message-ID: <9TPuteZ19ff8QThVw9ABT1rkUXDBscW6RYLC8whOwUE=.d179dd55-5d88-4946-8088-cf34aa4ed241@github.com>

On Thu, 27 May 2021 13:47:16 GMT, Daniel Fuchs  wrote:

>> Tagir F. Valeev 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.
>
> src/java.base/share/classes/java/util/concurrent/FutureTask.java line 495:
> 
>> 493:      * @return a string representation of this FutureTask
>> 494:      */
>> 495:     public String toString() {
> 
> Classes in java.util.concurrent are handled upstream. It would probably be better to leave them out of this patch. Or synchronize with @DougLea to see how to bring these changes in the upstream repo.

I rolled back changes in java.util.concurrent. Also, rebased the branch due to conflicts in JapaneseImperialCalendar.java

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From tvaleev at openjdk.java.net  Mon May 31 03:44:31 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 31 May 2021 03:44:31 GMT
Subject: RFR: 8267587: Update java.util to use enhanced switch [v7]
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

Tagir F. Valeev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Rollback changes in j.u.concurrent (including formatting)
 - Rollback changes in j.u.concurrent
 - JapaneseImperialCalendar: use switch expressions
 - Use yield in java.util.Calendar.Builder.build
 - More vertical alignment
 - Vertical alignment for single-line switch rules
 - Indent some lines to make GitHub diff happier
 - Unindent switch cases to simplify the review
 - 8267587: Update java.util to use enhanced switch

-------------

Changes: https://git.openjdk.java.net/jdk/pull/4161/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4161&range=06
  Stats: 884 lines in 15 files changed: 108 ins; 328 del; 448 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4161.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4161/head:pull/4161

PR: https://git.openjdk.java.net/jdk/pull/4161


From harshad.rj at gmail.com  Mon May 31 06:21:37 2021
From: harshad.rj at gmail.com (Harshad RJ)
Date: Mon, 31 May 2021 11:51:37 +0530
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
Message-ID: 

> In reply to Ron Pressier:
> Do you regularly use the Security Manager to sandbox your own dependencies and find it convenient and effective
> ? in which case, could you please describe your practice concretely so that it would be possible to consider
> alternatives ? or are you saying that you can *envision* such a powerful use-case? The desire to remove the
> Security Manager does not stem from its theoretical utility, which is absolutely amazing, but from its practical
> utility, which years of experience have found to be less than amazing after all, and probably too low to justify
> its burdensome cost.

# Practical example of SecurityManager use
We are developing a security and privacy conscious browser in pure Java:
https://gngr.info

`gngr` uses `SecurityManager` at its core to not only sandbox external
libraries but also *internal modules*!

# External Libraries we use
* `Rhino` for Javascript
* `jStyleParser` for CSS parsing and analysing
* `okhttp` for HTTP/2 support (before the Java11 HTTP client was available)

These are huge libraries that are practically impossible to audit by a
small team, but through the SecurityManager we
were able to identify the following issues very easily:

## Security issues discovered so far
* Network access by the CSS parser library:
https://github.com/radkovo/jStyleParser/issues/14

* Use of reflection to make a private method accessible
https://github.com/square/okhttp/issues/3426

# Trust, but verify
We don't use `SecurityManager` because we don't trust the external
library authors; we do trust them else we wouldn't
be using those libraries! And given that these are popular projects,
we can also bank on oversight from the community
at large.

But what if we could also verify this trust and other assumptions, for
very little overhead? The SecurityManager does
require initial time investment, but IMO the returns justify it.

A good example of trust but verify, is our own internal modules. We
obviously trust our own code, yet we sandbox it,
to be sure that our assumptions are correct. For example, the `Cookie`
module inside the browser only needs File
access, in order to persist the cookies. Having it sandboxed relieves
us from worrying about some bug or debug code
mistakenly accessing the internet or any of the other myriad
capabilities that the code has access to.

# Numbers are misleading
One argument I have seen in support of JEP 411 is that there are very
few projects that use the SecurityManager. But
this outcome seems natural to me:
1. Many users and developers are not aware of Security threats, or
don't give enough priority to them.
2. The SecurityManager is hard to setup.

I expect #1 to change over a period of time, as more data gets
breached and more people learn from this experience.

#2 could be solved with better documentation, tutorials, etc. Or
through development of an alternative API.

(Imagine if WeakReferences were removed from the JVM because they were
not used by many projects! Of course, they won't
be used by many projects because they are not relevant to most of
them. However, for the projects that do use them, they
are very essential.)

# Logging events violates POLP
The alternative of using logging, with JFR for example, might be
suitable for certain use-cases, but is not a general
replacement for the protections provided by SecurityManager.

For one, it might not be possible to exercise all code-paths in tests.
Hence, the events made during testing might be
a subset of the actual behavior in production.

Secondly, it is not possible to know all events that need to be
captured in advance. Using a SecurityManager allows
us to follow a whitelisting policy, which is practical because the
white list is finite.

However, the alternative of logging events requires us to list all
possible capabilities in advance, which is impossible,
as the capabilities provided by the JVM or the standard library might
grow in a future version.

Thirdly, using Java agents with bytecode manipulation, as suggested on
this list, doesn't seem any easier than using
the SecurityManager.

best,
-- 
Harshad RJ


From peter.firmstone at zeus.net.au  Mon May 31 07:11:41 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Mon, 31 May 2021 17:11:41 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
Message-ID: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au>

Hmm, whitelisting, you're using the principle of least privilege too then.

We have multiple SecurityManager and Policy implementations.

Our policy implementations can decorate each other with different 
functionality, including dynamic permissions and permissions granted by 
a permission service remotely, they have an interface to bubble up 
immutable data, so they can share immutable state.

The implementation code that ships with Java is like a model T Ford, 
ours is Formula 1, concurrent and non blocking, it's also very 
performant, we use bit shift operations, for string normalization, we've 
got RFC 3986 URI normalization and RFC 5982 IPv6 normalization , Java's 
implementation code makes network calls to DNS.? There just is no 
comparison there at all.? We use a comparator to order the permissions 
into their most performant order and it doesn't call equals or hashcode 
as that can cause a DNS call.

I believe we do achieve it's theoretical utility and I don't know that I 
would call it absolutely amazing, but it gets out of the way and just 
does what's is supposed to reliably, without impacting performance.? But 
now OpenJDK wants to rip the rug out from underneath us, because it's 
causing problems with loom or some other projects.? Could you just make 
the AccessControlContext immutable for loom threads??? We might say, ok 
I need a few minimal permissions for this AccessControlContext, give it 
one ProtectionDomain with a Subject and static Permissions, so it 
doesn't consult the policy, that AccessControlContext is immutable.? Get 
rid of the locks in PermissionCollection and make them immutable with a 
builder.?? We create PermissionCollection on demand and discard their 
reference for the garbage collection, we don't actually share 
PermissionCollection instances.

I think also that many more people are using SecurityManager than 
OpenJDK realises, and they're not using it how OpenJDK recommends 
either, (AllPermission granted to trusted code, and sandbox untrusted 
code model of Applets is not how we use it) people are using POLP, it's 
just that no one reports back to OpenJDK because they are only editing 
policy files, it will work with any library out there now, there's 
nothing to write back about.? It's pretty clear that OpenJDK devs don't 
use it, but they do have to manage doPrivileged and preserving context 
across tasks and threads.

And there are static analysis tools in Spotbugs to identify doPrivileged 
bugs, but someone has recently suggested removing them thanks to this 
JEP?? Does OpenJDK use static analysis.? I think if you did you'd find 
plenty of latent bugs.

The Java implementations do impact performance, although I believe this 
has improved with the module system, which uses a URN instead of a URL 
for codesources, I haven't looked at the jrt URL handler impl.

Regards,

Peter.

On 31/05/2021 4:21 pm, Harshad RJ wrote:
>> In reply to Ron Pressier:
>> Do you regularly use the Security Manager to sandbox your own dependencies and find it convenient and effective
>> ? in which case, could you please describe your practice concretely so that it would be possible to consider
>> alternatives ? or are you saying that you can *envision* such a powerful use-case? The desire to remove the
>> Security Manager does not stem from its theoretical utility, which is absolutely amazing, but from its practical
>> utility, which years of experience have found to be less than amazing after all, and probably too low to justify
>> its burdensome cost.
> # Practical example of SecurityManager use
> We are developing a security and privacy conscious browser in pure Java:
> https://gngr.info
>
> `gngr` uses `SecurityManager` at its core to not only sandbox external
> libraries but also *internal modules*!
>
> # External Libraries we use
> * `Rhino` for Javascript
> * `jStyleParser` for CSS parsing and analysing
> * `okhttp` for HTTP/2 support (before the Java11 HTTP client was available)
>
> These are huge libraries that are practically impossible to audit by a
> small team, but through the SecurityManager we
> were able to identify the following issues very easily:
>
> ## Security issues discovered so far
> * Network access by the CSS parser library:
> https://github.com/radkovo/jStyleParser/issues/14
>
> * Use of reflection to make a private method accessible
> https://github.com/square/okhttp/issues/3426
>
> # Trust, but verify
> We don't use `SecurityManager` because we don't trust the external
> library authors; we do trust them else we wouldn't
> be using those libraries! And given that these are popular projects,
> we can also bank on oversight from the community
> at large.
>
> But what if we could also verify this trust and other assumptions, for
> very little overhead? The SecurityManager does
> require initial time investment, but IMO the returns justify it.
>
> A good example of trust but verify, is our own internal modules. We
> obviously trust our own code, yet we sandbox it,
> to be sure that our assumptions are correct. For example, the `Cookie`
> module inside the browser only needs File
> access, in order to persist the cookies. Having it sandboxed relieves
> us from worrying about some bug or debug code
> mistakenly accessing the internet or any of the other myriad
> capabilities that the code has access to.
>
> # Numbers are misleading
> One argument I have seen in support of JEP 411 is that there are very
> few projects that use the SecurityManager. But
> this outcome seems natural to me:
> 1. Many users and developers are not aware of Security threats, or
> don't give enough priority to them.
> 2. The SecurityManager is hard to setup.
>
> I expect #1 to change over a period of time, as more data gets
> breached and more people learn from this experience.
>
> #2 could be solved with better documentation, tutorials, etc. Or
> through development of an alternative API.
>
> (Imagine if WeakReferences were removed from the JVM because they were
> not used by many projects! Of course, they won't
> be used by many projects because they are not relevant to most of
> them. However, for the projects that do use them, they
> are very essential.)
>
> # Logging events violates POLP
> The alternative of using logging, with JFR for example, might be
> suitable for certain use-cases, but is not a general
> replacement for the protections provided by SecurityManager.
>
> For one, it might not be possible to exercise all code-paths in tests.
> Hence, the events made during testing might be
> a subset of the actual behavior in production.
>
> Secondly, it is not possible to know all events that need to be
> captured in advance. Using a SecurityManager allows
> us to follow a whitelisting policy, which is practical because the
> white list is finite.
>
> However, the alternative of logging events requires us to list all
> possible capabilities in advance, which is impossible,
> as the capabilities provided by the JVM or the standard library might
> grow in a future version.
>
> Thirdly, using Java agents with bytecode manipulation, as suggested on
> this list, doesn't seem any easier than using
> the SecurityManager.
>
> best,


From Alan.Bateman at oracle.com  Mon May 31 07:59:26 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 31 May 2021 08:59:26 +0100
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au>
References: 
 <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au>
Message-ID: 

On 31/05/2021 08:11, Peter Firmstone wrote:
> :
>
> I think also that many more people are using SecurityManager than 
> OpenJDK realises, and they're not using it how OpenJDK recommends 
> either, (AllPermission granted to trusted code, and sandbox untrusted 
> code model of Applets is not how we use it) people are using POLP, 
> it's just that no one reports back to OpenJDK because they are only 
> editing policy files, it will work with any library out there now, 
> there's nothing to write back about.? It's pretty clear that OpenJDK 
> devs don't use it, but they do have to manage doPrivileged and 
> preserving context across tasks and threads.
>
> And there are static analysis tools in Spotbugs to identify 
> doPrivileged bugs, but someone has recently suggested removing them 
> thanks to this JEP?? Does OpenJDK use static analysis.? I think if you 
> did you'd find plenty of latent bugs.

I don't think the SM is approachable by most developers. I've sat 
through several embarrassing sessions at conferences over the years 
where a speaker attempted to get something non-trivial to work with the 
SM enabled. More often than not they had to deal with libraries that had 
never been run with a SM before and it was whack-a-mole to get them to 
run. As you know, any library or framework with callbacks means careful 
use of doPrivileged to avoid needing to grant permissions to every 
component on the stack. You mention capturing and re-asserting contexts 
across threads, this is just way too complex for most developers. My 
guess is that if we had enabled the SM by default 20 years ago then it 
would be a different discussion today. This is not to say that there 
isn't some usage, the flurry of mails here over the last month does show 
that there is some usage. The SM survey in 2018 showed that there was 
some usage too.

I can't speak for all OpenJDK contributors but Oracle contributors do a 
massive amount of analysis and static analysis before proposing to 
deprecate or removing anything. It's often much harder to remove 
something that add it and I don't think anyone has proposed deprecating 
or removing anything without a strong case.

-Alan









From tvaleev at openjdk.java.net  Mon May 31 08:52:23 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 31 May 2021 08:52:23 GMT
Subject: Integrated: 8267587: Update java.util to use enhanced switch
In-Reply-To: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
References: <2jDwFkwCe-hXFGw7mNYj1c_9vkDBA0piPpeQPbVINSI=.16c9fbf3-3390-4e3d-948b-0b403998608f@github.com>
Message-ID: 

On Mon, 24 May 2021 04:20:23 GMT, Tagir F. Valeev  wrote:

> Inspired by PR#4088. Most of the changes are done automatically using IntelliJ IDEA refactoring. Some manual adjustments are also performed, including indentations, moving comments, extracting common cast out of switch expression branches, etc.
> 
> I also noticed that there are some switches having one branch only in JapaneseImperialCalendar.java. Probably it would be better to replace them with `if` statement?

This pull request has now been integrated.

Changeset: ab5a7ff2
Author:    Tagir F. Valeev 
URL:       https://git.openjdk.java.net/jdk/commit/ab5a7ff2304dd4cb069ae2bbd6fdd99b3de7a6a3
Stats:     884 lines in 15 files changed: 108 ins; 328 del; 448 mod

8267587: Update java.util to use enhanced switch

Reviewed-by: iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/4161


From peter.firmstone at zeus.net.au  Mon May 31 09:56:26 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Mon, 31 May 2021 19:56:26 +1000
Subject: JEP411: Missing use-case: Monitoring / restricting libraries
In-Reply-To: 
References: 
 <35ac4a33-1bfb-16f2-232e-65ca7a1a08c3@zeus.net.au>
 
Message-ID: <8d1db309-5c3c-1475-d063-7539c45ef974@zeus.net.au>

Thanks Alan,

Concurrency is difficult too, but Java has gone a long way to addressing 
this with concurrency libraries that make the task seem like child's 
play, compared to using Java 1.4 language constructs.

On 31/05/2021 5:59 pm, Alan Bateman wrote:
> On 31/05/2021 08:11, Peter Firmstone wrote:
>> :
>>
>> I think also that many more people are using SecurityManager than 
>> OpenJDK realises, and they're not using it how OpenJDK recommends 
>> either, (AllPermission granted to trusted code, and sandbox untrusted 
>> code model of Applets is not how we use it) people are using POLP, 
>> it's just that no one reports back to OpenJDK because they are only 
>> editing policy files, it will work with any library out there now, 
>> there's nothing to write back about.? It's pretty clear that OpenJDK 
>> devs don't use it, but they do have to manage doPrivileged and 
>> preserving context across tasks and threads.
>>
>> And there are static analysis tools in Spotbugs to identify 
>> doPrivileged bugs, but someone has recently suggested removing them 
>> thanks to this JEP?? Does OpenJDK use static analysis.? I think if 
>> you did you'd find plenty of latent bugs.
>
> I don't think the SM is approachable by most developers. I've sat 
> through several embarrassing sessions at conferences over the years 
> where a speaker attempted to get something non-trivial to work with 
> the SM enabled. More often than not they had to deal with libraries 
> that had never been run with a SM before and it was whack-a-mole to 
> get them to run. 


Yes, it shouldn't have been allowed out the door without a tool for that 
reason, it could have been avoided.??? Yes, I have a tool that sorts 
that very problem, it's 500 - 600 lines of code. Just specify two 
command line arguments which are the security manager and policy file 
location, it generates the policy file, then you look at the file 
briefly, alter some permissions like network for ephemeral ports, easy, 
you now have a POLP policy file.?? You do need to properly run the 
program through its use cases however, but testing is often sufficient, 
even if you don't have full test coverage it will capture 99.9% of 
permissions required, then if you tests are missing a permission, it 
indicates insufficient test coverage.? The tool will also append, so you 
can run multiple processes and user roles one after the other.

I will rewrite it in GPL2.0 if you ask me to.? The only reason I didn't 
get around to it before was it's AL2.0 and there wasn't an existential 
threat to SecurityManager API's.

> As you know, any library or framework with callbacks means careful use 
> of doPrivileged to avoid needing to grant permissions to every 
> component on the stack. You mention capturing and re-asserting 
> contexts across threads, this is just way too complex for most 
> developers. My guess is that if we had enabled the SM by default 20 
> years ago then it would be a different discussion today. This is not 
> to say that there isn't some usage, the flurry of mails here over the 
> last month does show that there is some usage. The SM survey in 2018 
> showed that there was some usage too.


Yes, so how do we start that process?? It doesn't matter if we start it 
now or 20 years ago, as long as when it does happen the outcome is 
positive, I have been coming across more and more developers who 
implement POLP or that want to.?? Executors has two methods which 
decorate Runnable and Callable, but they could be placed into the 
Executors and performed automatically when tasks are submitted, when 
SecurityManager is installed.

We could give developers a choice, so loom threads are zero privileged 
by default? or are treated as doPrivileged calls with the Subject of the 
creator, so it only has one ProtectionDomain and load it with immutable 
collections of permissions, then we can use them for TLS connections if 
we want or leave them unprivileged.?? It's a fair compromise, just make 
sure the callers domain has minimal privileges.? It seems to me that 
loom would be very good for blocking IO.? It only needs to be 
documented, then we will use it appropriately.

In my SecurityManager implementation, once an AccessControlContext has 
been checked for a Permission, it is only ever checked again if the 
policy is refreshed, so it's a once off which has little impact in an 
Executor pool.? It uses concurrent collections that are decorated with 
weak references, to avoid memory leaks.


>
> I can't speak for all OpenJDK contributors but Oracle contributors do 
> a massive amount of analysis and static analysis before proposing to 
> deprecate or removing anything. It's often much harder to remove 
> something that add it and I don't think anyone has proposed 
> deprecating or removing anything without a strong case.
>
> -Alan
>
>

I understand, but this is incredibly useful software when POLP is 
applied and if promoted properly with good tooling and documentation it 
addresses a lot of technological issues that are receiving much more 
attention, millions of medical records are stolen every year and 
governments not getting along as well as we'd like?

https://www.wesh.com/article/millions-of-health-records-stolen-every-year/29988160

Could Java be the answer?

It can be modified and improved, it hasn't received much love for a long 
time.

I'm sure it can be made much more friendly.?? Turn it into Java's 
advantage instead, nothing else like this exists and we know and those 
that do use it, understand it very well because it's been around such a 
long time.

Peter.



From weijun at openjdk.java.net  Mon May 31 15:02:57 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:02:57 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
Message-ID: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>

> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:

  default behavior reverted to allow

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/01dc4c0d..8fd09c39

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4073&range=04-05

  Stats: 183 lines in 6 files changed: 127 ins; 23 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

PR: https://git.openjdk.java.net/jdk/pull/4073


From weijun at openjdk.java.net  Mon May 31 15:09:27 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 31 May 2021 15:09:27 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: 

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

New commit pushed. The default behavior is now reverted to be equivalent to `-Djava.security.manager=allow`. No warning will be shown when the system property is set to "allow", "disallow", or not set. A new test is added to check these warning messages. Some tests are updated to match the new behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From msterner at openjdk.mxy.se  Mon May 31 15:51:32 2021
From: msterner at openjdk.mxy.se (Mikael Sterner)
Date: Mon, 31 May 2021 17:51:32 +0200
Subject: JEP 411: Disable warning message with flag?
In-Reply-To: 
References: 
Message-ID: <3d4670da-43e1-4aa8-ab88-69405dffcf32@www.fastmail.com>

For the record, I want to point out that the latest revision to the
JEP 411 draft didn't solve the issue highlighted below, since applications
embedding a Java runtime still would not be able to suppress the warning
issued when setting a security manager. Such applications will thus have
to stay at Java 16 or earlier while migrating away from the Security
Manager, instead of being able to stay at Java 17+.

Regardless of the decision taken on allowing the suppression of warnings
(I stated my case), I think JEP 411 could benefit from being more clear
about the actors involved, and what their role is in relation to the Java
runtime. Currently it talks about the "users" and "developers" of a Java
application, but seems to assume that "users" benefit from knowing about
details (deprecated APIs) that typically would only concern "developers",
at least in a post-JRE world.

In a post-JRE world, the concept of "users" and "their Java applications"
doesn't make sense, since how would a "user" even know that their
application used Java, when the "developer" has hidden the Java runtime
behind jlink/jpackage, a launch script, or the Invocation API? I would
thus question the second goal of JEP 411 for such applications.

Yours,
Mikael Sterner

On Fri, May 21, 2021, at 19:33, Mikael Sterner wrote:
> The current version of JEP 411 (Deprecate the Security Manager for 
> Removal) has as its goal "Warn users if their Java applications rely on 
> the Security Manager.". To that end it proposes to "Issue a warning 
> message at startup if the Security Manager is enabled on the command 
> line."
> 
> I would suggest adding a flag to disable the warning message, for use 
> in cases where an application ships to end users with a Java runtime 
> included. Because in those cases, the warning is meant for the 
> developer of the application and not end users. End users would not be 
> the ones providing/upgrading the Java runtime, and in many cases it 
> would not be acceptable to have a warning displayed on startup that 
> could confuse users.
> 
> If a flag to disable the command line warning is not added, the effect 
> will be that the Security Manager is not possible to use in such 
> applications already in Java 17 (counting on the proposed target), 
> which seems rather harsh given the short notice.
> 
> If the flag is added, developers of applications that use the Security 
> Manager will still notice the warning (until disabled) but they get 
> more time to migrate to better solutions like process isolation. As a 
> bonus, for hard-to-migrate cases you can stay on Java 17 with the 
> Security Manager for as long as you're willing to pay, since many 
> vendors seem to plan to offer long term support for it.
> 
> Yours,
> Mikael Sterner


From lancea at openjdk.java.net  Mon May 31 16:24:24 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 31 May 2021 16:24:24 GMT
Subject: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager
 for Removal [v6]
In-Reply-To: <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
References: <_lD3kOiYR1ulm4m7HivqnnFQBD7WxWWLBz56oP6EMVU=.1723b50b-4390-457c-878d-f726cb1ce170@github.com>
 <2BckdZPCGmN4MBYST7T7jVz08y-vJwSqRc3pcPEBTWA=.c47e0c65-f091-4c87-89d5-893f662ff892@github.com>
Message-ID: <95Pzw60HuW83TYfd9Dogs6AdG0GDq0Ajh8McoTvRhJU=.37e0db8a-8670-408f-81cd-b5d30ea724ce@github.com>

On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1 The essential change for this JEP, including the `@Deprecate` annotations and spec change. It also update the default value of the `java.security.manager` system property to "disallow", and necessary test change following this update.
>> 2. https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66 Manual changes to several files so that the next commit can be generated programatically.
>> 3. https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950 Automatic changes to other source files to avoid javac warnings on deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is generated programmatically, see the comment below for more details. If you are only interested in a portion of the 3rd commit and would like to review it as a separate file, please comment here and I'll generate an individual webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system property is now "disallow", most of the tests calling `System.setSecurityManager()` need to launched with `-Djava.security.manager=allow`. This is covered in a different PR at https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   default behavior reverted to allow

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4073


From dfuchs at openjdk.java.net  Mon May 31 16:27:33 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 31 May 2021 16:27:33 GMT
Subject: RFR: 8267990: Revisit some uses of `synchronized` in the HttpClient
 API
Message-ID: 

The Utils.remaining(List list) method assumes that it can and should synchronize on the given list to prevent concurrent modification. In 99% of the cases this assumption is wrong. There's only one such list (the SSLFlowDelegate writeList) that requires this synchronization. 

Also the `SequentialScheduler.synchronizedScheduler` uses `synchronized`, it could use a Lock instead and this would make it possible to assert that there is no contention (since the logic of the SequentialScheduler is supposed to prevent contention from occurring at this place).

-------------

Commit messages:
 - 8267990: Revisit some uses of `synchronized` in the HttpClient API

Changes: https://git.openjdk.java.net/jdk/pull/4275/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4275&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267990
  Stats: 101 lines in 13 files changed: 59 ins; 6 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4275/head:pull/4275

PR: https://git.openjdk.java.net/jdk/pull/4275


From chegar at openjdk.java.net  Mon May 31 16:34:24 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 31 May 2021 16:34:24 GMT
Subject: RFR: 8267990: Revisit some uses of `synchronized` in the
 HttpClient API
In-Reply-To: 
References: 
Message-ID: 

On Mon, 31 May 2021 16:21:29 GMT, Daniel Fuchs  wrote:

> The Utils.remaining(List list) method assumes that it can and should synchronize on the given list to prevent concurrent modification. In 99% of the cases this assumption is wrong. There's only one such list (the SSLFlowDelegate writeList) that requires this synchronization. 
> 
> Also the `SequentialScheduler.synchronizedScheduler` uses `synchronized`, it could use a Lock instead and this would make it possible to assert that there is no contention (since the logic of the SequentialScheduler is supposed to prevent contention from occurring at this place).

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/4275


From dfuchs at openjdk.java.net  Mon May 31 16:40:44 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 31 May 2021 16:40:44 GMT
Subject: RFR: 8267990: Revisit some uses of `synchronized` in the
 HttpClient API [v2]
In-Reply-To: 
References: 
Message-ID: 

> The Utils.remaining(List list) method assumes that it can and should synchronize on the given list to prevent concurrent modification. In 99% of the cases this assumption is wrong. There's only one such list (the SSLFlowDelegate writeList) that requires this synchronization. 
> 
> Also the `SequentialScheduler.synchronizedScheduler` uses `synchronized`, it could use a Lock instead and this would make it possible to assert that there is no contention (since the logic of the SequentialScheduler is supposed to prevent contention from occurring at this place).

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  8267990: Revisit some uses of `synchronized` in the HttpClient API

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4275/files
  - new: https://git.openjdk.java.net/jdk/pull/4275/files/c2f49a5f..7d92e7bd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4275&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4275&range=00-01

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4275.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4275/head:pull/4275

PR: https://git.openjdk.java.net/jdk/pull/4275


From chap at anastigmatix.net  Mon May 31 16:45:56 2021
From: chap at anastigmatix.net (Chapman Flack)
Date: Mon, 31 May 2021 12:45:56 -0400
Subject: JEP 411: Disable warning message with flag?
In-Reply-To: <3d4670da-43e1-4aa8-ab88-69405dffcf32@www.fastmail.com>
References: 
 <3d4670da-43e1-4aa8-ab88-69405dffcf32@www.fastmail.com>
Message-ID: <60B512C4.40608@anastigmatix.net>

On 05/31/21 11:51, Mikael Sterner wrote:
> For the record, I want to point out that the latest revision to the
> JEP 411 draft didn't solve the issue highlighted below, since applications
> embedding a Java runtime still would not be able to suppress the warning
> 
> On Fri, May 21, 2021, at 19:33, Mikael Sterner wrote:
>> ...
>> I would suggest adding a flag to disable the warning message, for use 
>> in cases where an application ships to end users with a Java runtime 
>> included. Because in those cases, the warning is meant for the 
>> developer of the application and not end users. End users would not be 
>> the ones providing/upgrading the Java runtime, and in many cases it 
>> would not be acceptable to have a warning displayed on startup that 

I was just composing a message to the same effect, for a slightly different
use case.

The module I maintain for the PostgreSQL RDBMS will simply have to continue
using the deprecated API for the near future. I will need to do a minor
release that deals with the deprecation and the needed invocation flags,
and handles warning its users in a context-appropriate way that is
meaningful to them and explains how the future is going to look.

I will then need to use the time available during 17's support lifetime
to work on a heavily-reengineered major release of the module that will
meet its requirements through some other mechanism.

In the meantime, users of PostgreSQL with this module installed will
derive absolutely zero benefit from having their RDBMS logs spammed
with an obscure warning from Java that they can do nothing about
every time a DB connection loads the module.

I can suggest a couple approaches. One would be to make sure the warning
is delivered via the vfprintf hook. As I am using the invocation API to
start the JVM, I can use the hook to eat the message. This might not serve
others' needs though.

Another would be to add another -Djava.security.manager value,
allow-until-degraded. In 17, that would be treated as allow, but with
the warning suppressed. In 17+n, wherever functional degradation starts,
it should become equivalent to disallow.

In essence, if I have taken the explicit step of doing a release that
adds allow-until-degraded, that is a handoff of responsibility to me.
It is now up to me to make sure that users of this module are advised
in an appropriate way of what's going down, and it is up to me to make
sure what will happen in 17+n is reasonable (in my case, it will have to
say "can't run functions of PostgreSQL's TRUSTED variety, unless you
back up to Java < 17+n, or move to the next major version of this module").
If I don't handle that responsibility, then it just stops working in 17+n
because the flag becomes equivalent to disallow. But by using that flag,
I have clearly accepted that responsibility.

Meanwhile, users of the RDBMS don't get their logs uselessly spammed.

Another ingredient that would help is to be a little less vague about
the future "degradation", but commit to one easily-detected "degradation"
that will happen no later than any other. Maybe it could be
getSecurityManager()=null, for example, which is easier to test than
whether doPrivileged() has no ACC effect.

That way, without needing a crystal ball to know in which release 17+n
the degradation will start, I can already issue a release in advance
that will detect and handle it gracefully when it happens.

Regards,
-Chap


From chap at anastigmatix.net  Mon May 31 17:08:50 2021
From: chap at anastigmatix.net (Chapman Flack)
Date: Mon, 31 May 2021 13:08:50 -0400
Subject: JEP 411: Disable warning message with flag?
In-Reply-To: <60B512C4.40608@anastigmatix.net>
References: 
 <3d4670da-43e1-4aa8-ab88-69405dffcf32@www.fastmail.com>
 <60B512C4.40608@anastigmatix.net>
Message-ID: <60B51822.8020502@anastigmatix.net>

On 05/31/21 12:45, Chapman Flack wrote:
> allow-until-degraded. In 17, that would be treated as allow, but with
> the warning suppressed. In 17+n, wherever functional degradation starts,
> it should become equivalent to disallow.
> ...
> the future "degradation", but commit to one easily-detected "degradation"
> that will happen no later than any other. Maybe it could be
> getSecurityManager()=null, for example, which is easier to test than

Ok, that was a small thinko. As long as allow-until-degraded becomes
equivalent to disallow as soon as any degradation starts, then catching
the exception from setSecurityManager will be a perfectly reliable way
to detect the degradation. :)

Regards,
-Chap


From ron.pressler at oracle.com  Mon May 31 18:58:04 2021
From: ron.pressler at oracle.com (Ron Pressler)
Date: Mon, 31 May 2021 18:58:04 +0000
Subject: JEP 411: Disable warning message with flag?
In-Reply-To: <60B512C4.40608@anastigmatix.net>
References: 
 <3d4670da-43e1-4aa8-ab88-69405dffcf32@www.fastmail.com>
 <60B512C4.40608@anastigmatix.net>
Message-ID: <25588843-E867-4720-97CD-D8B44155AE72@oracle.com>

The deprecation warnings serve three purposes:

1. Help software maintainers know about the deprecation.
2. Help software users (the more tech-literate ones, those who look at logs)
   know when the software they use has properly addressed the issue.
3. Help us better gauge, however imperfectly and indirectly, the impact of the
   deprecation process, and focus us on the more common and impactful uses of 
   the Security Manager.

While a flag to suppress warnings doesn't harm goal 1, it severely harms goals
2 and 3.

However, if the warning were emitted just once, at startup, if the ?allow? 
value is given rather than on each SM installation, would that reduce the warning 
noise for you?

On a separate note, I found your previous emails about your SM use-case
particularly interesting. Even though it falls under the sandbox category,
we might consider keeping some hooks that would allow third-parties to create
sandboxing solutions that might be satisfactory, if we?re able to find a good 
cost/benefit sweet-spot. 

I hope that you continue to provide such useful feedback as we explore the 
degradation process and seek alternatives for particular use-cases.

? Ron

> On 31 May 2021, at 17:45, Chapman Flack  wrote:
> 
> On 05/31/21 11:51, Mikael Sterner wrote:
>> For the record, I want to point out that the latest revision to the
>> JEP 411 draft didn't solve the issue highlighted below, since applications
>> embedding a Java runtime still would not be able to suppress the warning
>> 
>> On Fri, May 21, 2021, at 19:33, Mikael Sterner wrote:
>>> ...
>>> I would suggest adding a flag to disable the warning message, for use 
>>> in cases where an application ships to end users with a Java runtime 
>>> included. Because in those cases, the warning is meant for the 
>>> developer of the application and not end users. End users would not be 
>>> the ones providing/upgrading the Java runtime, and in many cases it 
>>> would not be acceptable to have a warning displayed on startup that 
> 
> I was just composing a message to the same effect, for a slightly different
> use case.
> 
> The module I maintain for the PostgreSQL RDBMS will simply have to continue
> using the deprecated API for the near future. I will need to do a minor
> release that deals with the deprecation and the needed invocation flags,
> and handles warning its users in a context-appropriate way that is
> meaningful to them and explains how the future is going to look.
> 
> I will then need to use the time available during 17's support lifetime
> to work on a heavily-reengineered major release of the module that will
> meet its requirements through some other mechanism.
> 
> In the meantime, users of PostgreSQL with this module installed will
> derive absolutely zero benefit from having their RDBMS logs spammed
> with an obscure warning from Java that they can do nothing about
> every time a DB connection loads the module.
> 
> I can suggest a couple approaches. One would be to make sure the warning
> is delivered via the vfprintf hook. As I am using the invocation API to
> start the JVM, I can use the hook to eat the message. This might not serve
> others' needs though.
> 
> Another would be to add another -Djava.security.manager value,
> allow-until-degraded. In 17, that would be treated as allow, but with
> the warning suppressed. In 17+n, wherever functional degradation starts,
> it should become equivalent to disallow.
> 
> In essence, if I have taken the explicit step of doing a release that
> adds allow-until-degraded, that is a handoff of responsibility to me.
> It is now up to me to make sure that users of this module are advised
> in an appropriate way of what's going down, and it is up to me to make
> sure what will happen in 17+n is reasonable (in my case, it will have to
> say "can't run functions of PostgreSQL's TRUSTED variety, unless you
> back up to Java < 17+n, or move to the next major version of this module").
> If I don't handle that responsibility, then it just stops working in 17+n
> because the flag becomes equivalent to disallow. But by using that flag,
> I have clearly accepted that responsibility.
> 
> Meanwhile, users of the RDBMS don't get their logs uselessly spammed.
> 
> Another ingredient that would help is to be a little less vague about
> the future "degradation", but commit to one easily-detected "degradation"
> that will happen no later than any other. Maybe it could be
> getSecurityManager()=null, for example, which is easier to test than
> whether doPrivileged() has no ACC effect.
> 
> That way, without needing a crystal ball to know in which release 17+n
> the degradation will start, I can already issue a release in advance
> that will detect and handle it gracefully when it happens.
> 
> Regards,
> -Chap


From chap at anastigmatix.net  Mon May 31 21:53:56 2021
From: chap at anastigmatix.net (Chapman Flack)
Date: Mon, 31 May 2021 17:53:56 -0400
Subject: JEP 411: Disable warning message with flag?
In-Reply-To: <25588843-E867-4720-97CD-D8B44155AE72@oracle.com>
References: 
 <3d4670da-43e1-4aa8-ab88-69405dffcf32@www.fastmail.com>
 <60B512C4.40608@anastigmatix.net>
 <25588843-E867-4720-97CD-D8B44155AE72@oracle.com>
Message-ID: <60B55AF4.803@anastigmatix.net>

On 05/31/21 14:58, Ron Pressler wrote:
> However, if the warning were emitted just once, at startup, if the
> ?allow? value is given rather than on each SM installation, would that
> reduce the warning noise for you?

In my case not at all, because only one SM is ever installed per process,
at startup.

But a PostgreSQL installation can start processes rather frequently.
(This is a case where it works better to select JVM options that are more
client-like than server-like; there is not one long-lived 'server' JVM.)


> 1. Help software maintainers know about the deprecation.
> 2. Help software users (the more tech-literate ones, those who look at logs)
>    know when the software they use has properly addressed the issue.
> 3. Help us better gauge, however imperfectly and indirectly, the impact of the
>    deprecation process, and focus us on the more common and impactful uses of 
>    the Security Manager.
> 
> While a flag to suppress warnings doesn't harm goal 1, it severely harms
> goals 2 and 3.

In my case, goal 2 will be better served by the software users getting
release notes from me, and specific warnings generated by my code, speaking
directly to their use of PostgreSQL and PL/Java and how that will have to
evolve.

Therefore I would like an option that says "I'm on it. Please be quiet for
now, and go ahead and break in 17+n if I haven't provided my own graceful
degradation response for that case by then."

Really, my intention is to build the graceful degradation response right
now, into the same minor release that will add the option. So even if I
fall down a manhole between now and 17+n, the code will be ready for that
event anyway.

The graceful degradation will have to be a message (again from my code)
saying "the fateful Java 17+n has arrived, your functions marked trusted
are no longer allowed to run, unless you set this new database option
indicating you don't mind them running unrestricted--or revert to
Java 17+n-1, or upgrade to the new PL/Java major release that ideally
Chap pushed out before falling down that manhole."

Naturally, if you provide such an option for my use, it might also get
used by the maintainer of package X who just doesn't like looking at the
warning, and won't do anything further, and package X will have a train
wreck when 17+n arrives. But as long as it's an opt-in option that is
clearly so documented, and that maintainer deliberately pushes a commit
that adds it, that seems fair.

I am not sure what you are getting at with goal 3. Will the warning
phone home?

> we might consider keeping some hooks that would allow third-parties to create
> sandboxing solutions that might be satisfactory, if we?re able to find a good 
> cost/benefit sweet-spot. 

Thank you for that. One question I have been wondering about: do you have
any internally-tracked metrics that you can share about how many uses
of doPrivileged there are in the JDK codebase, and perhaps even a histogram
of the stack depth from the doPrivileged down to the affected
checked operation(s)?

It would be good news if a lot of those are shallow, as in "the checked
operation that I know to be taint-free is this one right here that I am
wrapping this doPrivileged around." (I'm sure that has always been desirable
from a code-review standpoint anyway.)

It could also be useful to partition the data according to whether the
affected checked operation is something with a real external effect
(filesystem, socket, process, thread, ...?), or is something that only
had to be checked in the pre-JPMS-encapsulation days in order to fend off
circumvention of the policy.

I am also sort of wondering what's to become of some of the familiar
known rules in the post-SM world. Will getClassLoader() become always
allowed, whether the loader is an ancestor or not? Will
setContextClassLoader() be a free-for-all? checkGuard()? ...?

Is it confidently believed that the JPMS encapsulation suffices for
integrity enforcement and non-circumvention with all of those former
familiar rules relaxed?

Regards,
-Chap


From peter.firmstone at zeus.net.au  Fri May 21 10:19:19 2021
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Fri, 21 May 2021 20:19:19 +1000
Subject: [External] : Re: JEP411: Missing use-case: Monitoring /
 restricting libraries
In-Reply-To: 
References: 
 
 <443EB134-930F-41A0-B8A4-7414741734E0@oracle.com>
 
 
 
 
 
 <6f3fe83c-e579-6b89-dbfd-e86581f81fe6@zeus.net.au>
 <09904C75-830A-4DCE-86D4-A76102249CF2@oracle.com>
 <207e45d6-7a5f-2c9a-f121-846c893ad4de@zeus.net.au>
 <3E3AFC65-9592-4C91-B226-2DF2479BBCBD@oracle.com>
 <3baf725c-39a2-e98f-8e70-5a11730221ad@zeus.net.au>
 <811367F2-3E4C-4E72-9F47-B31E339EC09F@oracle.com>
 
 
 
 
Message-ID: <5cedefc6-704f-5aa7-be65-756281735429@zeus.net.au>


On 21/05/2021 6:58 pm, Ron Pressler wrote:
>> These are just opinions, it's nice to have them, but they're not helping.   I think you'll find usages of SecurityManager api's are far more widespread than your opinion suggests, but that's just my opinion too lol.
> I guess you could say they?re my opinions because there is no conclusive proof, but they are based
> on empirical data. At least you should scan GitHub and Maven Central. That few libraries are properly
> instrumented is yet another piece of evidence. This isn?t conclusive, and that is why we?re discussing
> this here in an attempt to collect more information, but we have done our homework.


Can you share this list please??? If I see anything missing I can add it 
for you.


>
>> Yes, I think we should keep it simple, and keep calling it the principle of least privilege, to avoid confusion, it's very beneficial for reducing the consequences of perimeter security failure, even if your experts think otherwise.
> It is absolutely not the principle of least privilege,

So I'm restricting permissions granted to only those required to perform 
the intended tasks of the software,? restricted even to a subset of 
which that software is capable, and you say it is not the principle of 
least privilege?

Please refer to the attached policy file.

Notice how the attached grants permission to code and principal? That 
means the code without the Principal cannot attain that privilege, nor 
can the Principal use that permission without the specified code?

This means if an attacker breaches peripheral protection systems, such 
as authentication, they can not perform anything that requires 
permission outside of the granted scope?

I execute exactly the code paths I want executed, with the user role I 
want to perform that task, I grant only the permissions required to 
perform the intended task.

How is this absolutely not the principle of least privilege?

> Java (the last remaining mainstream platform
> with a mechanism that assigns permissions on a per-class basis).

Java Policy doesn't assign permissions on a per-class basis, it assigns 
them by ProtectionDomain, or by ClassLoader, or by CodeSource, or by 
Signer Certificates, or by Principal, or by a combination of Principal's 
and (ProtectionDomain or ClassLoader or CodeSource, or signer 
Certificates) and Certificates.? I don't really want to document all the 
possibilities here if yo don't mind.

How do you critique something if you don't understand how it works?

With test cases, I can generate policy files for the principle of least 
privilege for any Java software, including dependencies.

Not only that, but I do it without impacting performance or scalability.

Show me some evidence for your arguments, name your experts you speak of 
so often.

If you are going to argue, back it up with hard evidence, not nonsense.

I provide you with hard evidence, show me the same courtesy and respect 
please.

I'm not seeing any evidence that you have done much homework at all sir?

Previously you claimed SecurityManager didn't even work, that a 
Doctorate in Nuclear particle physics was required to use it.

I don't wish to publicly show that I doubt your credibility, but you are 
making it difficult for me not to sir.? It is your user base you need to 
convince, so far, you are not very convincing.

-- 
Respectfully,
  
Peter Firmstone

-------------- next part --------------
grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53583", "accept,resolve";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "shutdownHooks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53586", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53587", "accept,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
    permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
};

grant codebase "jrt:/java.smartcardio"
{
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission javax.security.auth.AuthPermission "getSubject";
};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.rmi.server.codebase", "read";
    permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53583", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "getProtectionDomain";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
};

grant codebase "jrt:/jdk.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential ", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.crypto.policy";
    permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred";
    permission java.security.SecurityPermission "getProperty.jdk.serialFilter";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.login.config.url.1";
    permission java.security.SecurityPermission "getProperty.login.configuration.provider";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.securerandom.source";
    permission java.security.SecurityPermission "getProperty.security.provider.1";
    permission java.security.SecurityPermission "getProperty.security.provider.10";
    permission java.security.SecurityPermission "getProperty.security.provider.11";
    permission java.security.SecurityPermission "getProperty.security.provider.12";
    permission java.security.SecurityPermission "getProperty.security.provider.13";
    permission java.security.SecurityPermission "getProperty.security.provider.14";
    permission java.security.SecurityPermission "getProperty.security.provider.2";
    permission java.security.SecurityPermission "getProperty.security.provider.3";
    permission java.security.SecurityPermission "getProperty.security.provider.4";
    permission java.security.SecurityPermission "getProperty.security.provider.5";
    permission java.security.SecurityPermission "getProperty.security.provider.6";
    permission java.security.SecurityPermission "getProperty.security.provider.7";
    permission java.security.SecurityPermission "getProperty.security.provider.8";
    permission java.security.SecurityPermission "getProperty.security.provider.9";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SUN";
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.security.SecurityPermission "putProviderProperty.SunJCE";
    permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunRsaSign";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission javax.security.auth.AuthPermission "setLoginConfiguration";
    permission java.util.logging.LoggingPermission "control";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53583", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessSystemModules";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.nio";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "loggerFinder";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "reflectionFactoryAccess";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53586", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53587", "accept,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential ", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.NetPermission "getProxySelector";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.util.logging.LoggingPermission "control";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53583", "accept,resolve";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53583", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53701", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53702", "accept,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53698", "accept,resolve";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "shutdownHooks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53701", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53702", "accept,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
};

grant codebase "jrt:/java.smartcardio"
{
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/java.xml.crypto"
{
    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.rmi.server.codebase", "read";
    permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53698", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
    permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.crypto.policy";
    permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred";
    permission java.security.SecurityPermission "getProperty.jdk.serialFilter";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.login.config.url.1";
    permission java.security.SecurityPermission "getProperty.login.configuration.provider";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.securerandom.source";
    permission java.security.SecurityPermission "getProperty.security.provider.1";
    permission java.security.SecurityPermission "getProperty.security.provider.10";
    permission java.security.SecurityPermission "getProperty.security.provider.11";
    permission java.security.SecurityPermission "getProperty.security.provider.12";
    permission java.security.SecurityPermission "getProperty.security.provider.13";
    permission java.security.SecurityPermission "getProperty.security.provider.14";
    permission java.security.SecurityPermission "getProperty.security.provider.2";
    permission java.security.SecurityPermission "getProperty.security.provider.3";
    permission java.security.SecurityPermission "getProperty.security.provider.4";
    permission java.security.SecurityPermission "getProperty.security.provider.5";
    permission java.security.SecurityPermission "getProperty.security.provider.6";
    permission java.security.SecurityPermission "getProperty.security.provider.7";
    permission java.security.SecurityPermission "getProperty.security.provider.8";
    permission java.security.SecurityPermission "getProperty.security.provider.9";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SUN";
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.security.SecurityPermission "putProviderProperty.SunJCE";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunRsaSign";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission java.security.SecurityPermission "setPolicy";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission javax.security.auth.AuthPermission "setLoginConfiguration";
    permission java.util.logging.LoggingPermission "control";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential ", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53698", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessSystemModules";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.nio";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "loggerFinder";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "reflectionFactoryAccess";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
};

grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "getProtectionDomain";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.net.NetPermission "getProxySelector";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.util.logging.LoggingPermission "control";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential ", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53698", "accept,resolve";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53698", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/java.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53926", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53934", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53952", "accept,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "shutdownHooks";
};

grant codebase "jrt:/java.xml.crypto"
{
    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53934", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53937", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar"
{
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.rmi.server.codebase", "read";
    permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53926", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53934", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53952", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "getProtectionDomain";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53934", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53937", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "jrt:/jdk.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17681811632309791462.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17681811632309791462.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17681811632309791462.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.crypto.policy";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred";
    permission java.security.SecurityPermission "getProperty.jdk.serialFilter";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.login.config.url.1";
    permission java.security.SecurityPermission "getProperty.login.configuration.provider";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.securerandom.source";
    permission java.security.SecurityPermission "getProperty.security.provider.1";
    permission java.security.SecurityPermission "getProperty.security.provider.10";
    permission java.security.SecurityPermission "getProperty.security.provider.11";
    permission java.security.SecurityPermission "getProperty.security.provider.12";
    permission java.security.SecurityPermission "getProperty.security.provider.13";
    permission java.security.SecurityPermission "getProperty.security.provider.14";
    permission java.security.SecurityPermission "getProperty.security.provider.2";
    permission java.security.SecurityPermission "getProperty.security.provider.3";
    permission java.security.SecurityPermission "getProperty.security.provider.4";
    permission java.security.SecurityPermission "getProperty.security.provider.5";
    permission java.security.SecurityPermission "getProperty.security.provider.6";
    permission java.security.SecurityPermission "getProperty.security.provider.7";
    permission java.security.SecurityPermission "getProperty.security.provider.8";
    permission java.security.SecurityPermission "getProperty.security.provider.9";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SUN";
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.security.SecurityPermission "putProviderProperty.SunJCE";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunRsaSign";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission javax.security.auth.AuthPermission "setLoginConfiguration";
    permission java.util.logging.LoggingPermission "control";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53926", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53934", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53952", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessSystemModules";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.nio";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "loggerFinder";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "reflectionFactoryAccess";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53934", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53937", "connect,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
    permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17681811632309791462.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17681811632309791462.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17681811632309791462.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.util.logging.LoggingPermission "control";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53934", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53952", "accept,resolve";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getClassAnnotation";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getEncodedCerts";
    permission net.jini.security.AccessPermission "org.apache.river.admin.DestroyAdmin.destroy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.register";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
};

grant codebase "jrt:/java.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53926", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53952", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53934", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:53937", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "jrt:/java.smartcardio"
{
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
};

grant codebase "jrt:/java.xml.crypto"
{
    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54149", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54152", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54143", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54149", "accept,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "shutdownHooks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54149", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54152", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
    permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read";
};

grant codebase "jrt:/jdk.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
};

grant codebase "jrt:/java.smartcardio"
{
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.rmi.server.codebase", "read";
    permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54143", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54149", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "getProtectionDomain";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getClassAnnotation";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getEncodedCerts";
    permission net.jini.security.AccessPermission "org.apache.river.admin.DestroyAdmin.destroy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.notiFy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.register";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17694708624372961840.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17694708624372961840.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17694708624372961840.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.crypto.policy";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred";
    permission java.security.SecurityPermission "getProperty.jdk.serialFilter";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.login.config.url.1";
    permission java.security.SecurityPermission "getProperty.login.configuration.provider";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.securerandom.source";
    permission java.security.SecurityPermission "getProperty.security.provider.1";
    permission java.security.SecurityPermission "getProperty.security.provider.10";
    permission java.security.SecurityPermission "getProperty.security.provider.11";
    permission java.security.SecurityPermission "getProperty.security.provider.12";
    permission java.security.SecurityPermission "getProperty.security.provider.13";
    permission java.security.SecurityPermission "getProperty.security.provider.14";
    permission java.security.SecurityPermission "getProperty.security.provider.2";
    permission java.security.SecurityPermission "getProperty.security.provider.3";
    permission java.security.SecurityPermission "getProperty.security.provider.4";
    permission java.security.SecurityPermission "getProperty.security.provider.5";
    permission java.security.SecurityPermission "getProperty.security.provider.6";
    permission java.security.SecurityPermission "getProperty.security.provider.7";
    permission java.security.SecurityPermission "getProperty.security.provider.8";
    permission java.security.SecurityPermission "getProperty.security.provider.9";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SUN";
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.security.SecurityPermission "putProviderProperty.SunJCE";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunRsaSign";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission javax.security.auth.AuthPermission "setLoginConfiguration";
    permission java.util.logging.LoggingPermission "control";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54143", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54149", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessSystemModules";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.nio";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "loggerFinder";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "reflectionFactoryAccess";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54149", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54152", "connect,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17694708624372961840.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17694708624372961840.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache17694708624372961840.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.util.logging.LoggingPermission "control";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54143", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54149", "accept,resolve";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
};

grant codebase "jrt:/java.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
};

grant codebase "httpmd://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar;sha=b5afcec62d076600b575da853d09f73e2f9b81c9"
{
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54143", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54149", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54152", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "jrt:/java.xml.crypto"
{
    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar"
{
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54222", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54229", "accept,resolve";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "shutdownHooks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getClassAnnotation";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getEncodedCerts";
    permission net.jini.security.AccessPermission "org.apache.river.admin.DestroyAdmin.destroy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.notiFy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.register";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54229", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54232", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "jrt:/java.smartcardio"
{
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
    permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar"
{
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission javax.security.auth.AuthPermission "getSubject";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.rmi.server.codebase", "read";
    permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getClassLoader";
};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getSubject";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54222", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54229", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "getProtectionDomain";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4086211490695541220.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4086211490695541220.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4086211490695541220.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.crypto.policy";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred";
    permission java.security.SecurityPermission "getProperty.jdk.serialFilter";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.login.config.url.1";
    permission java.security.SecurityPermission "getProperty.login.configuration.provider";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.securerandom.source";
    permission java.security.SecurityPermission "getProperty.security.provider.1";
    permission java.security.SecurityPermission "getProperty.security.provider.10";
    permission java.security.SecurityPermission "getProperty.security.provider.11";
    permission java.security.SecurityPermission "getProperty.security.provider.12";
    permission java.security.SecurityPermission "getProperty.security.provider.13";
    permission java.security.SecurityPermission "getProperty.security.provider.14";
    permission java.security.SecurityPermission "getProperty.security.provider.2";
    permission java.security.SecurityPermission "getProperty.security.provider.3";
    permission java.security.SecurityPermission "getProperty.security.provider.4";
    permission java.security.SecurityPermission "getProperty.security.provider.5";
    permission java.security.SecurityPermission "getProperty.security.provider.6";
    permission java.security.SecurityPermission "getProperty.security.provider.7";
    permission java.security.SecurityPermission "getProperty.security.provider.8";
    permission java.security.SecurityPermission "getProperty.security.provider.9";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SUN";
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.security.SecurityPermission "putProviderProperty.SunJCE";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunRsaSign";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission javax.security.auth.AuthPermission "setLoginConfiguration";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.util.logging.LoggingPermission "control";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54222", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54229", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessSystemModules";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.nio";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "loggerFinder";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "reflectionFactoryAccess";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54229", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54232", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4086211490695541220.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4086211490695541220.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4086211490695541220.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.util.logging.LoggingPermission "control";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54222", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54229", "accept,resolve";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/java.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54229", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54232", "connect,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "jrt:/jdk.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54222", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
};

grant codebase "httpmd://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar;sha=fcbcbc6de40d41791ce7eeb47a5a25c7aa12dcee"
{
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54229", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54232", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54355", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54361", "accept,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "shutdownHooks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54361", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54364", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
};

grant codebase "httpmd://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar;md5=b62123057dd92fbf5dadb35d1f08b297"
{
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "jrt:/java.smartcardio"
{
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission javax.security.auth.AuthPermission "getSubject";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.rmi.server.codebase", "read";
    permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getClassLoader";
};

grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54355", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54361", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54361", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54364", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "getProtectionDomain";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "jrt:/jdk.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache5655481226212806669.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache5655481226212806669.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache5655481226212806669.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.crypto.policy";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred";
    permission java.security.SecurityPermission "getProperty.jdk.serialFilter";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.login.config.url.1";
    permission java.security.SecurityPermission "getProperty.login.configuration.provider";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.securerandom.source";
    permission java.security.SecurityPermission "getProperty.security.provider.1";
    permission java.security.SecurityPermission "getProperty.security.provider.10";
    permission java.security.SecurityPermission "getProperty.security.provider.11";
    permission java.security.SecurityPermission "getProperty.security.provider.12";
    permission java.security.SecurityPermission "getProperty.security.provider.13";
    permission java.security.SecurityPermission "getProperty.security.provider.14";
    permission java.security.SecurityPermission "getProperty.security.provider.2";
    permission java.security.SecurityPermission "getProperty.security.provider.3";
    permission java.security.SecurityPermission "getProperty.security.provider.4";
    permission java.security.SecurityPermission "getProperty.security.provider.5";
    permission java.security.SecurityPermission "getProperty.security.provider.6";
    permission java.security.SecurityPermission "getProperty.security.provider.7";
    permission java.security.SecurityPermission "getProperty.security.provider.8";
    permission java.security.SecurityPermission "getProperty.security.provider.9";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SUN";
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.security.SecurityPermission "putProviderProperty.SunJCE";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunRsaSign";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission javax.security.auth.AuthPermission "setLoginConfiguration";
    permission java.util.logging.LoggingPermission "control";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54355", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54361", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessSystemModules";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.nio";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "loggerFinder";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "reflectionFactoryAccess";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54361", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54364", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getClassAnnotation";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getEncodedCerts";
    permission net.jini.security.AccessPermission "org.apache.river.admin.DestroyAdmin.destroy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.notiFy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.register";
};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache5655481226212806669.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache5655481226212806669.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache5655481226212806669.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.util.logging.LoggingPermission "control";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54355", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54361", "accept,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
};

grant codebase "jrt:/java.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54355", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54361", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54364", "connect,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
    permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read";
};

grant codebase "jrt:/java.xml.crypto"
{
    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54425", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54429", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54432", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54446", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54450", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54452", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54463", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54485", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54493", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54505", "accept,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getClassAnnotation";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getEncodedCerts";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.notiFy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.register";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54422", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54429", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54446", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54452", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54463", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54485", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54493", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54505", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54506", "accept,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "shutdownHooks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
    permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin";
    permission net.jini.security.AccessPermission "org.apache.river.admin.DestroyAdmin.destroy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.rmi.server.codebase", "read";
    permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54422", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54429", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54446", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54452", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54463", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54485", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54493", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54505", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54506", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
};

grant codebase "jrt:/java.smartcardio"
{
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "getProtectionDomain";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54429", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54432", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54446", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54452", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54463", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54485", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54493", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54505", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases";
};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4200132123085984126.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4200132123085984126.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4200132123085984126.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.crypto.policy";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred";
    permission java.security.SecurityPermission "getProperty.jdk.serialFilter";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.login.config.url.1";
    permission java.security.SecurityPermission "getProperty.login.configuration.provider";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.securerandom.source";
    permission java.security.SecurityPermission "getProperty.security.provider.1";
    permission java.security.SecurityPermission "getProperty.security.provider.10";
    permission java.security.SecurityPermission "getProperty.security.provider.11";
    permission java.security.SecurityPermission "getProperty.security.provider.12";
    permission java.security.SecurityPermission "getProperty.security.provider.13";
    permission java.security.SecurityPermission "getProperty.security.provider.14";
    permission java.security.SecurityPermission "getProperty.security.provider.2";
    permission java.security.SecurityPermission "getProperty.security.provider.3";
    permission java.security.SecurityPermission "getProperty.security.provider.4";
    permission java.security.SecurityPermission "getProperty.security.provider.5";
    permission java.security.SecurityPermission "getProperty.security.provider.6";
    permission java.security.SecurityPermission "getProperty.security.provider.7";
    permission java.security.SecurityPermission "getProperty.security.provider.8";
    permission java.security.SecurityPermission "getProperty.security.provider.9";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SUN";
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.security.SecurityPermission "putProviderProperty.SunJCE";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunRsaSign";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission javax.security.auth.AuthPermission "setLoginConfiguration";
    permission java.util.logging.LoggingPermission "control";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54422", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54429", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54446", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54452", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54463", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54485", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54493", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54505", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54506", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessSystemModules";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.nio";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "loggerFinder";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "reflectionFactoryAccess";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
};

grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54429", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54432", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54446", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54452", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54463", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54485", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54493", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54505", "accept,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4200132123085984126.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4200132123085984126.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache4200132123085984126.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.util.logging.LoggingPermission "control";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54429", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54446", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54452", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54463", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54485", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54493", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54505", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54506", "accept,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "jrt:/java.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.lookup";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.renewLeases";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission net.jini.security.GrantPermission "net.jini.security.AuthenticationPermission \"javax.security.auth.x500.X500Principal \\\"CN=Reggie\\\" peer javax.security.auth.x500.X500Principal \\\"CN=Tester\\\"\", \"connect\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54425", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54429", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54432", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54446", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54450", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54452", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54463", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54485", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54493", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54505", "accept,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54422", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54506", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/java.xml.crypto"
{
    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54641", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54644", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar"
{
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54631", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54641", "accept,resolve";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "shutdownHooks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\" peer javax.security.auth.x500.X500Principal \"CN=Tester\"", "connect";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54641", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54644", "connect,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.lang.RuntimePermission "createClassLoader";
};

grant codebase "jrt:/jdk.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
};

grant codebase "jrt:/java.smartcardio"
{
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "jrt:/jdk.localedata"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.rmi.server.codebase", "read";
    permission java.util.PropertyPermission "net.jini.loader.codebaseAnnotation", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "getClassLoader";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-url-integrity-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-jeri-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.client.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connection.mux.server.initialInboundRation", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.connectionTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.checkInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.cleanInterval", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.leaseValue", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.dgc.minimumDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.handshakeTimeout", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxCacheSize", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.maxGssContextRetries", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.kerberos.KerberosEndpoint.minGssContextLifetime", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.server.suppressStackTraces", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.tcp.useNIO", "read";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54631", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54641", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.security.auth"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "getProtectionDomain";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "javax.net.ssl.trustStore", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStorePassword", "read";
    permission java.util.PropertyPermission "javax.net.ssl.trustStoreType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.certificateType", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.cipherSuites", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jceProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.jsseProvider", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxClientSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.maxServerSessionDuration", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.secureRandomAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.sslProtocol", "read";
    permission java.util.PropertyPermission "org.apache.river.jeri.ssl.trustManagerFactoryAlgorithm", "read";
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission java.util.PropertyPermission "org.apache.river.reggie.enableImplToStubReplacement", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission java.io.FilePermission "harness\\trust\\truststore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54641", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54644", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9080", "connect,resolve";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/jdk.crypto.ec"
{
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-platform-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\nio.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunec.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\net.properties", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_US_export.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\policy\\unlimited\\default_local.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\tzdb.dat", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13495776613407126739.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13495776613407126739.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13495776613407126739.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\service-starter-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\jsselogins", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getNetworkInformation";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.crypto.policy";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.security.provider.preferred";
    permission java.security.SecurityPermission "getProperty.jdk.serialFilter";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.login.config.url.1";
    permission java.security.SecurityPermission "getProperty.login.configuration.provider";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.securerandom.source";
    permission java.security.SecurityPermission "getProperty.security.provider.1";
    permission java.security.SecurityPermission "getProperty.security.provider.10";
    permission java.security.SecurityPermission "getProperty.security.provider.11";
    permission java.security.SecurityPermission "getProperty.security.provider.12";
    permission java.security.SecurityPermission "getProperty.security.provider.13";
    permission java.security.SecurityPermission "getProperty.security.provider.14";
    permission java.security.SecurityPermission "getProperty.security.provider.2";
    permission java.security.SecurityPermission "getProperty.security.provider.3";
    permission java.security.SecurityPermission "getProperty.security.provider.4";
    permission java.security.SecurityPermission "getProperty.security.provider.5";
    permission java.security.SecurityPermission "getProperty.security.provider.6";
    permission java.security.SecurityPermission "getProperty.security.provider.7";
    permission java.security.SecurityPermission "getProperty.security.provider.8";
    permission java.security.SecurityPermission "getProperty.security.provider.9";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SUN";
    permission java.security.SecurityPermission "putProviderProperty.SunEC";
    permission java.security.SecurityPermission "putProviderProperty.SunJCE";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunJSSE";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunRsaSign";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission java.security.SecurityPermission "setPolicy";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission javax.security.auth.AuthPermission "setLoginConfiguration";
    permission java.util.logging.LoggingPermission "control";
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
    permission org.apache.river.thread.ThreadPoolPermission "getUserThreadPool";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[0:0:0:0:0:0:0:0]", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54631", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54641", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.krb5";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.locale.provider";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.util.resources";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "accessSystemModules";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.nio";
    permission java.lang.RuntimePermission "loadLibrary.sunec";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "loggerFinder";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "reflectionFactoryAccess";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission org.apache.river.thread.ThreadPoolPermission "getSystemThreadPool";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-collections-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/reggie-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
    permission java.io.SerializablePermission "enableSubclassImplementation";
};

grant     principal javax.security.auth.x500.X500Principal "CN=Tester"
{
    permission net.jini.security.AccessPermission "net.jini.admin.Administrable.getAdmin";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getClassAnnotation";
    permission net.jini.security.AccessPermission "net.jini.export.CodebaseAccessor.getEncodedCerts";
    permission net.jini.security.AccessPermission "org.apache.river.admin.DestroyAdmin.destroy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.notiFy";
    permission net.jini.security.AccessPermission "org.apache.river.reggie.proxy.Registrar.register";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/service-starter-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "*", "read,write";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "set";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\net.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\sunmscapi.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\bin\\zip.dll", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\conf\\security\\java.policy", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\blacklisted.certs", "read";
    permission java.io.FilePermission "C:\\Program Files\\Zulu\\zulu-13\\lib\\security\\cacerts", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\.java.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13495776613407126739.tmp", "delete";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13495776613407126739.tmp", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\AppData\\Local\\Temp\\jar_cache13495776613407126739.tmp", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-discovery-providers-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-platform-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-url-integrity-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultnonactvm.policy.new", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\lib\\jiniharness.jar", "read";
    permission java.io.FilePermission "file:\\C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\policy\\defaultsecurereggie.policy", "read";
    permission java.net.NetPermission "getCookieHandler";
    permission java.net.NetPermission "getProxySelector";
    permission java.net.NetPermission "getResponseCache";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "listen";
    permission java.security.SecurityPermission "createAccessControlContext";
    permission java.security.SecurityPermission "getDomainCombiner";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.auth.login.defaultCallbackHandler";
    permission java.security.SecurityPermission "getProperty.jdk.certpath.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.security.caDistrustPolicies";
    permission java.security.SecurityPermission "getProperty.jdk.tls.disabledAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.keyLimits";
    permission java.security.SecurityPermission "getProperty.jdk.tls.legacyAlgorithms";
    permission java.security.SecurityPermission "getProperty.jdk.tls.server.defaultDHEParameters";
    permission java.security.SecurityPermission "getProperty.keystore.type";
    permission java.security.SecurityPermission "getProperty.keystore.type.compat";
    permission java.security.SecurityPermission "getProperty.org.apache.river.start.servicePolicyProvider";
    permission java.security.SecurityPermission "getProperty.policy.allowSystemProperty";
    permission java.security.SecurityPermission "getProperty.policy.expandProperties";
    permission java.security.SecurityPermission "getProperty.policy.url.1";
    permission java.security.SecurityPermission "getProperty.policy.url.2";
    permission java.security.SecurityPermission "getProperty.policy.url.3";
    permission java.security.SecurityPermission "getProperty.securerandom.drbg.config";
    permission java.security.SecurityPermission "getProperty.ssl.TrustManagerFactory.algorithm";
    permission java.security.SecurityPermission "putProviderProperty.JdkLDAP";
    permission java.security.SecurityPermission "putProviderProperty.JdkSASL";
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.security.SecurityPermission "putProviderProperty.SunPCSC";
    permission java.security.SecurityPermission "putProviderProperty.SunSASL";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
    permission javax.security.auth.AuthPermission "getLoginConfiguration";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.AuthPermission "getSubjectFromDomainCombiner";
    permission javax.security.auth.AuthPermission "modifyPrincipals";
    permission javax.security.auth.AuthPermission "modifyPrivateCredentials";
    permission javax.security.auth.AuthPermission "modifyPublicCredentials";
    permission java.util.logging.LoggingPermission "control";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.io.SerializablePermission "enableSubstitution";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54631", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54641", "accept,resolve";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar", "GET:";
    permission net.jini.io.context.ContextPermission "net.jini.io.context.ClientSubject.getClientSubject";
    permission java.lang.RuntimePermission "accessClassInPackage.jdk.internal.reflect";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.jca";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.pkcs";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util.math.intpoly";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.x509";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "createSecurityManager";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "getClassLoader";
    permission java.lang.RuntimePermission "getProtectionDomain";
    permission java.lang.RuntimePermission "getStackWalkerWithClassReference";
    permission java.lang.RuntimePermission "loadLibrary.net";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
    permission java.lang.RuntimePermission "loadLibrary.zip";
    permission java.lang.RuntimePermission "localeServiceProvider";
    permission java.lang.RuntimePermission "modifyThread";
    permission java.lang.RuntimePermission "modifyThreadGroup";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/java.security.jgss"
{
    permission java.security.SecurityPermission "putProviderProperty.SunJGSS";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "httpmd://DESKTOP-R0ORPA2:9082/qa1-lookupservice-dl.jar;md5=b62123057dd92fbf5dadb35d1f08b297"
{
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.util.PropertyPermission "org.apache.river.qa.home", "read";
    permission org.apache.river.api.io.DeSerializationPermission "MARSHALL";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\reggie.keystore", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\tester.keystore", "read";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "accept";
    permission net.jini.security.AuthenticationPermission "javax.security.auth.x500.X500Principal \"CN=Reggie\"", "connect";
    permission java.security.SecurityPermission "getPolicy";
    permission javax.security.auth.AuthPermission "getSubject";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "224.0.1.84", "connect,accept,resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2.lan", "resolve";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54641", "accept,resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54644", "connect,resolve";
    permission java.net.SocketPermission "[ff05:0:0:0:0:0:0:156]", "connect,accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.SocketPermission "localhost:4160", "listen,resolve";
    permission java.lang.RuntimePermission "shutdownHooks";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.jeri.internal.runtime";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/reggie-service-3.1.1-SNAPSHOT.jar"
{
    permission java.util.PropertyPermission "java.net.preferIPv6Addresses", "read";
    permission java.util.PropertyPermission "net.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse", "read";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib-dl/jgdms-lib-dl-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.api.io.DeSerializationPermission "ATOMIC";
};

grant codebase "jrt:/jdk.crypto.cryptoki"
{
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/qa/lib/nonactivatablegroup.jar"
{
    permission java.util.PropertyPermission "java.security.policy", "read";
    permission java.util.PropertyPermission "java.security.policy", "write";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-activation-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\jgdms-rmi-tls-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\reggie\\reggie.config", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\configs\\jsse\\starter\\starter.config", "read";
    permission net.jini.export.ExportPermission "exportRemoteInterface.org.apache.river.qa.harness.NonActivatableGroup";
    permission java.security.SecurityPermission "createPolicy.JiniPolicy";
    permission java.security.SecurityPermission "getPolicy";
    permission java.security.SecurityPermission "getProperty.net.jini.security.policy.PolicyFileProvider.basePolicyClass";
    permission java.security.SecurityPermission "setPolicy";
    permission net.jini.security.GrantPermission "java.security.AllPermission \"\", \"\";";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Reggie";
    permission javax.security.auth.AuthPermission "createLoginContext.org.apache.river.Test";
    permission javax.security.auth.AuthPermission "doAsPrivileged";
    permission java.io.SerializablePermission "enableSubclassImplementation";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2", "resolve";
    permission java.net.SocketPermission "[fe80:0:0:0:9ca0:dfeb:b9a7:96fd%16]:54631", "accept,resolve";
    permission java.net.SocketPermission "localhost:0", "listen,resolve";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/jgdms-lib-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.net.URLPermission "http://DESKTOP-R0ORPA2:9080/reggie-dl-3.1.1-SNAPSHOT.jar", "GET:";
    permission java.lang.RuntimePermission "accessDeclaredMembers";
    permission java.lang.RuntimePermission "createClassLoader";
    permission java.lang.RuntimePermission "exitVM.0";
    permission java.lang.RuntimePermission "setContextClassLoader";
    permission java.lang.RuntimePermission "setIO";
    permission java.lang.reflect.ReflectPermission "newProxyInPackage.org.apache.river.qa.harness";
    permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codebase "jrt:/java.xml.crypto"
{
    permission java.util.PropertyPermission "java.specification.version", "read";
    permission java.security.SecurityPermission "putProviderProperty.XMLDSig";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-discovery-providers-3.1.1-SNAPSHOT.jar"
{
    permission org.apache.river.jeri.internal.EndpointInternalsPermission "get";
    permission javax.security.auth.AuthPermission "getSubject";
    permission javax.security.auth.PrivateCredentialPermission "javax.security.auth.x500.X500PrivateCredential javax.security.auth.x500.X500Principal \"CN=Reggie\"", "read";
};

grant codebase "jrt:/jdk.crypto.mscapi"
{
    permission java.security.SecurityPermission "putProviderProperty.SunMSCAPI";
    permission java.lang.RuntimePermission "accessClassInPackage.sun.security.util";
    permission java.lang.RuntimePermission "loadLibrary.sunmscapi";
};

grant codebase "file:/C:/Users/peter/Documents/NetBeansProjects/JGDMS/JGDMS/dist/target/JGDMS-3.1.1-SNAPSHOT/lib/jgdms-pref-class-loader-3.1.1-SNAPSHOT.jar",
    principal javax.security.auth.x500.X500Principal "CN=Reggie"
{
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\reggie-dl-3.1.1-SNAPSHOT.jar", "read";
    permission java.io.FilePermission "C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\reggie-service-3.1.1-SNAPSHOT.jar", "read";
    permission java.net.SocketPermission "DESKTOP-R0ORPA2:9082", "connect,resolve";
};


From alex.buckley at oracle.com  Fri May 21 17:23:24 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 21 May 2021 10:23:24 -0700
Subject: Updates to JEP 411: Deprecate the Security Manager for Removal
In-Reply-To: <9272f796-4268-a674-b648-49ff26ad3bc6@oracle.com>
References: <9272f796-4268-a674-b648-49ff26ad3bc6@oracle.com>
Message-ID: <56ee1652-9d5e-4bde-b14f-b861e9ea2987@oracle.com>

A further point is that `-Djava.security.manager=allow` has been 
special-cased since JDK 12:

- RFE:
   https://bugs.openjdk.java.net/browse/JDK-8191053

- Compatibility review:
   https://bugs.openjdk.java.net/browse/JDK-8203316

- Release note:
 
https://www.oracle.com/java/technologies/javase/12-relnote-issues.html#JDK-8191053 


(I saw that Netbeans has run into trouble under JEP 411 because some 
code does not recognize `allow`, and treats it as a class name: 
https://issues.apache.org/jira/browse/NETBEANS-5703)

Alex

On 5/19/2021 6:48 AM, Sean Mullan wrote:
> Thanks for those that have taken the time to review JEP 411 [1]. The JEP 
> has been updated today with a few changes, the most significant which is 
> the addition of a new section titled "Future Work" [2] which lists 
> related potential enhancements and works in progress.
> 
> Other smaller changes have been made throughout the JEP, including:
> 
>  ?- The "Alternate JAAS APIs" section has been removed and replaced with 
> a smaller section in the Description section with a pointer to a JBS 
> issue with more details.
> 
>  ?- Changes have been made to the Motivation section to improve some of 
> the wording and add more details.
> 
>  ?- A new item named "Preserve the Security Manager API for extension by 
> custom Security Managers that wish to intercept, log, and veto access to 
> resources" has been added to the Alternatives section, as this has been 
> a topic of discussion since the JEP has been published.
> 
>  ?- RMISecurityException has been removed from the list of APIs to be 
> deprecated for removal, and 
> java.util.concurrent.Executors::{privilegedCallable, 
> privilegedCallableUsingCurrentClassLoader, privilegedThreadFactory} have 
> been added.
> 
> Thanks,
> Sean
> 
> [1] https://openjdk.java.net/jeps/411
> [2] https://openjdk.java.net/jeps/411#Future-Work


From omniasterix at gmail.com  Tue May 25 12:30:46 2021
From: omniasterix at gmail.com (joshua spies)
Date: Tue, 25 May 2021 06:30:46 -0600
Subject: New candidate JEP: 411: Deprecate the Security Manager for
 Removal....
Message-ID: 

RE:no
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From geertjan.wielenga at googlemail.com  Sat May 29 07:02:00 2021
From: geertjan.wielenga at googlemail.com (Geertjan Wielenga)
Date: Sat, 29 May 2021 09:02:00 +0200
Subject: JEP 411: Missing use-case: user functions in an RDBMS
In-Reply-To: <3c24236f-40c9-ebbd-4d11-291ba778a0aa@zeus.net.au>
References: <60B048F9.7090105@anastigmatix.net>
 
 <3c24236f-40c9-ebbd-4d11-291ba778a0aa@zeus.net.au>
Message-ID: 

We have updated the JEP with a few changes to the "Issue Warnings"
section [1], summarized as follows:

If the Java runtime is started without setting the system property
'java.security.manager' then a custom Security Manager can be installed
dynamically by calling System::setSecurityManager, just as in Java 16.
No UnsupportedOperationException will be thrown. This call will,
however, issue a warning message explaining that the Security Manager is
deprecated and will be removed in a future release.

We plan to change the default value of the 'java.security.manager'
system property to "disallow" in the next release, i.e., Java 18. That
will cause System::setSecurityManager to throw an
UnsupportedOperationException in Java 18.

With these changes, the process of deprecating and eventually removing
the Security Manager will be consistent with our treatment of past
breaking changes such as, e.g., the strong encapsulation of internal
APIs. Maintainers of libraries and applications will be given fair
warning before any existing code is broken.

https://mail.openjdk.java.net/pipermail/jdk-dev/2021-May/005616.html



On Sat, May 29, 2021 at 12:04 AM Peter Firmstone <
peter.firmstone at zeus.net.au> wrote:

> While I accept that my particular use case will no longer be supported
> in future, it's difficult to see the value of a sandbox, because
> developers will always want to relax it in some way and people fall into
> the trap of thinking that trust is black and white; this is trusted,
> that is not.
>
> Nowadays, there's a lot more interest in the Principle of Least
> Privilege, especially in health care regulations, now I'm going to use
> the meaning implied in "Inside Java 2 Platform Security, Second
> Edition", so that we aren't arguing whether that applies with the JVM or
> external to it.
>
> The reason POLP is simpler, is that it can be automated with tooling,
> then the development / deployment team may choose to relax it, they can
> certainly test it and validate it.   Then we are simply focused on what
> we need to do, rather than what we might want to restrict, which is
> always unknown and subject to change.
>
> The problem is that this is not how developers have been taught to use
> SecurityManager, instead they are told that trusted code can be given
> AllPermission because it's trusted and that's an approach which has
> proven largely ineffective and the OpenJDK development team carry's the
> cost as a result, with little benefit.
>
> I just thought I'd provide you with a different perspective, so
> hopefully the mistake isn't repeated.
>
> Peter.
>
> On 28/05/2021 8:09 pm, Ron Pressler wrote:
> >
> > Deep sandboxes, simple or stack-dependent, are useful for very ?rich?
> code,
> > that is potentially very big and possibly contains arbitrary third-party
> > libraries, while shallow sandboxes are more suitable to limited plugins.
> >
> > While a complex, stack-dependent, deep sandbox *could* be used for
> plugins,
> > permissions that don?t specify what is forbidden but what is allowed
> > effectively also severely limit the use of third-party libraries, that
> > for example, might want to do benign operations with their own files,
> > and so effectively only allow very limited plugins. The result is a
> costly
> > mechanism that is overkill for what it?s used for.
> >
> > ? Ron
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: