On 14/09/2018 00:19, Bernd Eckenfels wrote:
:
I am curious, did you verify that the compiler will actually optimize
the getSecurityManager null check in case allow=never?
Yes, and the reason the allowSecurityManager field is an int rather than
a boolean is so that it get sets to a value othe
On 13/09/2018 21:02, Sean Mullan wrote:
:
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
CSR: https://bugs.openjdk.java.net/browse/JDK-8203316
JBS: https://bugs.openjdk.java.net/browse/JDK-8191053
This is inline with the discussion we had on this mailing list last year
a
On 14/09/2018 03:45, mandy chung wrote:
The behavior makes sense, though the name I think is misleading. It
seems not to disallow a security manager, but to disallow the
capability to *set* the security manager. Maybe
"jdk.allowSetSecurityManager" ?
When -Djdk.allowSecurityManager is set at
On 14/09/2018 12:31, Daniel Fuchs wrote:
Maybe it would be less confusing if the property was named
-Djdk.disableSecurityManager, because AFAICT, it's what it does?
Forget I said that ;-)
The name "jdk.allowSecurityManager" is actually fine.
I was also confused at first because I believed the
On 14/09/2018 03:40, Weijun Wang wrote:
The test runs very slow on Linux and turns out reading from the embedded HTTP
server is the bottleneck. Here is the fix:
diff --git a/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
b/test/jdk/javax/xml/crypto/dsig/GenerationTests.java
--- a/test/jd
On Thu, Sep 13, 2018 at 3:03 PM Sean Mullan wrote:
>
> This is a SecurityManager related change which warrants some additional
> details for its motivation.
>
> The current System.setSecurityManager() API allows a SecurityManager to
> be set at run-time. However, because of this mutability, it inc
On 14/09/2018 13:46, David Lloyd wrote:
:
There are essentially two main parts to this change:
1. Deprecation of System.s[etS]ecurityManager()
We (JBoss) use this method to configure some things at run time (like
customizing the Policy) before installing our security manager, so
this would be
On Fri, Sep 14, 2018 at 8:22 AM Alan Bateman wrote:
>
> On 14/09/2018 13:46, David Lloyd wrote:
> > :
> >> There are essentially two main parts to this change:
> >>
> >> 1. Deprecation of System.s[etS]ecurityManager()
> > We (JBoss) use this method to configure some things at run time (like
> > cu
On 14/09/2018 14:28, David Lloyd wrote:
:
I can say that this explanation would be more palatable by far if the
security manager as a whole could be deprecated all at once. I for
one would certainly be happy to remove support for it in the software
that I maintain (it's a considerable amount of
In my latest test that repeats 100 times, the slowest one runs for 208 seconds.
This test runs tens of thousands of signing and verifying and I'd like to keep
that timeout.
Thanks
Max
> On Sep 14, 2018, at 8:14 PM, Alan Bateman wrote:
>
> On 14/09/2018 03:40, Weijun Wang wrote:
>> The test ru
On 9/14/18 4:52 AM, Daniel Fuchs wrote:
The name "jdk.allowSecurityManager" is actually fine.
I was also confused at first because I believed the
property, if set to false, would just prevent someone
to call System::setSecurityManager at runtime, whereas
it also prevents to set a security man
On 9/13/18 11:01 PM, Weijun Wang wrote:
On Sep 14, 2018, at 4:02 AM, Sean Mullan wrote:
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8191053/webrev.00/
public static SecurityManager getSecurityManager() {
+if (allowSecurityManager()) {
return security;
+
Just curious, but why is this not an issue on platforms other than
linux? Seems like we are working around a problem that maybe should be
fixed somewhere else ...
--Sean
On 9/14/18 10:33 AM, Weijun Wang wrote:
In my latest test that repeats 100 times, the slowest one runs for 208 seconds.
Th
On 9/13/18 7:19 PM, Bernd Eckenfels wrote:
Hallo Sean,
The change looks fine to me, but if you have to roll another version
maybe you could add a comment on this line to explain its purpose. Since
this line is changed in the patch it would be a good time:
System.java:350
sm.checkPackageA
Hi Sean,
Looks good.
I would quibble with System.java:335-6
"Java virtual machine does not allow a security manager"
I would say only "a security manager is not allowed to be set dynamically."
There is no need to identify the Java virtual machine. The VM itself
has nothing to do with it.
On 9/13/18 7:52 PM, Stuart Marks wrote:
I'd guess that security-dev would have reviewers for the change to
default.policy. Cc'd.
The default.policy file change looks like this is not specifically
related to this change because the jdk.desktop module no longer exists.
I guess it is ok to inclu
There is another way, by reusing the existing security manager property with a
new keyword („default“ is already a well known value) one could implement the
stable suppression of the SM without actually needing a new property. It also
avoids unclear meaning of denied but specified SM:
java.secu
On 9/14/18 12:23 PM, Stuart Marks wrote:
On 9/14/18 4:52 AM, Daniel Fuchs wrote:
The name "jdk.allowSecurityManager" is actually fine.
I was also confused at first because I believed the
property, if set to false, would just prevent someone
to call System::setSecurityManager at runtime, where
On 9/14/18 2:54 PM, Bernd Eckenfels wrote:
There is another way, by reusing the existing security manager property
with a new keyword („default“ is already a well known value) one could
implement the stable suppression of the SM without actually needing a
new property. It also avoids unclear me
I was looking at some key management code and noticed this typo in
X509ExtendedKeyManager. Attached is a trivial patch which fixes it. I'm
not a committer but have a signed OCA, so I'll need help from a sponsor.
-Jaikiran
# HG changeset patch
# User Jaikiran Pai
# Date 1536980065 -19800
# S
Hi Jaikiran,
Thanks for the find and the patch. The patch looks fine to me, and I
sponsored the committing and now it is in the JDK repository.
http://hg.openjdk.java.net/jdk/jdk/rev/6c394ed56b07
Thanks,
Xuelei
On 9/14/2018 7:58 PM, Jaikiran Pai wrote:
I was looking at some key management
Thank you Xuelei.
-Jaikiran
On 15/09/18 9:03 AM, Xuelei Fan wrote:
> Hi Jaikiran,
>
> Thanks for the find and the patch. The patch looks fine to me, and I
> sponsored the committing and now it is in the JDK repository.
>
> http://hg.openjdk.java.net/jdk/jdk/rev/6c394ed56b07
>
> Thanks,
> Xuelei
Is there any more details you need ?
Just wondering. If you say so I can also provide a pure jdk client (without the
Netty wrapper) that shows the problem when used with OpenSSL on the server in
the next days.
Bye
Norman
> Am 13.09.2018 um 21:07 schrieb Norman Maurer :
>
> Hi all,
>
> I am c
Hello!
This is a followup of the fix of JDK-8210785 (Trivial typo fix in
X509ExtendedKeyManager javadoc).
A few more occurrences of the typo were found.
Would you please help review?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8210786
WEBREV: http://cr.openjdk.java.net/~igerasim/8210786
Hi Norman,
I have not had a chance to look into the details. But sure, it helps a
lot if you can provide a java client to reproduce the issue.
Thanks,
Xuelei
On 9/14/2018 10:29 PM, Norman Maurer wrote:
Is there any more details you need ?
Just wondering. If you say so I can also provide a
Ok will try to find time today.
> Am 15.09.2018 um 08:08 schrieb Xuelei Fan :
>
> Hi Norman,
>
> I have not had a chance to look into the details. But sure, it helps a lot
> if you can provide a java client to reproduce the issue.
>
> Thanks,
> Xuelei
>
>> On 9/14/2018 10:29 PM, Norman Maure
It would greatly help if you can provide the client side debug output so
we can see what's going on locally:
-Djavax.net.debug=all or System.setProperty()
Please also let us know if you are using a custom client keymanager.
It's possible that it isn't properly selecting an entity to use, i
27 matches
Mail list logo
