Authorization Layer post JEP 411

in OpenJDK to maintain Permission checks where we need them and preserve context where appropriate. JAAS will continue to remain functional and it's performance will increase significantly (it performs very well with my Policy implementation, even with stack walks). -- Regards, Peter Firmstone

Re: JEP 411 - Secure Java Distribution

and replacing them with Guard.check. Then we could potentially continue to support this functionality on later versions of Java without detonation. Cheers, Peter. On 2/06/2021 7:35 pm, Andrew Haley wrote: On 6/1/21 10:06 AM, Peter Firmstone wrote: If a vendor were to continue supporting

JEP 411 - Secure Java Distribution

If a vendor were to continue supporting SecurityManager and was backporting from OpenJDK, if it passes the JCK with SecurityManager disabled, that's still acceptable right? -- Regards, Peter Firmstone

Re: JEP411: Missing use-case: Monitoring / restricting libraries

Would have really liked to have known about that. Any chance Java 17 LTS (hopefully with sorted security manager property), can be supported as long as Java 8, 16 years? The new security API's don't exist yet, I'd prefer to work with a version that has a fully functional SecurityManager

Re: JEP411: Missing use-case: Monitoring / restricting libraries

Thanks Alan, Concurrency is difficult too, but Java has gone a long way to addressing this with concurrency libraries that make the task seem like child's play, compared to using Java 1.4 language constructs. On 31/05/2021 5:59 pm, Alan Bateman wrote: On 31/05/2021 08:11, Peter Firmstone

Re: JEP411: Missing use-case: Monitoring / restricting libraries

Hmm, whitelisting, you're using the principle of least privilege too then. We have multiple SecurityManager and Policy implementations. Our policy implementations can decorate each other with different functionality, including dynamic permissions and permissions granted by a permission

Re: JEP: 411 How JGDMS utilises the Java platform

/ task. On 30/05/2021 9:22 am, Peter Firmstone wrote: This is provided as information only I'm not looking for arguments, debate or even requesting functionality, I'm just documenting what JGDMS does now, unfortunately JGDMS appears to be too entangled with current security API's at its

JEP: 411 How JGDMS utilises the Java platform

= | -- Regards, Peter Firmstone

Re: JEP 411: Missing use-case: user functions in an RDBMS

While I accept that my particular use case will no longer be supported in future, it's difficult to see the value of a sandbox, because developers will always want to relax it in some way and people fall into the trap of thinking that trust is black and white; this is trusted, that is not.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

you. — Ron On 22 May 2021, at 00:17, Peter Firmstone wrote: I had hoped by end of this discussion, that there would at least be an understanding of what OpenJDK is so hastily choosing to destroy. Once it is gone, it will be irretrievable, it will never be possible to lock down the JVM so

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

: On 21 May 2021, at 12:52, Peter Firmstone wrote: It's quite clear this will be pushed through anyway, No, not *anyway*, but given the fact that the community consists of millions of users, this proposal has been well-publicised, I discovered the proposal on the 11th of the May on a mailing

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 21/05/2021 9:14 pm, Ron Pressler wrote: On 21 May 2021, at 11:29, Peter Firmstone wrote: Can you share this list please? If I see anything missing I can add it for you. No, because this might give the false impression that this is a debate. It's quite clear this will be pushed

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

to use it. I don't wish to publicly show that I doubt your credibility, but you are making it difficult for me not to sir.  It is your user base you need to convince, so far, you are not very convincing. -- Respectfully, Peter Firmstone

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 18/05/2021 10:09 pm, Ron Pressler wrote: On 18 May 2021, at 12:27, Peter Firmstone wrote: However I disagree that the Principle of least privilege is wrong headed, I think you've been discussing sandbox concepts with the experts and they're going to tell you that's a bad idea

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

