may put us 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
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
authenticat
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 goo
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 untrust
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 provid
pport this JDK version.
Personally I'd like to see SM fully supported until finalizers 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 basi
/8349
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
ms-platform/src/main/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. Modifi
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 de
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 met
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.
With
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
check
tly
for a bit more info. 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
.044 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
x27;s
pitfalls.
Watch 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 f
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 a
* User Credentials
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 comprom
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 that
uts in addition 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
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
wi
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
ain's on the stack. We don't need to call
ProtectionDomain::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
lared API.
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&
more
than I've posted, I suggest you do the 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'
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
somet
ops global service
discovery over IPv6, 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 const
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 /
t prefer slow change.
- Property-based testing is wonderful, I wish more 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
remove finalizers soon, prior 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
la
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 potential
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 for
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
rs cat to bury applets.
Regards,
Peter.
On 28/07/2021 7:41 pm, [email protected] wrote:
----
*From: *"Peter Firmstone"
*To: *"Remi Forax" , "Alan Bateman"
*Cc: *"jdk-d
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 download
(very well supported, Oracle should sell these lol,
the only drawback is no zfs) is a good idea, no Spectre or Meltdown
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.
O
brought it
forward. If Haskell is a magnitude more efficient, as its proponents
claim, then it may ultimately provide an overall cost saving. We
haven't made a choice yet though, it's still under investigation.
I do appreciate that you took the time to respond to my emails.
Reg
ng, data parsing, 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
e to secure the underlying
platform, or at least use it securely. 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,
t
great performance, all our hotspots were native methods and Java let us
get close to the metal at low 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,
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 J
s for our TLS
and Kerberos connections, for authentication, I've 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.
--
Reg
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 Acces
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
GED);
PRIVILEGED_DOMAINS.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 tho
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
rotectionDomain());
} 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 intende
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 pl
, may be thought of as a
system domain, should 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
27;s principals.
6. GuardFactory and GuardFactorySpi, Authorization agents 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/20
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 for
y of implementation.
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
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 hooks
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 this
innocuous 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 retu
mbiner.
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 target
er.doPrivileged, or Thread context, which limits viral
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
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 Fi
Java, 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 this i
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 to
reads
that do not support any 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 func
, 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
"
"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. 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
sion
"accessClassInPackage.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 NativeReso
expand 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 compl
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 exampl
yes didn't 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 a
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 po
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.
If
VM's 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
MBEAN-TRUST"
"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.
dvice on how this is intended to be handled by library
developers like 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: [email protected]
Clarification, utilize java.security.Provider.
So this might
"
"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 ab
s 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 que
ed confirm
Permission checks are made and 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
rote:
On 10/06/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 CodeSourc
ad of null?
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
ed to add synchronization to use it.
-
PR: https://git.openjdk.java.net/jdk/pull/4400
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
\\dist\\target\\JGDMS-3.1.1-SNAPSHOT\\lib-dl\\mahalo-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\\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
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 deprecated
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
ing about
removing, then we need to know, so 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
lieve some portion of the burden on those who 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 soft
https://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
some 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
1 - 100 of 186 matches
Mail list logo
