Changes look good.
Thanks,
Valerie
On 8/23/2018 1:40 PM, Ivan Gerasimov wrote:
Hello!
This is a smartcardio related issue.
If CardChannel.transmit() needs to issue an additional command, it
reuses the array 'command' that was passed in as an argument, which
may turn out to be shorter than n
Hi,
i enabled the logging but did not receive more usefull information.
Maybe an hint how i get this NPE, i run an SSL Scan on
"https://www.ssllabs.com/ssltest/analyze.html";.
And the check that cause the error contain an list of elliptical curves
that are not all known i think.
Gruß Thomas
Hi Thomas, can you reproduce the issue with debug logging turned on? It
may be helpful in conjunction with the stack trace you've provided. You
should be able to turn it on with -Djavax.net.debug=ssl
Thanks,
--Jamil
On 8/23/2018 2:41 PM, Thomas Lußnig wrote:
Hi,
i got these NPE on my Serve
Hi Thomas,
I filed a bug for the tracking and further evaluation.
https://bugs.openjdk.java.net/browse/JDK-8209916
Did you have more information? For example, the debug log or the group
name used in the context?
Thanks,
Xuelei
On 8/23/2018 2:41 PM, Thomas Lußnig wrote:
Hi,
i got these
Hi,
i got these NPE on my Server. With Java:
openjdk 11-ea 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11-ea+25)
OpenJDK 64-Bit Server VM 18.9 (build 11-ea+25, mixed mode)
java.lang.NullPointerException
at
java.base/sun.security.ssl.SupportedGroupsExtension$SupportedGroups.getEC
Hello!
This is a smartcardio related issue.
If CardChannel.transmit() needs to issue an additional command, it
reuses the array 'command' that was passed in as an argument, which may
turn out to be shorter than needed.
The fix was verified locally with the manual test.
Would you please help
Hi,
The code below reproduces a bug where session resumption is tested.
Turns out that session resumption does happen on the client and on the
server, but on the client the session id is not replaced with the
resumed session id (while it is on the server).
The code prints:
session1 = Session(153
Hi,
In the case of supplying a filter to getObject the caller is
intentionally replacing
the system filter and can supply a filter that performs it own checks and
if desired can delegate to the system filter.
Some thought does need to be designed into the filter supplied as to
its purpose and
I'm starting work on yet another ECC JEP[1], this time with the goal of
developing improved implementations of existing algorithms, rather than
implementing new ones. The JEP will re-implement ECDH and ECDSA for the
256-, 384-, and 521-bit NIST prime curves. The new implementation will
be all J
But calling getObject(filter) effectively overrides the system filter, is that
a problem?
> On Aug 23, 2018, at 11:51 PM, Roger Riggs wrote:
>
> Hi Max,
>
> Yes, the stream is passed to the readObject method of the classes being
> deserialized.
>
> But that's only a concern during the call t
Hi Max,
Yes, the stream is passed to the readObject method of the classes being
deserialized.
But that's only a concern during the call to a.readObject() not on the
call to setObjectInputFilter.
It would be reasonable I think for getObject0 to put a doPriv around the
call to a.setObjectInp
You mean during deserialization an untrusted object could be created that have
a reference to the stream itself?
> On Aug 23, 2018, at 10:12 PM, Roger Riggs wrote:
>
> Hi,
>
> The original basis for the security manager check was to ensure that the
> filter could
> not be replaced by untruste
Good catch! I filed a bug for the tracking and further evaluation.
https://bugs.openjdk.java.net/browse/JDK-8209893
Thanks,
Xuelei
On 8/23/2018 7:04 AM, Simone Bordet wrote:
Hi,
SSLSocket is behaving weird in 11+27.
In particular:
* Setup a SSLServerSocket.
* Connect with a normal Socket (
Hi,
The original basis for the security manager check was to ensure that the
filter could
not be replaced by untrusted code including code in the classes being
deserialized
that have access to the ObjectInputStream.
Regards, Roger
On 8/23/18 10:00 AM, Weijun Wang wrote:
This follows the con
Hi,
SSLSocket is behaving weird in 11+27.
In particular:
* Setup a SSLServerSocket.
* Connect with a normal Socket (rawClient).
* Wrap rawClient into a SSLSocket (sslClient).
* sslClient.startHandshake()
Now a few cases:
A) immediate rawClient.close()
If the server is reading via InputStream.re
This follows the convention of ObjectInputStream::setObjectInputFilter. IMHO,
in that case the caller also creates the filter and it's only set on this input
stream.
Maybe we shouldn't have added the permission check there?
Thanks
Max
> On Aug 23, 2018, at 4:55 AM, Sean Mullan wrote:
>
> One
Looks fine to me.
--Sean
On 8/22/18 3:21 PM, Ivan Gerasimov wrote:
Hello!
In sun.security.provider.DSA.engineInitSign() a check for the key size
is meant to be skipped if the MessageDigest is NullDigest20.
However, the check for the algorithm's name is done via comparing with a
String lite
No idea. I may not use a printable character to zero a password.
Xuelei
On 8/23/2018 3:31 AM, Weijun Wang wrote:
I have no more comment.
As for fill(passwd, '\0'), maybe JVM can translate it to ZeroMemory() or
memset(0). In fact, I don't know why originally it was fill(passwd, '0'). I can
o
Hi Sean,
thanks for the information.
Can you please let me know when you've crated the Jira item for removal that I
can add me as a watcher?
Thanks & Best regards
Christoph
> -Original Message-
> From: Sean Mullan
> Sent: Mittwoch, 22. August 2018 15:41
> To: Langer, Christoph ; Rajan
I made those minor edits in the end and pushed the changes. We should
examine usage of Arrays.fill(passwd, '0') in other parts of the JDK as a
follow up.
regards,
Sean.
On 22/08/2018 23:01, Seán Coffey wrote:
On 22 August 2018 19:22:49 IST, Ivan Gerasimov
wrote:
Hi Seán!
Just a minor com
I have no more comment.
As for fill(passwd, '\0'), maybe JVM can translate it to ZeroMemory() or
memset(0). In fact, I don't know why originally it was fill(passwd, '0'). I can
only guess that it can still be printed out as a normal string and if someone
misuse it there won't be a NPE. Who know
21 matches
Mail list logo