to "Oracle" project members. regards, Andrew Dinn --- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 18/05/2021 10:21 am, Ron Pressler wrote: On 18 May 2021, at 01:11, Peter Firmstone wrote: Your ideas are great in theory, in practice, the problem with your Agent proposal is every JVM release needs to be reviewed, and we have to review Java's internal implementation code

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 18/05/2021 8:49 pm, Ron Pressler wrote: On 18 May 2021, at 03:39, Peter Firmstone wrote: Is it also possible to consider directing file access and network access through single points of access? This will simplify the process so we don't need to scour the entire codebase for usages

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

complacent because nothing was ever removed from Java for a very long time. We've been using it silently and efficiently for years. Regards, Peter. On 18/05/2021 7:13 pm, Alan Bateman wrote: On 18/05/2021 08:36, Peter Firmstone wrote: : It's a perception issue, I understand, but we can fix

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 18/05/2021 4:10 pm, Alan Bateman wrote: On 18/05/2021 03:39, Peter Firmstone wrote: : Yes, I realize that, it is my understanding that because this is a security concern, it is not something the community is allowed to provide support for at OpenJDK, hence my suggestion to Alan

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 18/05/2021 10:21 am, Ron Pressler wrote: On 18 May 2021, at 01:11, Peter Firmstone wrote: Your ideas are great in theory, in practice, the problem with your Agent proposal is every JVM release needs to be reviewed, and we have to review Java's internal implementation code

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

. It's your existing userbase with over 50% still using Java 8 that need convincing, who will be ultimate judge of the success or failure of this decision. Thanks for your time. -- Regards, Peter Firmstone On 18/05/2021 8:16 am, Ron Pressler wrote: On 17 May 2021, at 21:46, Peter

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

Some quick clarifications, I'll try to reply properly in the next few days. On 17/05/2021 9:29 pm, Ron Pressler wrote: On 17 May 2021, at 06:19, Peter Firmstone wrote: In versions of Java, without a security manager, the third party service provider will have AllPermission, and the user

Re: JEP411: Missing use-case: Monitoring / restricting libraries

Although JGDMS is a different type of system, this is one of the functions of SecurityManager in our system also. We have methods equivalent to Subject.doAs, which instead of injecting the privileges of the user into all ProtectionDomain's, instead prepends a ProtectionDomain that represents

JEP 411: Why the last version to support SecurityManager is likely to be the most powerful version of Java.

A disclaimer: I accept SecurityManager will be removed, but I feel a few words are in order before it's passing. A little history: Pre-1994, Bill Joy presented a proposal to Sun Labs where he presented three main concepts: 1) a language that would run on all platforms, 2) a virtual machine to

Re: JEP411: Missing use-case: Monitoring / restricting libraries

array with only one ProtectionDomain, containing the Subject. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd.

Re: JEP411: Missing use-case: Monitoring / restricting libraries

Thanks for confirming. Cheers, Peter. On 13/05/2021 10:59 pm, Sean Mullan wrote: On 5/13/21 6:00 AM, Ron Pressler wrote: On 13 May 2021, at 10:32, Peter Firmstone wrote: So it targets 17. I don’t know. I think that’s still TBD, but perhaps others know more. At this point, yes, we

Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

Re: Performance differences between Java 8,, 11, 14 and 16

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

Re: Performance differences between Java 8,, 11, 14 and 16

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

Re: Performance differences between Java 8,, 11, 14 and 16

: 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

Performance differences between Java 8,, 11, 14 and 16

versions, the results are pretty consistent to the second. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd.

Re: JEP411: Restricting/logging library usages using a SecurityManager

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

Re: JEP411: Missing use-case: Monitoring / restricting libraries

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.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

On 7/05/2021 1:17 pm, Peter Firmstone wrote: On 6/05/2021 9:46 pm, Ron Pressler wrote: That is correct. Here is where this is mentioned for ForkJoinPool: https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/ForkJoinPool.html And here it is for virtual threads

Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

Re: JEP411: Missing use-case: Monitoring / restricting libraries

will become more stable. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

complexity: https://docs.osgi.org/specification/osgi.core/8.0.0/service.condpermadmin.html -- Regards, Peter Firmstone Zeus Project Services Pty Ltd.

Re: [External] : Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

