Message: 3
Date: Thu, 15 Jan 2015 10:28:46 +0000
From: Se?n Coffey <sean.cof...@oracle.com>
To: Peter Haraldson <pe...@certitrade.net>
Cc: Security OpenJDK <security-dev@openjdk.java.net>
Subject: Re: DSA with keylength > 1024 no longer accepted
Message-ID: <54b7965e.8010...@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi Peter,
security-dev is best mailing list to discuss this issue, I'm cc'ing that
list and bcc'ing off jdk7u-dev.
Are you hitting this issue with JDK 8 and later ? (I'll assume so) -
You've hit https://bugs.openjdk.java.net/browse/JDK-8039921
To aid compatibility, it's been decided to relax that restriction from
8u60 and later. See comments in bug report around use of SHA1 and SHA2
and the length of keys that should be used in each operation.
Hope that helps.
regards,
Sean.
On 15/01/2015 10:10, Peter Haraldson wrote:
Hi
First, I'm not quite sure if this is the correct list for this issue,
please excuse & correct me if it's not.
Our problem is that in latest openjdk a check is added that makes our
certificates with DSA & Keylength 2048 unusable. In file
"sun.security.provider.DSA" line 484-489:
protected void checkKey(DSAParams params) throws
InvalidKeyException {
int valueL = params.getP().bitLength();
if (valueL > 1024) {
throw new InvalidKeyException("Key is too long for
this algorithm");
}
}
This is new, these certificates worked fine before. I don't know the
reason for not accepting longer keys than 1024, not allowing too short
keys would make sense to me but not allowing long keys?
We need to find a permanent solution, as for now we can't update our
production servers because of this. We have several certificates
issued by MasterCard, it is a very tedious job to change them all.
Is there a way we could bypass this, could this check be abandoned in
next update?
Our system:
java version "1.7.0_65" (not affected)
OpenJDK Runtime Environment (rhel-2.5.1.2.el6_5-x86_64 u65-b17)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)
OS: RedHat 6.6
Regards Peter
------------------------------
Message: 4
Date: Thu, 15 Jan 2015 11:02:48 +0000
From: kevin.wa...@oracle.com
To: jdk7u-...@openjdk.java.net
Subject: hg: jdk7u/jdk7u-dev/hotspot: 8042235: redefining method used
by multiple MethodHandles crashes VM
Message-ID: <201501151102.t0FB2mNa002494@aojmv0008>
Changeset: e99b6986875c
Author: kevinw
Date: 2015-01-15 09:12 +0000
URL: http://hg.openjdk.java.net/jdk7u/jdk7u-dev/hotspot/rev/e99b6986875c
8042235: redefining method used by multiple MethodHandles crashes VM
Reviewed-by: coleenp, sspitsyn
! src/share/vm/classfile/javaClasses.cpp
! src/share/vm/classfile/javaClasses.hpp
! src/share/vm/oops/cpCacheOop.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp
! src/share/vm/prims/jvm.cpp
! src/share/vm/prims/methodHandles.cpp
! src/share/vm/prims/methodHandles.hpp
+
test/compiler/jsr292/RedefineMethodUsedByMultipleMethodHandlesNoASM.java
------------------------------
Message: 5
Date: Thu, 15 Jan 2015 12:09:30 +0000
From: Se?n Coffey <sean.cof...@oracle.com>
To: "Valery Kopylov (Akvelon)" <v-val...@microsoft.com>, "Martin
Sawicki (MS OPEN TECH)" <marc...@microsoft.com>,
"jdk7u-...@openjdk.java.net" <jdk7u-...@openjdk.java.net>
Cc: "Kirk Shoop \(MS OPEN TECH\)" <kirk.sh...@microsoft.com>
Subject: Re: Backporting the TCP loopback fast path (Windows)
improvement to OpenJDK v7
Message-ID: <54b7adfa.4030...@oracle.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Valeriy,
I used the jdk7u patch that was attached to the mail request. It applied
cleanly. I've posted webrev here for reference (patch there also):
http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u/webrev/
The new WSAIoctl call would appear to be failing with WSAEINVAL. The
NET_EnableFastTcpLoopback call already tests for WSAEOPNOTSUPP - maybe
we should test for WSAEINVAL also and perhaps return silently if windows
don't support the option. Or maybe - we state this as desired behaviour
- i.e this option is suitable for modern windows kernels - your note
below would contradict what I'm seeing though.
The test passes for me on Windows 7 and fails on Windows XP.
regards,
Sean.
On 15/01/2015 11:15, Valery Kopylov (Akvelon) wrote:
Hi Sean,
Our TCP loopback implementation should process the option correctly
on older windows kernels. I tried to reproduce the issue, but it
works fine on my side. So I have an assumption that part of the code
present on jdk9 patch has been lost and this causes such errors.
Did you use the patch for jdk7 sent by Martin or perform the
backporting from jdk8 or 9 by yourself?
Could you please send me output of "hg diff" command in jdk folder?
Best regards,
Valeriy Kopylov
-----Original Message-----
From: Se?n Coffey [mailto:sean.cof...@oracle.com]
Sent: Tuesday, January 13, 2015 22:31
To: Martin Sawicki (MS OPEN TECH); jdk7u-...@openjdk.java.net
Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH); Alan Bateman
Subject: Re: Backporting the TCP loopback fast path (Windows)
improvement to OpenJDK v7
Hi Martin,
I've run into a problem in backporting this to JDK 7u. The test
fails on our build/test systems. (windows XP) -
reason: User specified action: run main/othervm
-Djdk.net.useFastTcpLoopback StressLoopback elapsed time (seconds):
0.64
STDOUT:
STDERR:
java.net.SocketException: Invalid argument: fastLoopback
at sun.nio.ch.Net.socket0(Native Method)
at sun.nio.ch.Net.serverSocket(Net.java:445)
at
sun.nio.ch.AsynchronousServerSocketChannelImpl.<init>(AsynchronousServerSocketChannelImpl.java:71)
at
sun.nio.ch.WindowsAsynchronousServerSocketChannelImpl.<init>(WindowsAsynchronousServerSocketChannelImpl.java:69)
at
sun.nio.ch.WindowsAsynchronousChannelProvider.openAsynchronousServerSocketChannel(WindowsAsynchronousChannelProvider.java:83)
at
java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:140)
at
java.nio.channels.AsynchronousServerSocketChannel.open(AsynchronousServerSocketChannel.java:161)
at StressLoopback.main(StressLoopback.java:42)
This seems to be from the fact that the new SIO_LOOPBACK_FAST_PATH
IOCTL code is only supported on more modern windows systems. I'm
wondering if we should change the src code to not attempt to use
this option on older windows kernels or if I should just modify the
testcase to not run the test on older windows systems ?
regards,
Sean.
On 09/01/2015 16:25, Martin Sawicki (MS OPEN TECH) wrote:
Sean, thank you for the update and your assistance. Looking forward.
-----Original Message-----
From: Se?n Coffey [mailto:sean.cof...@oracle.com]
Sent: Friday, January 09, 2015 8:24 AM
To: Martin Sawicki (MS OPEN TECH); jdk7u-...@openjdk.java.net
Cc: Valery Kopylov (Akvelon); Kirk Shoop (MS OPEN TECH)
Subject: Re: Backporting the TCP loopback fast path (Windows)
improvement to OpenJDK v7
Hey Martin,
I can help in getting this enhancement ported to jdk7u-dev. I'm
just waiting on approval for use of new system property in jdk7u
release.
Once I have that, I can get this in.
regards,
Sean.
On 08/01/15 20:01, Martin Sawicki (MS OPEN TECH) wrote:
Hello again,
We'd like to propose to back-port our TCP loopback fast path
performance improvement for Windows that was recently accepted
into OpenJDK v9 and v8 into v7.
Just for reference, the original OpenJDK v9 fix just for reference
can be found here:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/26e6402772c8.
Our suggested webrev patch file for OpenJDK *v7* is attached to
this message, based on our understanding of the back-porting steps.
Your review and acceptance of this contribution would be appreciated.
Best regards,
Martin Sawicki (and Kirk Shoop, and Valeriy Kopylov) Microsoft Open
Technologies, Inc.
A subsidiary of Microsoft Corp.
------------------------------
Message: 6
Date: Thu, 15 Jan 2015 11:25:25 -0600
From: Paul Nauman <paul.nau...@oracle.com>
To: jdk7u-...@openjdk.java.net
Subject: [7u-dev] Request for approval: 8020829: NMT tests fail on
platforms if NMT detail is not supported
Message-ID: <54b7f805.1090...@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Would like to push this trivial backport to correct test failures.
Bug: 8020829 (Confidential) - NMT tests fail on platforms if NMT detail
is not supported.
hs25 changeset:
http://hg.openjdk.java.net/hsx/hsx25/hotspot/rev/5fd8e2fbafd4
Reviewed by: chris.plum...@oracle.com
- Paul
------------------------------
Message: 7
Date: Thu, 15 Jan 2015 19:33:19 +0100
From: dalibor topic <dalibor.to...@oracle.com>
To: "jdk7u-...@openjdk.java.net" <jdk7u-...@openjdk.java.net>
Subject: [7u communication] RDP2 milestone for 7u80 approaching
Message-ID: <54b807ef.8000...@oracle.com>
Content-Type: text/plain; charset=utf-8; format=flowed
As per earlier communication [1], RDP2 for jdk7u80 is approaching. It
looks like 7u80 b05 (planned for the week of January 21st) will be the
last 7u80 promotion built from the jdk7u repo.
After January 21st, RDP2 will start.
cheers,
dalibor topic
[1]
http://mail.openjdk.java.net/pipermail/jdk7u-dev/2014-December/010126.html
