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: