A comment from Ron highlites our issue:
the JDK contains only things that either only the JDK can technically do
We have a need to distinguish between different sources of code, as well
as user principles, and as well as Services. Our services are loaded
by separate ClassLoaders and are to
On 06/02/21 19:41, Peter Firmstone wrote:
> We need the power of AccessController's stack walk, StackWalker doesn't work
> with compiled code, only bytecode.
Is this correct? I have not tried it, but the apidocs had led me to
understand it did not distinguish much between JITed and interpreted cod
On 03/06/2021 01:04, Chapman Flack wrote:
On 06/02/21 19:41, Peter Firmstone wrote:
We need the power of AccessController's stack walk, StackWalker doesn't work
with compiled code, only bytecode.
Is this correct? I have not tried it, but the apidocs had led me to
understand it did not distin
Apologies, I meant when compiled to native code, when you ship native
binaries.
Having said that, if it's necessary to use StackWalker behind
AccessController.doPrivileged going forward then lets do so, and maybe
the native binary is a later feature.
Hopefully my proposal is getting some con
On 03/06/2021 08:28, Peter Firmstone wrote:
Apologies, I meant when compiled to native code, when you ship native
binaries.
I'm not sure what you mean here. Are you talking about native binaries
as generated by the GraalVM Native Image Generator? If you are
suggesting there is a disparity in
On 6/2/21 7:41 PM, Peter Firmstone wrote:
AccessController and AccessControlContext allow backward compatiblity
for JAAS. JAAS whether we like it or not, is the default authorisation
layer framework.
http://word-bits.flurg.com/jaas-is-terrible-and-there-is-no-escape-from-it/
I'm not su
Hi Sean,
Developers are still going to need single points of control, where we
can attach our agents to Java's API's. We can't be playing a game of
whack a mole trying to lock down the JDK.
It's fair enough that OpenJDK no longer wishes to maintain
SecurityManager, however there are those
Sean,
Also moving forward we currently preserve AccessControlContext across
threads, and we do this to establish TLS connections for call backs.
Will there be a new way to preserve the calling Subject across threads,
so we can perform callbacks over TLS?
Regards,
--
Regards,
Peter Firmst
> On 3 Jun 2021, at 00:41, Peter Firmstone wrote:
>
>
> StackWalker doesn't work with compiled code, only bytecode.
If you’re referring to GraalVM’s Native Image, I don’t know about that problem
and
there does seem to be a relevant patch
(https://github.com/oracle/graal/pull/734), but
Nati
Ok, thanks Ron,
I think we are confirming that Java, post version 17, will not meet the
security needs our software. It's time I accepted that and moved on.
Thanks for your time.
Have you seen my latest article on foojay? Feel free to comment and
let me know what you think.
https://fooj
It is certainly time to accept that JEP 411 has been accepted, and so that those
who use Security Manager will need to do some work to change their software.
The purpose of this and upcoming discussions is to find reasonable approaches
that might relieve some portion of the burden on those who use
Yes, I think so too. However I will encourage developers to continue to
take advantage of SM for improved security now, there's no need to rush
to abandon it.
Maybe in future there will be better alternatives, but it's the best
option for those who are security focused now.
With time no dou
12 matches
Mail list logo