Re: JEP411: Missing use-case: Monitoring / restricting libraries

at 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 ba

Re: JEP411: Missing use-case: Monitoring / restricting libraries

application.   You are right on one respect, not enough people take security seriously. -- Regards, Peter Firmstone Zeus Project Services Pty Ltd.

Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

Re: JEP411: Missing use-case: Monitoring / restricting libraries

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

Re: JEP411: Missing use-case: Monitoring / restricting libraries

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 develo

Re: Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization?

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

Re: Java Security: JEP: 411: Deprecate the Security Manager for Removal - What about Serialization?

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

Re: New candidate JEP: 411: Deprecate the Security Manager for Removal

will say however that it appears to be slightly less performant, which is unfortunate (but hopefully fixable at some point in the future). On Thu, Apr 29, 2021 at 1:48 AM Peter Firmstone mailto:peter.firmst...@zeus.net.au>> wrote: We also use the SecurityManager for caller sensitive method

Re: New candidate JEP: 411: Deprecate the Security Manager for Removal

On 29/04/2021 10:57 pm, Sean Mullan wrote: On 4/29/21 1:37 AM, Peter Firmstone wrote: We have our own security manager implementation and policy provider implementations.  Both of these are high performance and non-blocking and we are able to dynamically grant and revoke some permissions

Re: JEP411: Missing use-case: Monitoring / restricting libraries

Having implemented SecurityManager and Policy providers, I'd like to comment on some of the assessments, some thoughts: * Poor performance, this is specific to the Java Policy implementation, I have addressed this in my implementations, performance impact is imperceptible, I know how to

Re: New candidate JEP: 411: Deprecate the Security Manager for Removal

is discovered using a SecurityManager subclass. -- Regards, Peter Firmstone 0498 286 363 Zeus Project Services Pty Ltd. On 29/04/2021 3:37 pm, Peter Firmstone wrote: Which version of Java is this planned for?   Will the last version supporting the security manager be a long term support

Re: New candidate JEP: 411: Deprecate the Security Manager for Removal

was available, perhaps indefinitely lol. Regards, Peter Firmstone Zeus Project Services Pty Ltd. On 16/04/2021 4:05 am, mark.reinh...@oracle.com wrote: https://openjdk.java.net/jeps/411 Summary: Deprecate the Security Manager for removal in a future release. The Security Manager dates

Re: JDK 14 RFR of JDK-8231262: Suppress warnings on non-serializable instance fields in security libs serializable classes

Hello, I'd make an exception for interfaces, often these are not serializable, but their implementations may be, in this case a warning would be spurious. Regards, Peter. On 20/09/2019 3:32 AM, Joe Darcy wrote: Hello, Ahead of augmenting javac's serial lint checks under JDK-8160675, it

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

security.policy" property doesn't begin with "=" (which represents java.security.policy==). Cheers, Peter. On 15/09/2019 10:58 PM, Alan Bateman wrote: On 14/09/2019 21:21, Peter Firmstone wrote: Hi Alan, We've got a bunch of very old policy files in our test suite, so they sti

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

{ permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.crypto.mscapi" { permission java.security.AllPermission "", ""; }; grant codebase "jrt:/jdk.localedata" { permission java.security.AllPermission &q

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

provider as the java.ext.dirs property is now blank, I also had to grant permissions to a number of jdk modules, after fixing these, everthing running as expected, except for a few minor test failures. Next step will be to test against the EA builds. On 17/08/2019 7:24 AM, Peter Firmstone wrote

Re: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

I probably should have vetted this before hitting send... let me know if you need any clarifications. Cheers, Peter. On 23/08/2019 12:59 PM, Peter Firmstone wrote: "...since at the time the industry believed that distributed objects were going to save us from complexity.) Many of the

Re: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

ron out the wrinkles. :) Regards, Peter. On 23/08/2019 7:36 AM, Peter Firmstone wrote: Hi Sean, Regarding the section entitled "Why not write a new serialization library?", unlike the serialization libraries listed, our purpose was to be able to securely deserialize untrusted data, whil

