Hello Sean,
On 15/06/21 12:19 am, Sean Mullan wrote:
We already are working on improvements to the warning message to show
the class and the source of the code calling
System::setSecurityManager. See
https://bugs.openjdk.java.net/browse/JDK-8268392
I just had a look at that JBS issue and
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
Is it possible to redirect those vm messages with unified logging or vm-error
files or similar command line flags to the launcher to keep stdout/stderr clean?
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: security-dev im Auftrag von Sean
Mullan
Gesendet:
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
> More loudly and precise warning messages when a security manager is either
> enabled at startup or installed at runtime.
>
> This is new PR for the `openjdk/jdk17` repo copied from
> https://github.com/openjdk/jdk/pull/4400. A new commit is added.
Weijun Wang has updated the pull request
On Sat, 12 Jun 2021 05:45:35 GMT, Valerie Peng wrote:
> Could someone help review this small fix? This clears the static
> aliasOidsTable field in AlgorithmId class when provider list is changed.
> Enhanced existing regression test to cover the provider removal scenario.
>
> Thanks,
> Valerie
On Fri, 11 Jun 2021 21:22:49 GMT, Valerie Peng wrote:
> Could someone help review this straightforward fix? The current impl for AES
> KW and KWP cipher should check for possible null iv value in its
> CipherSpi.engineGetIV() and CipherSpi.engineGetParameters() impls. Updated
> the regression
Folks,
can someone confirm the following bug or tell me I am too stupid to read
the RFCs:
I have recently created a PKCS12-based trust store and had one CA from
Hungary with non-ASCII chars in the subject's CN RDN.
RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1:
We already are working on improvements to the warning message to show
the class and the source of the code calling System::setSecurityManager.
See https://bugs.openjdk.java.net/browse/JDK-8268392
If that is not sufficient and a stack trace is really still needed, my
preference would be to
While testing the Apache Ant project with the latest released EA of JDK
17[1] (build 26), at least one of our internal test case has started
failing. The failure relates to the new "WARNING" message that gets
printed out to System.err when some code at runtime sets the security
manager. The
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 developers to
> only implement those
On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 17 -> JDK 18
This pull request has now been integrated.
Changeset: 17295b1b
Author:Jesper Wilhelmsson
URL:
https://git.openjdk.java.net/jdk/commit/17295b1bb02b2121978f1459b2e75c5e1031e7ea
Stats: 721
On Mon, 14 Jun 2021 15:58:15 GMT, Jesper Wilhelmsson
wrote:
>> Forwardport JDK 17 -> JDK 18
>
> Jesper Wilhelmsson has updated the pull request with a new target base due to
> a merge or a rebase. The incremental webrev excludes the unrelated changes
> brought in by the merge/rebase.
Looked
> Forwardport JDK 17 -> JDK 18
Jesper Wilhelmsson has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase.
-
Changes:
- all:
On Mon, 14 Jun 2021 14:28:33 GMT, Jesper Wilhelmsson
wrote:
> Forwardport JDK 17 -> JDK 18
Thumbs up!
Thanks for doing this sync forward.
-
Marked as reviewed by dcubed (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/4484
On 6/14/21 7:34 AM, 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. With Java 8 being a common baseline for libraries and
the version being supported
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. With Java 8 being a common baseline for libraries and
the version being supported until (at least) 2030, I don't see how this
removal
One example for a currently necessary "doPrivileged" are Java agents where
a class loading triggers agent code where the agent shares the stack with
any code that loads a class for the first time. Otherwise, Byte Buddy wraps
anything that might require privileges as privileged action to allow
Forwardport JDK 17 -> JDK 18
-
Commit messages:
- 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed:
avoid underflow
- 8268342: java/foreign/channels/TestAsyncSocketChannels.java fails with
"IllegalStateException: This segment is already closed"
-
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.
The JEP addresses this:
> In future JDK releases, we will degrade the Security Manager APIs so that
> they
remain in place but have limited or no functionality. ... This will allow
libraries
that support the Security Manager and were compiled against previous Java
releases
to continue to
Binary compatibility only?
Security.getSecurityManager() always returns null.
Security.setSecurityManager() always throws a SecurityException
(compatible because existing SecurityManager is allowed to prevent the
call from succeeding).
SecurityManager constructor always throws a
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 without realizing it's no longer fully
functional. Get rid of the baggage so
Making things clearer if I can:
Some thoughts on hooks:
* Utilize java.security.Provider, so as not to expose jdk
implementation code. Eg: a module declaration or
META-INF/services/java.security.Provider to obtain relevant
instances of java.security.Guard, where Permission
My thoughts on how to proceed with this is:
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 developers to
only implement those which they need, without
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
26 matches
Mail list logo
