at a significant disadvantage.
Regards,
Peter.
On 2/05/2022 5:24 pm, arjan tijms wrote:
Hi,
On Monday, May 2, 2022, Peter Firmstone
wrote:
I guess I'm just trying to say we need more time, the process of
extricating SM for security will take years, if we can leave SM as
it is in deprecated
Our software was never designed to run without SM enabled. We will need
to instrument the Java API's with some access controls, this will be
reliant on the removal of finalizers, or the option to disable them.
In our case deserialization is decided by the permission granted to the
, the attacker would probably be unable to penetrate the jvm,
but still could potentially steal data.
On 28/04/2022 3:25 pm, Peter Firmstone wrote:
Hi Martin,
Your arguments are the reasons why we use the principle of least
privilege. It creates a headache for attackers, similar to the
developer
Hi Martin,
Your arguments are the reasons why we use the principle of least
privilege. It creates a headache for attackers, similar to the
developer who's enabled SM for the first time and must manually add
every required permission for their software to function (who thought
that was a
Well said, we're not trying to sandbox untrusted code. We're simply
trying to provide authorization controls on authenticated users and in
my particular case, service proxy's. It's well known the JVM can't
handle untrusted code, nor does it have well designed defenses against
parsing
On 26/04/2022 8:10 pm, Alan Bateman wrote:
On 26/04/2022 10:06, Peter Firmstone wrote:
:
What about ensuring that all network access occurs through a single
location that we can instrument?
Network, file, and process launch are potentially interesting but
instrumenting them to run
On 26/04/2022 6:28 pm, Alan Bateman wrote:
On 25/04/2022 13:53, David Lloyd wrote:
Nothing in the proposal causes splitting or delegation of
responsibilities. It is _only_ about preserving security checkpoints
in the JDK, which *add* a layer of checks to what the container might
already
rs can be disabled.
--
Regards,
Peter Firmstone
Hi Martin,
I'm curious, you sound like you arrived at this opinion from
experience? Rather than being an upper layer only concern, my opinion
is that it requires lower layer intervention / controls, with upper
layers providing the decision making context.
My reason for asking is, we're
/8349
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
/java/org/apache/river/api/io/AtomicMarshalInputStream.java#L853
Would be nice to do some testing with the changes.
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
On 18/04/2022 2:24 am, liach wrote:
Convert dynamic proxies to hidden classes. Modifies the serialization
flag be provided to
disable jvm calls to finalizer methods.
--
Regards,
Peter Firmstone.
Thanks for trying David. :)
Regards,
Peter.
On 8/04/2022 7:15 pm, Andrew Dinn wrote:
I'm 100% in agreement with Sean. This proposal leaves the OpenJDK team
with just as much -- or possibly more -- code to maintain, test and
design around while making the behaviour under the retained API less
Hi Sean,
In order to keep our code up to date with Java, we need to replace
access control functionality. Current advise is that we will need to
instrument the Java API, once finalizers have been removed.
The sticking point is about the retention of permission checks, which
haven't been
Looks good to me, removes credentials when phantom reachable, doesn't do
anything that would prevent it from becoming reachable. You removed the
GNSSException that wasn't thrown.
Regards,
Peter.
On 7/04/2022 2:17 pm, Xue-Lei Andrew Fan wrote:
Please review the update to remove finalizer
Thanks David,
I'd certainly support such a proposal and encourage OpenJDK to consider
exploring it.
Perhaps also consider; no privileges should be granted unless a
privileged call is made, this simplifies the the stack walk, such that
it's only required when a privileged call is made.
Hi Olivier,
After JEP 421 (deprecation of finalizers) and a JEP is assigned to
removal of finalizers, it will be possible to instrument java methods
and intercept their calls. While finalizers exist, instrumenting
constructors would allow finalizer attacks to circumvent the permission
. The instructions on the JGDMS page look pretty
straightforward, so hopefully that won't take long to replicate.
Thanks,
--Jamil
On 8/11/2021 3:12 AM, Peter Firmstone wrote:
谢谢johnsjiang(江莎)，
I set the property:
-Djdk.tls.acknowledgeCloseNotify=true.
Unfortunately the test is still failing on JDK17
AEST|ClientHello.java:652|Produced
ClientHello handsha
On 11/08/2021 7:22 pm, johnsjiang(江莎) wrote:
+ security-dev
Hi Peter,
It looks both of file 1 and 5 contain that close_notify warning alert.
This point may be related to JDK-8208526: TLS 1.3 half-close and
synchronization issues [1].
atch this space, I'll post a link when ready.
Regards,
Peter.
On 5/08/2021 7:27 am, Sean Mullan wrote:
On 8/3/21 8:10 PM, Peter Firmstone wrote:
On 4/08/2021 2:40 am, Sean Mullan wrote:
On 8/2/21 8:28 PM, Peter Firmstone wrote:
In JGDMS without SM, at least the following must be addre
Maybe we need some criteria, that defines what's not easily instrumented?
On 4/08/2021 10:19 am, Peter Firmstone wrote:
Excellent, Ron, that's exactly what I'm after.
I need to be able to implement an authorization layer on top of the
JDK, but reach down into the JDK to use authorization
Maybe we should have a mailing list dedicated to this where we can
discuss and potentially collaborate?
Regards,
Peter.
On 3/08/2021 10:15 pm, Ron Pressler wrote:
On 3 Aug 2021, at 12:50, Peter Firmstone wrote:
Can you think of any workable alternative compromises?
If you mean
On 4/08/2021 2:40 am, Sean Mullan wrote:
On 8/2/21 8:28 PM, Peter Firmstone wrote:
In JGDMS without SM, at least the following must be addressed to
maintain security:
1. TLS and Kerberos connections cannot be established. (My
software is
littered with doPrivileged calls
to strong encapsulation; quite
the opposite.
— Ron
On 3 Aug 2021, at 10:44, Peter Firmstone wrote:
Thanks Ron, reply inline.
On 3/08/2021 6:48 pm, Ron Pressler wrote:
On 3 Aug 2021, at 06:48, Peter Firmstone
wrote:
We can still use these without an SM, Policy or Permissions
Wow, thanks Andrew,
There's certainly some complexity there, I appreciate your guidance.
Regards,
Peter.
On 3/08/2021 7:11 pm, Andrew Dinn wrote:
On 03/08/2021 02:30, Peter Firmstone wrote:
Just curious, when using Agents, what are the recommendations for
line numbers in code
Thanks Ron, reply inline.
On 3/08/2021 6:48 pm, Ron Pressler wrote:
On 3 Aug 2021, at 06:48, Peter Firmstone wrote:
We can still use these without an SM, Policy or Permissions for authorization
decisions, as mentioned previously I'd replace the inherited thread context
On 3/08/2021 6:31 pm, Ron Pressler wrote:
On 3 Aug 2021, at 02:30, Peter Firmstone wrote:
I am still hopeful that OpenJDK might create some hooks for us and keep the
AccessController, AccessControlContext and Subject.doAs methods to make
supporting all Java versions easier.
When I
ectionDomain::Implies(Permission) to make authorization decisions.
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/security/CombinerSecurityManager.java
--
Regards,
Peter
On 3/08/2021 11:30 am, Peter Firmstone wrote:
Thanks Ron,
Wh
.
The default security policy today is already more restrictive than it was a
couple of versions ago, and we expect it to become
even more restrictive.
— Ron
On 2 Aug 2021, at 11:33, Peter Firmstone wrote:
Hello Andrew,
I think you may be misinterpreting my comment, let me clarify:
I'm assuming
same and direct your attack onto
problems, rather than people.
Thank you.
Peter.
On 2/08/2021 11:07 pm, Andrew Dinn wrote:
On 02/08/2021 11:33, Peter Firmstone wrote:
I think you may be misinterpreting my comment, let me clarify:
Really? I'd suggest only if you stretch the meaning of your words
be
Hello Andrew,
I think you may be misinterpreting my comment, let me clarify:
I'm assuming that during the process of removal of security manager, any
external ports or process hooks that we can only turn off now by not
granting a permission will be replaced by a command line property or
Pv6, and constrains the software in many other areas as
well, so it's not being considered at this time.
Regards,
Peter.
On 2/08/2021 4:23 pm, Florian Weimer wrote:
* Peter Firmstone:
From our discussions, my interpretation is that OpenJDK is constrained
by corporate security policy; any issu
On 2/08/2021 4:48 am, Alan Bateman wrote:
On 01/08/2021 15:28, Uwe Schindler wrote:
:
What I figured out: You intend to remove SecurityManager because it
does not fit your latest ideas how Java threads should behave. I know
the main problem is not "SecurityManager is too complex / too slow /
ore people would use it, and I
hope to see it used in
the JDK as well. Java has several PBT tools, but I believe the most popular one
these days is
https://jqwik.net/. As long as you’re still with Java, give it a try.
— Ron
On 31 Jul 2021, at 04:04, Peter Firmstone wrote:
The current JE
to removal of SM.
Regards,
Peter.
On 31/07/2021 5:35 pm, Alan Bateman wrote:
On 31/07/2021 04:04, Peter Firmstone wrote:
Allan has advised when finalizers are removed, it will be practical
to use Agents to instrument public API to implement an authorization
layer, this is try, so can
The current JEP 411 plan of action, if left unchanged, will leave
developers who adopted the SM architecture as an authorization layer
unable to upgrade to later versions of Java, until finalizers and the
finalizer attack defensive methods in constructors are removed. JEP 411
has the
Appended inline below.
On 29/07/2021 11:20 am, Peter Firmstone wrote:
The intent of the following process is to perform a targeted audit,
which allows inspection of small parts of the code identified by these
steps.
On 28/07/2021 9:12 am, Peter Firmstone wrote:
Our process
The intent of the following process is to perform a targeted audit,
which allows inspection of small parts of the code identified by these
steps.
On 28/07/2021 9:12 am, Peter Firmstone wrote:
Our process for establishing whether third party libraries are trusted
before we use them:
1
wrote:
*From: *"Peter Firmstone"
*To: *"Remi Forax" , "Alan Bateman"
*Cc: *"jdk-dev" , "security-dev"
*Sent: *Wednesday, July 28, 2021 1:12:32
On 28/07/2021 9:12 am, Peter Firmstone wrote:
While its possible to use a dynamic proxy without downloading code,
via an atomic serialization connection, it's not generally advised to
do so with unauthenticated users, decisions around dynamic discovery,
whether class loading or downloads
vulnerabilities.
buffy$ uname -a
OpenBSD buffy.lan 6.7 GENERIC.MP#310 sparc64
Although this one's a couple of versions behind, time for an upgrade.
Regards,
Peter.
On 28/07/2021 5:52 am, fo...@univ-mlv.fr wrote:
- Original Message -
From: "Alan Bateman"
To: "Remi
vestigation.
I do appreciate that you took the time to respond to my emails.
Regards,
Peter.
On 26/07/2021 12:44 am, Alan Bateman wrote:
On 23/07/2021 23:33, Peter Firmstone wrote:
I think it's worth noting that there isn't a way to securely run code
with malicious intent now,
, etc.
Rather than a sandbox, it just needs to be safer, with the ability to
allow access to the underlying Java / C / etc, to trusted /
authenticated / verified entities.
If anyone has any ideas regarding suitable languages, I'd be very
interested to hear your thoughts.
--
Regards,
Peter Firmstone
. Arguably we can do things now
that aren't possible on other platforms, so we need to develop that
capability as well, not just secure it.
Regards,
Peter.
On 23/07/2021 9:45 pm, Alan Bateman wrote:
On 23/07/2021 11:48, Peter Firmstone wrote:
Perhaps the solution is to replace the entire
levels as well using bit shift operations
on primitives, that are magnitudes faster than standard string
operations. TLS ran so much faster with stateless session tickets too.
Regards,
Peter.
On 23/07/2021 9:45 pm, Alan Bateman wrote:
On 23/07/2021 11:48, Peter Firmstone wrote:
Perhaps
the
original JVM with classes from the fork?
I sure wish there was a better option, if anyone knows one, I'm all ears.
Regards,
Peter.
On 23/07/2021 6:36 pm, Peter Firmstone wrote:
Post JEP 411, we need to write Agents to replace the current
permission checks performed within the JVM
created support for
obtaining the Subject from the Authorization context, in my
authorization layer software (linked above), but instrumenting private
methods in the JDK goes against all previously learned best practices.
--
Regards,
Peter Firmstone
Code snippet from java.lang.ClassLoader
JEP 411 is quite a conundrum for downstream developers that depend on SM.
SecurityManager has its problems, but it's the only authorization layer
we have.
If I had a complaint about SM, it's the implementation of:
1. SocketPermission doesn't allow netmask wild cards.
2. Thread inherited
Thanks Sean,
Be nice if it can be implemented in a way that allows it to be decorated.
Regards,
Peter.
On 19/07/2021 10:29 pm, Sean Mullan wrote:
On 7/17/21 9:13 PM, Peter Firmstone wrote:
My mistake copied wrong bug:
Has there been any progress with the new Subject API?
https
OMAINS.add(cl.getProtectionDomain());
} finally {
INHERITED_CONTEXT.set(authorization);
}
}
On 16/07/2021 2:20 pm, Peter Firmstone wrote:
I'm currently experimenting with a new authorization layer for java,
post JEP 411.
I would like your thoughts around threads.
This i
My mistake copied wrong bug:
Has there been any progress with the new Subject API?
https://bugs.openjdk.java.net/browse/JDK-8267108
On 17/07/2021 2:53 pm, Peter Firmstone wrote:
Thanks Sean,
Has there been any progress with JDK-8264713?
https://bugs.openjdk.java.net/browse/JDK-8264713
());
} finally {
INHERITED_CONTEXT.set(authorization);
}
}
On 16/07/2021 2:20 pm, Peter Firmstone wrote:
I'm currently experimenting with a new authorization layer for java,
post JEP 411.
I would like your thoughts around threads.
This is intended to be simpler than
Thanks Sean,
Has there been any progress with JDK-8264713?
https://bugs.openjdk.java.net/browse/JDK-8264713
Regards,
Peter.
On 16/07/2021 11:44 pm, Sean Mullan wrote:
JEP 411 has been updated with a few changes:
1. The "Description" section [1] has been updated with more details on
our
it create threads, then provided those threads
only have privileged domains on the stack, guard checks may proceed.
For unprivileged application code, all guard checks fail.
Any thoughts or questions?
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
Updated authorization layer prototype:
https://github.com/pfirmstone/HighPerformanceSecurity
On 30/06/2021 9:38 pm, Peter Firmstone wrote:
A draft Authorization implementation, untested.
--
Regards,
Peter Firmstone
A draft Authorization implementation, untested.
--
Regards,
Peter Firmstone
/**
* Authorization class, instances contain the domains and Subject of the
* Authorization context, used for Authorization decisions by Guard
* implementations. Provides static utility methods to make
will need to
call GuardFactory, to obtain Guard instances, the Guard
implementation can call:
* Authorization::getContext()checkEach(domain -> doSomething(domain));
--
Regards,
Peter Firmstone
On 26/06/2021 10:05 pm, Peter Firmstone wrote:
On 26/06/2021 3:41 pm, Peter Firmstone wr
On 26/06/2021 3:41 pm, Peter Firmstone wrote:
Apologies for multiple earlier emails, please ignore and read this
instead.
This proposal is about stripping out and simplifying as much of the
dilapidated and complex SecurityManager infrastructure as possible,
while retaining the ability
tion.
Regards,
Peter Firmstone.
On 25/06/2021 3:59 pm, Peter Firmstone wrote:
Thanks Dalibor,
Would targeting Java 18 be practical?
Also it won't take long to code a prototype, just not sure of the
process.
Cheers,
Peter.
On 24/06/2021 9:30 pm, Dalibor Topic wrote:
On 24.06.2021 04:24, P
Inline.
On 26/06/2021 1:46 pm, Peter Firmstone wrote:
Inline below.
On 26/06/2021 1:11 pm, Peter Firmstone wrote:
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide h
On 26/06/2021 1:48 pm, Peter Firmstone wrote:
The innocuous AccessControlContext, is intended to have no permission,
hence it is constructed using the two argument ProtectionDomain
constructor, which causes ProtectionDomain to not consult the Policy.
However, if a user obtains
AccessControlContext instead be given a
ProtectionDomain, with a non-null CodeSource, which has a null URL. This
is also considered by the Policy to be unprivileged.
--
Regards,
Peter Firmstone
Inline below.
On 26/06/2021 1:11 pm, Peter Firmstone wrote:
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note GuardFactory
should never return null and instead re
iner.
This is backward compatible with existing usages of JAAS and least
painful method of transition for all concerned as well as allowing
complete flexibility of implementation.
Regards,
Peter Firmstone.
On 25/06/2021 3:59 pm, Peter Firmstone wrote:
Thanks Dalibor,
Would targeting Jav
iral
authorization checks).
3. ProtectionDomain, CodeSource and Principal
4. JAAS, Subject and LoginModule.
5. GSS-API/Kerberos, JCA, JCE and JSSE.
--
Regards,
Peter Firmstone
On 24/06/2021 11:50 am, Peter Firmstone wrote:
Clarification inline below.
On 24/06/2021 11:03 am, Peter Firms
Thanks Remi,
We're still building on 8, for CORBA-IIOP stubs, but will look into this
when we've found an alternative IIOP stub compiler.
--
Regards,
Peter
On 23/06/2021 8:02 pm, Remi Forax wrote:
- Mail original -
De: "Andrew Dinn"
À: "Peter Firmstone&qu
, provided we
have some basic things like JVM hooks for access checks.
--
Regards,
Peter Firmstone
On 23/06/2021 7:19 pm, Andrew Dinn wrote:
OHi Peter,
n 23/06/2021 04:02, Peter Firmstone wrote:
1. StackWalker - Can stack walker be back ported to Java 8?
The right place to ask about
Clarification inline below.
On 24/06/2021 11:03 am, Peter Firmstone wrote:
Hi Alan,
It is important to understand the reason for the inherited
AccessControlContext, in order to consider alternatives.
The motivation for inherited context, was simply to avoid privilege
escalation, prior
permissions at all.
--
Regards,
Peter Firmstone
On 23/06/2021 4:34 pm, Alan Bateman wrote:
On 23/06/2021 04:02, Peter Firmstone wrote:
Note: I'm not sure how to replace an inherited AccessControlContext
(with a new implementation based on StackWalker functionality) at
thread creation time
, Peter Firmstone wrote:
Was ever to run with SecurityManager?
I found the issue while porting to jdk8u where Solaris uses a
configuration file with the SunPKCS11 Provider by default - We have
tests to register Providers while SecurityManager is in place. This
failed for SunPKCS11.
When you see
"
I would like to suggest adding a new provider type:
"PARSE-DATA" - To be called by any code about to parse data, eg
deserialization, XML, JSON, SQL, etc. The use case for this is for
servers to grant it to authenticated users (user supplied input data),
so that it can only be performed following user authentication.
Existing Permission implementations
--
Regards,
Peter Firmstone
essClassInPackage.sun.security.util.math";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util.math.intpoly";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.x509";
};
Good call making NativeResourceCleaner imp
the SocketPermission to the local subnet, and
it would shrink the size of the generated policy file by eliminating
other SocketPermission grants to IP addresses on the subnet.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
On 18/06/2021 1:18 pm, Peter Firmstone wrote:
On 16/06/2021 11:18 pm, David Lloyd wrote:
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
Permission references can be replaced with Guard references (which
Permissions are instances of).
I guess you've got something fairly complex
On 16/06/2021 11:18 pm, David Lloyd wrote:
On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
wrote:
Permission references can be replaced with Guard references (which
Permissions are instances of).
I guess you've got something fairly complex in mind, could you give
some practical examples
see a link to your authorization
libraries in your message.
On 6/15/21 5:23 PM, Peter Firmstone wrote:
Rick,
Out of curiosity, does Apache Derby have a need for an Authorization
layer?
We have tooling to generate our policy files, which simplifies the
process a lot, we also have highly
Rick,
Out of curiosity, does Apache Derby have a need for an Authorization layer?
We have tooling to generate our policy files, which simplifies the
process a lot, we also have highly scalable and performant
SecurityManager and Policy implementations which are compatible with
standard Java
On 14/06/2021 9:34 pm, Rafael Winterhalter wrote:
Why not add the property once this is the case, though?
As it is now, I read the 'forRemoval' property to indicate a problem
that should be instantly addressed.
I too suggested and support this approach.
With Java 8 being a common baseline
On 15/06/2021 2:23 am, David Lloyd wrote:
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
wrote:
1. Develop authorization layer security provider services in OpenJDK,
back port it to Java 8 and Java 11 (these provide most of the
utilised functionality of SecurityManager, allowing
On 14/06/2021 6:37 pm, Alan Bateman wrote:
There are some libraries where the maintainers have put effort into
working with a SM.
Yes, I am one of them, very much so.
At first it's a shock, but the show must go on, it could be an
opportunity to address some long standing issues also.
with unmaintained OS's.
Peter.
On 14/06/2021 6:37 pm, Alan Bateman wrote:
On 14/06/2021 08:35, Peter Firmstone wrote:
I wouldn't want to see SecurityManager and Policy be neutralized,
it's better to remove it and fail early so people update their
software, there's a risk they may update
T"
"SUBJECT-DELEGATION"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"
I would like to suggest adding a new provider type:
"PARSE-DATA" - To be called by any code about to parse data, eg
deserialization, XML, JSON, SQL, etc. Granted to users, so that it can
only be performed after authentication.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
me.
Best regards, Rafael
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
Forgot to cc.
Forwarded Message
Subject: Re: Low level hooks in JDK for instrumentation of permission
checks.
Date: Mon, 14 Jun 2021 15:13:15 +1000
From: Peter Firmstone
To: jdk-...@openjdk.java.net
Clarification, utilize java.security.Provider.
So this might
TION"
"TLS"
"AUTH"
"KERBEROS-DELEGATION"
"KERBEROS-SERVICE"
"PRIVATE-CREDENTIAL"
"AUDIO"
"JAXB"
"WEB-SERVICE"
I would like to suggest adding a new provider type:
"PARSE-DATA" - To be called by any code about t
is the ability to customize Permission
implementations, such as allowing address ranges in a SocketPermission
implementation and not consulting DNS to resolve host names.
Cheers,
Peter.
On 10/06/2021 11:55 pm, Alan Bateman wrote:
On 10/06/2021 07:40, Peter Firmstone wrote:
Just a quick question
nd functionality of the AccessController and
AccessControlContext methods if these are retained (I would prefer to
see that, at least for JAAS compatibility).
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
Just a quick question, would it be possible that some JFR hooks might
also be useable for an authorisation layer?
Regards,
Peter.
On 9/06/2021 11:35 am, Peter Firmstone wrote:
Apologies in advance if this seems like paranoid security.
As you are likely now aware, we have been using
/2021 03:49, Peter Firmstone wrote:
Hi Sean,
Sorry I've confused you.
What I should have said is a ProtectionDomain with a null CodeSource.
What I mean to ask is, where ProtectionDomain is created with a null
CodeSource, in Class::getProtectionDomain() can we have CodeSource's
that represents
?
A CodeSource with URL's like jrt:/jdk.* or jrt:/java.* for system modules?
Hopefully my comments below will make a little more sense now.
Regards,
Peter.
On 10/06/2021 1:07 am, Sean Mullan wrote:
On 6/8/21 9:35 PM, Peter Firmstone wrote:
I would also like to request that all JDK modules
ion to use it.
-
PR: https://git.openjdk.java.net/jdk/pull/4400
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
ilePermission
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\JGDMS\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib\\mahalo-service-3.1.1-SNAPSHOT.jar",
"read";
permission java.io.FilePermission
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\mahalo.keystore",
"read";
permission java.io.FilePermission
"C:\\Users\\peter\\Documents\\NetBeansProjects\\JGDMS\\qa\\harness\\trust\\outrigger.keystore",
"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.lang.RuntimePermission "getClassLoader";
permission java.lang.RuntimePermission "modifyThread";
permission net.jini.discovery.DiscoveryPermission
"QATestDefaultGroup_DESKTOP-R0ORPA2_1623111918992";
};
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
Don't bother replying.
I found that it is actually on the TODO list.
https://bugs.openjdk.java.net/browse/JDK-8266592
I've had enough now anyway, there is no fixing this mess.
Sayonara.
On 4/06/2021 2:22 pm, Peter Firmstone wrote:
Could someone please advise the recommended way now
Could someone please advise the recommended way now to preserve the
Subject in Executors to establish a TLS connection?
I am unable to find the documentation.
We use Executors and we preserve the calling Subject across them, to use
for authentication our TLS endpoints.
This is now
Firmstone
On 4/06/2021 7:39 am, Peter Firmstone wrote:
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
we don't use them in our new
authorization layer.
--
Regards,
Peter Firmstone
On 4/06/2021 1:02 am, Sean Mullan wrote:
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
use SM today while
not placing an undue (indirect) burden on those who do not.
— Ron
On 3 Jun 2021, at 10:43, Peter Firmstone wrote:
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
://foojay.io/today/jep-411-what-it-means-for-javas-security-model/
Cheers,
Peter.
On 3/06/2021 7:33 pm, Ron Pressler wrote:
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
consideration.
--
Regards,
Peter.
On 3/06/2021 5:18 pm, Alan Bateman wrote:
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
1 - 100 of 184 matches
Mail list logo
