On 6/1/21 1:30 PM, Chapman Flack wrote:
On 06/01/21 12:32, Sean Mullan wrote:
On 6/1/21 2:11 AM, Peter Firmstone wrote:
Would have really liked to have known about that.
It was announced on jdk-dev at the time it was launched, with a follow-up
reminder one week later:
On 06/01/21 12:32, Sean Mullan wrote:
> On 6/1/21 2:11 AM, Peter Firmstone wrote:
>> Would have really liked to have known about that.
>
> It was announced on jdk-dev at the time it was launched, with a follow-up
> reminder one week later:
>
>
The survey was also shared by @java to its many followers, fwiw:
https://twitter.com/java/status/961296752732135424?s=20
and through the OpenJDK Quality Outreach to the many projects
participating there:
https://mail.openjdk.java.net/pipermail/quality-discuss/2018-February/000749.html
If
On 6/1/21 2:11 AM, Peter Firmstone wrote:
Would have really liked to have known about that.
It was announced on jdk-dev at the time it was launched, with a
follow-up reminder one week later:
https://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html
--Sean
Any chance
On 01.06.2021 08:11, Peter Firmstone wrote:
Any chance Java 17 LTS (hopefully with sorted security manager
property), can be supported as long as Java 8, 16 years?
According to the Oracle Java SE Support Roadmap at
https://www.oracle.com/java/technologies/java-se-support-roadmap.html
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
On 01/06/2021 01:11, Chapman Flack wrote:
On 05/31/21 03:59, Alan Bateman wrote:
The SM survey in 2018 showed that there was some usage too.
Out of curiosity, where can I learn more about this survey?
Was it the kind of survey that, if I had been hanging around in the right
places in 2018, I
On 05/31/21 03:59, Alan Bateman wrote:
> The SM survey in 2018 showed that there was some usage too.
Out of curiosity, where can I learn more about this survey?
Was it the kind of survey that, if I had been hanging around in the right
places in 2018, I might have been solicited to respond to?
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
On 31/05/2021 08:11, Peter Firmstone wrote:
:
I think also that many more people are using SecurityManager than
OpenJDK realises, and they're not using it how OpenJDK recommends
either, (AllPermission granted to trusted code, and sandbox untrusted
code model of Applets is not how we use it)
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
> In reply to Ron Pressier:
> Do you regularly use the Security Manager to sandbox your own dependencies
> and find it convenient and effective
> — in which case, could you please describe your practice concretely so that
> it would be possible to consider
> alternatives — or are you saying that
On 22/05/2021 11:58, Bernd Eckenfels wrote:
:
This whole discussion about using only secure libraries really makes
me wonder if you know the realities of modern applications with
hundreds of dependencies and the state of those, like there is still
no easy way to limit XXE in upstream xerces.
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> Von: security-dev im Auftrag von Peter
> Tribble
> Gesendet: Saturday, May 22, 2021 11:11:43 AM
> An: Ron Pressler
> Cc: Peter Firmstone ; David Black
> ; Alan Bateman ;
> security-dev@openjdk.java.
:43 AM
An: Ron Pressler
Cc: Peter Firmstone ; David Black
; Alan Bateman ;
security-dev@openjdk.java.net
Betreff: Re: [External] : Re: JEP411: Missing use-case: Monitoring /
restricting libraries
On Sat, May 22, 2021 at 2:12 AM Ron Pressler
mailto:ron.press...@oracle.com>> wrote:
On Sat, May 22, 2021 at 2:12 AM Ron Pressler
wrote:
> Let me be very clear: the proposers of this JEP, some of whom have worked
> on the Security Manager for the
> last twenty years, strongly believe that not only will its removal not
> harm Java’s security, but considerably
> improve it, as do
Studies, experts, meetings and academics, without practical application
of the principle of least privilege, these are meaningless. I hope
someone remembered to bring tea and scones.
My point is nothing gets done without workers. It's the Pareto
Principle or 80:20 rule. Li Gong may have
Let me be very clear: the proposers of this JEP, some of whom have worked on
the Security Manager for the
last twenty years, strongly believe that not only will its removal not harm
Java’s security, but considerably
improve it, as do the maintainers of other platforms who have decided to either
I had hoped by end of this discussion, that there would at least be an
understanding of what OpenJDK is so hastily choosing to destroy.
Once it is gone, it will be irretrievable, it will never be possible to
lock down the JVM so securely again.
On 21/05/2021 11:06 pm, Ron Pressler wrote:
> On 21 May 2021, at 12:52, Peter Firmstone wrote:
>
> It's quite clear this will be pushed through anyway,
>
No, not *anyway*, but given the fact that the community consists of millions of
users, this
proposal has been well-publicised, only very few people have voiced objections,
fewer
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
> On 21 May 2021, at 11:29, Peter Firmstone wrote:
>
>
> Can you share this list please? If I see anything missing I can add it for
> you.
No, because this might give the false impression that this is a debate. In a
community
of millions, almost no decision will be universally accepted.
On 21.05.2021 03:40, Peter Firmstone wrote:
If there are those of us who wanted to maintain a fork of Java 17,
focused on security, we could backport new features after they've been
reviewed for security.
Would we be welcomed to do that here? Otherwise is it something we
should do on
On 21/05/2021 6:58 pm, Ron Pressler wrote:
These are just opinions, it's nice to have them, but they're not
helping. I think you'll find usages of SecurityManager api's are far
more widespread than your opinion suggests, but that's just my
opinion too lol.
I guess you could say they’re my
> On 21 May 2021, at 04:55, Peter Firmstone wrote:
>
>
> Yes everything is a compromise and there are trade-offs. The way I see it,
> the cheapest way to maintain security is to find others who share a common
> pain point is to maintain a copy of OpenJDK focused on security. We can
>
On 18/05/2021 10:09 pm, Ron Pressler wrote:
On 18 May 2021, at 12:27, Peter Firmstone wrote:
However I disagree that the Principle of least privilege is wrong headed, I
think you've been discussing sandbox concepts with the experts and they're
going to tell you that's a bad idea. But
If there are those of us who wanted to maintain a fork of Java 17,
focused on security, we could backport new features after they've been
reviewed for security.
Would we be welcomed to do that here? Otherwise is it something we
should do on GitHub?
Cheers,
Peter.
On 21/05/2021 11:25 am,
On Thu, 20 May 2021 at 21:27, Andrew Dinn wrote:
>
> On 18/05/2021 23:06, David Black wrote:
> > I don't think that this thinking is unique but it might not be worth
> > the "cost" to Oracle to maintain something that seemingly for various
> > reasons Oracle has little interest in maintaining
On 18/05/2021 23:06, David Black wrote:
I don't think that this thinking is unique but it might not be worth
the "cost" to Oracle to maintain something that seemingly for various
reasons Oracle has little interest in maintaining (we're not in
applet-land anymore). I would like to encourage
On 18/05/2021 10:21 am, Ron Pressler wrote:
On 18 May 2021, at 01:11, Peter Firmstone wrote:
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to review
Java's internal implementation code, and
On Tue, 18 May 2021 at 22:24, Ron Pressler wrote:
>
>
> > On 18 May 2021, at 07:10, David Black wrote:
> >
> >
> > I hope you aren't being rude on purpose by continuing to 1) top post
> > and 2) not ignore various parts of my emails.
> >
>
> This isn’t a debate forum. We’re trying to collect
> On 18 May 2021, at 07:10, David Black wrote:
>
>
> I hope you aren't being rude on purpose by continuing to 1) top post
> and 2) not ignore various parts of my emails.
>
This isn’t a debate forum. We’re trying to collect information, not
to convince every last person. I respond to what I
> On 18 May 2021, at 12:27, Peter Firmstone wrote:
>
>
> However I disagree that the Principle of least privilege is wrong headed, I
> think you've been discussing sandbox concepts with the experts and they're
> going to tell you that's a bad idea. But the two aren't the same, one is
>
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
> On 18 May 2021, at 03:39, Peter Firmstone wrote:
>
>
> Is it also possible to consider directing file access and network access
> through single points of access? This will simplify the process so we don't
> need to scour the entire codebase for usages.
>
Of all your suggestions, I
Because people have been treating it like a sandbox.
Since it will take a number of years, can we at least consider my
proposal and give it a try? It may reduce the burden in the interim.
So this step deprecates it for removal, can we create a JEP for
replacing the SecurityManager with
On 18/05/2021 08:36, Peter Firmstone wrote:
:
It's a perception issue, I understand, but we can fix that far less
painfully.
With respect, I don't see a viable route here. SM/AccessController and
most of that security architecture has been an albatross around our
necks for years. This
On 18/05/2021 4:10 pm, Alan Bateman wrote:
On 18/05/2021 03:39, Peter Firmstone wrote:
:
Yes, I realize that, it is my understanding that because this is a
security concern, it is not something the community is allowed to
provide support for at OpenJDK, hence my suggestion to Alan, to
Hi,
On Tue, 18 May 2021 at 10:13, Ron Pressler wrote:
>
> We can call any mechanism that might impose restrictions a mitigation, but
> that
> doesn’t mean that any mechanism is worth its cost. I believe that the evidence
> gathered over the past few decades shows that attempting to assign
On 18/05/2021 03:39, Peter Firmstone wrote:
:
Yes, I realize that, it is my understanding that because this is a
security concern, it is not something the community is allowed to
provide support for at OpenJDK, hence my suggestion to Alan, to make
it possible for this to happen by changing
On 18/05/2021 10:21 am, Ron Pressler wrote:
On 18 May 2021, at 01:11, Peter Firmstone wrote:
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to review
Java's internal implementation code, and
> On 18 May 2021, at 01:11, Peter Firmstone wrote:
>
> Your ideas are great in theory, in practice, the problem with your Agent
> proposal is every JVM release needs to be reviewed, and we have to review
> Java's internal implementation code, and understand it in order to instrument
> it.
We can call any mechanism that might impose restrictions a mitigation, but that
doesn’t mean that any mechanism is worth its cost. I believe that the evidence
gathered over the past few decades shows that attempting to assign different
permissions to code of different origin in the same process
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to
review Java's internal implementation code, and understand it in order
to instrument it. But I do appreciate you took the time to do your
homework to
Hi Ron,
On Mon, 17 May 2021 at 21:38, Ron Pressler wrote:
>
> I would say that trying to mitigate attacks on vulnerabilities in trusted
> code based on specific code paths is
> not recommended. You’re trying to preemptively defend agains something
> complex — a security bug — with
> another
> On 17 May 2021, at 21:46, Peter Firmstone wrote:
>
>
> Yes, you are talking about those who maintain and develop OpenJDK, but this
> is only a small proportion of the overall Java developer ecosystem.
Not at all. I’m talking about the millions of developers who don’t get what
they
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
> On 17 May 2021, at 13:47, Peter Firmstone wrote:
>
> It is a foundational feature, it has a significant impact on those who
> adopted it.
True. But the problem is that it also has a significant impact on those who
didn’t.
>
>
> This is an existing system, your arguments are not
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
I would say that trying to mitigate attacks on vulnerabilities in trusted code
based on specific code paths is
not recommended. You’re trying to preemptively defend agains something complex
— a security bug — with
another complex mechanism. Even if you do happen to defend against a particular
> On 17 May 2021, at 06:19, Peter Firmstone wrote:
>
>
> In versions of Java, without a security manager, the third party service
> provider will have AllPermission, and the user will have restricted
> permissions (if we still have some form of user Permission based access
> control).
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
Hi Ron
On Thu, 13 May 2021 at 20:22, Ron Pressler wrote:
>
>
>
> > On 13 May 2021, at 03:11, David Black wrote:
> >
> >
> > This seems somewhat more useful than 1 & 2 but imho it would be better to
> > be able to perform checks/grant access on a call stack basis.
>
> This is an important point
On 13/05/2021 10:59 pm, Sean Mullan wrote:
The JEP does have a section on this:
"In future JDK releases, we may degrade the Security Manager APIs so
that they remain in place but have limited or no functionality. For
example, we may revise AccessController::doPrivileged simply to run
the
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
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
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
Auftrag von Peter
Tribble
Gesendet: Thursday, May 13, 2021 9:25:25 AM
An: Ron Pressler
Cc: Alan Bateman ; Peter Firmstone
; security-dev@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
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
> 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
> 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
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
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,
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
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
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
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
> 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
> 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
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
> 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
>
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
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.
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
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
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
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,
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
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
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
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
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
On 2021-05-06T11:46:33 +
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
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
> 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
>
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
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,
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
> 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
>
-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.
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
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
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
On 4 May 2021, at 03:49, Peter Firmstone
mailto:peter.firmst...@zeus.net.au>> 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,
On 29 Apr 2021, at 13:06, Peter Firmstone
mailto:peter.firmst...@zeus.net.au>> 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
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
Thanks Chris,
I like that approach very much.
Thanks again
Markus
From: Chris Hegarty
Sent: den 28 april 2021 12:51
To: Markus Gronlund
Cc: Lim ; Ron Pressler
; security-dev@openjdk.java.net
Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries
On 28 Apr 2021, at 11
den 28 april 2021 12:18
To: Markus Gronlund
mailto:markus.gronl...@oracle.com>>
Cc: Ron Pressler mailto:ron.press...@oracle.com>>;
security-dev@openjdk.java.net<mailto:security-dev@openjdk.java.net>
Subject: Re: JEP411: Missing use-case: Monitoring / restricting libraries
Hi Mar
Hi Lim,
JFR specific feedback can be posted to: hotspot-jfr-...@openjdk.java.net
Thanks
Markus
-Original Message-
From: Lim
Sent: den 28 april 2021 12:18
To: Markus Gronlund
Cc: Ron Pressler ; security-dev@openjdk.java.net
Subject: Re: JEP411: Missing use-case: Monitoring
On Wed, Apr 21, 2021 at 8:38 PM Ron Pressler wrote:
> Its current events might be not have everything you want, but will be
> expanded, in
> part to address the functionality that will be lost with the removal of
> Security Manager.
I agree that monitoring needs to be improved since there is a
1 - 100 of 120 matches
Mail list logo