Re: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

k.java.net/~briangoetz/amber/serialization.html --Sean On 8/17/19 10:22 PM, Peter Firmstone wrote: Thanks Sean, You've gone to some trouble to answer my question, which demonstrates you have considered it. I donate some time to help maintain Apache River, derived from Sun's Jini. Once Jin

Re: Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

have copied him. Not sure if you have seen it but he recently posted a document about some of his ideas and possible future directions for serialization: http://cr.openjdk.java.net/~briangoetz/amber/serialization.html --Sean On 8/17/19 10:22 PM, Peter Firmstone wrote: Thanks Sean, You've gone

Serialzation PREVIOUSLY: RFR: 8229773: Resolve permissions for code source URLs lazily

of maintenance developer time. Regards, Peter. On 17/08/2019 12:50 AM, Sean Mullan wrote: On 8/15/19 8:18 PM, Peter Firmstone wrote: Hi Roger, +1 for writeReplace Personally I'd like to see some security classes break backward compatibility and remove support for serialization as it all

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

on coming EA builds would be greatly appreciated! One thing we could do on the JDK end to reduce fragility somewhat in this area is to provoke initialization of sun.security.util.SecurityConstants before installing the first SM. /Claes On 2019-08-16 12:40, Peter Firmstone wrote: Hello Alan, Yes, we

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

/08/2019 5:04 PM, Alan Bateman wrote: On 15/08/2019 23:20, Peter Firmstone wrote: : The following code is included in the constructor of our SecurityManager implementation, I suspect we may need to add some classes to this list, perhaps this is something that needs documenting

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hello Alan, This is related to URL and CodeSource and might be worth making a note of for future reference. Our software uses delayed dynamically assigned permissions via a policy provider, but for privileged domains that have AllPermission we make sure to assign this up front (We also

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hello Claes, The following code is included in the constructor of our SecurityManager implementation, I suspect we may need to add some classes to this list, perhaps this is something that needs documenting? Regards, Peter. /* The following ensures the classes we need are loaded early to

Re: RFR: 8229773: Resolve permissions for code source URLs lazily

Hi Roger, +1 for writeReplace Personally I'd like to see some security classes break backward compatibility and remove support for serialization as it allows someone to get references to internal objects, especially since these classes are cached by the JVM. Which makes

Re: -Djava.security.manager=problems for service providers

, it looks like you are using JDK 8 or older. There are several changes in JDK 9 and newer in the PolicyFile code to how it loads its resources that may help with the issues you are seeing. -Alan On 27/03/2018 13:56, Peter Firmstone wrote: Not sure if this is the right place to mention

Re: Strange test failure when referencing a class in a deprivileged module

device.     Include original message Original message From: Peter Firmstone <peter.firmst...@zeusnet.au> Sent: 08/07/2016 05:53:47 pm To: WeijunWang <weijun.w...@oracle.com> Cc: jigsaw-dev <jigsaw-...@openjdk.java.net>; OpenJDK <security-dev@openjdk.java.net> S

Re: Strange test failure when referencing a class in a deprivileged module

, as these create recursive calls that can become infinite, but this won't occur in your simple test case. Regards, Peter. Sent from my Samsung device.      Include original message Original message From: Weijun Wang <weijun.w...@oracle.com> Sent: 08/07/2016 01:18:56 pm To: Peter Fir

Re: Strange test failure when referencing a class in a deprivileged module

Original message From: Wang Weijun <weijun.w...@oracle.com> Sent: 07/07/2016 01:45:08 pm To: Peter Firmstone <peter.firmst...@zeus.net.au> Cc: SeanMullan <sean.mul...@oracle.com>; jigsaw-dev <jigsaw-...@openjdk.java.net>; OpenJDK <security-dev@openjdk.javanet> Subject:

Re: Strange test failure when referencing a class in a deprivileged module

From: Wang Weijun <weijun.w...@oracle.com> Sent: 07/07/2016 06:55:26 pm To: Peter Firmstone <peter.firmst...@zeus.net.au> Cc: SeanMullan <sean.mul...@oracle.com>; jigsaw-dev <jigsaw-...@openjdk.java.net>; OpenJDK <security-dev@openjdk.java.net> Subject: Re: Strange

Re: Strange test failure when referencing a class in a deprivileged module

Yes, that's correct. ;) Sent from my Samsung device.     Include original message Original message From: Alan Bateman Sent: 07/07/2016 06:37:49 pm To: Wang Weijun Cc: jigsaw-dev ; OpenJDK

Re: Strange test failure when referencing a class in a deprivileged module

:58 am To: Peter Firmstone <peter.firmst...@zeus.net.au> Cc: SeanMullan <sean.mul...@oracle.com>; jigsaw-dev <jigsaw-...@openjdk.java.net>; OpenJDK <security-dev@openjdk.java.net> Subject: Re: Strange test failure when referencing a class in a deprivileged module > 

Re: Strange test failure when referencing a class in a deprivileged module

Perhaps the policy provider hasn't been refreshed when the new security manager is in force?  Try doing a Policy.refresh() in the SecurityManager constructor. Regards, Peter. Sent from my Samsung device.     Include original message Original message From: Wang Weijun

Re: Strange test failure when referencing a class in a deprivileged module

; Sent: 07/07/2016 06:27:43 pm To: Peter Firmstone <peter.firmst...@zeus.net.au> Cc: SeanMullan <sean.mul...@oracle.com>; jigsaw-dev <jigsaw-...@openjdk.java.net>; OpenJDK <security-dev@openjdk.java.net> Subject: Re: Strange test failure when referencing a class i

Re: The future of Serialization

Brian, Thanks for picking up on my frustration ;) I have something in mind for Serializable2 to address cyclic data structures and the possibility of independant evolution of super and child classes, while retaining a relatively clean public api, with one optional private method. The

Re: The future of Serialization

On 11/08/2014 8:12 PM, Peter Firmstone wrote: Brian, Thanks for picking up on my frustration ;) I have something in mind for Serializable2 to address cyclic data structures and the possibility of independant evolution of super and child classes, while retaining a relatively clean public api

Re: The future of Serialization

/RJ.pdf https://www.cs.purdue.edu/homes/peugster/Ribbons/ Got any links to info on extending access control rules? Regards, Peter. On 11/08/2014 9:21 PM, Alan Bateman wrote: On 09/08/2014 06:56, Peter Firmstone wrote: I've noticed there's not much interest in improving Serialization on these lists

The future of Serialization

I've noticed there's not much interest in improving Serialization on these lists. This makes me wonder if java Serialization has lost relevance in recent years with the rise of protocol buffers apache thrift and other means of data transfer over byte streams. The burden of implementing

Re: JEP Review Request: Improve Security Manager Performance

No David is right, the code will run with the privileges of it's own ProtectionDomain, so if that PD is not trusted, the code cannot bypass security checks from static initializers. This does not break secure by default. A static initializer can write to static fields, but public or protected

Re: Policy provider comparison

confinement fixes that too. Regards, Peter. On 19/07/2014 6:31 PM, Peter Firmstone wrote: Thought I might provide a comparison using our random stress test on a 4 way sony vaio, JDK7 Windows 7 amd64: Note that using sun.security.provider.PolicyFile doubles the duration of the stress test

Concurrent Policy provider

(Peter Firmstone) 2. Re: ThreadLocalRandom clinit troubles (Alan Bateman) -- Message: 1 Date: Mon, 30 Jun 2014 20:02:30 +1000 From: Peter Firmstonepeter.firmst...@zeus.net.au To: Peter Levartpeter.lev...@gmail.com Cc

JEP Improve Security Manager Performance

. This kind of thing sounds like exactly the sort of thing that would fit in under that initiative, IMO. [1] http://mail.openjdk.java.net/pipermail/security-dev/2014-April/010432.html On 07/10/2014 10:00 PM, Peter Firmstone wrote: Would there be interest in using a Policy provider and SecurityManager

<    1   2