Hi Max,
Thanks for fixing.
Reviewed.
David
JDK-8186186 added a new test called SpnegoUnknownMech.java [1]. It was named
SpnegoRejected.java but was renamed to the current name right before the push.
The content still references the old name and therefore cannot run.
Please review the patch
Hi,
I've seen the changes that should allow for keeping the GTE cybertrust root ca
around although it has expired on 14th of August, also this one:
http://mail.openjdk.java.net/pipermail/security-dev/2018-April/017023.html
However, I'd like to ask the question if you really plan to keep this ex
Hi,
> > On 7/12/2018 1:17 PM, Simone Bordet wrote:
> > Currently:
> > - Server wraps 160, 6 and 907 in 3 wraps.
> > - Server *sends* the 1073 bytes in 1 TCP write
> > - Client unwraps 160, then goes into NEED_WRAP
> > - Client wraps 6, then goes again into NEED_UNWRAP to finish with the
> > 6 and
This test is currently on the ProblemList for solaris-all in jdk8u-dev.
The test can fail on Solaris installs where the native pkcs11 library
might not be fully patched. I've modified the testcase to allow for such
failure and to re-run with the SunPKCS11-Solaris Provider removed.
Testing look
Looks fine to me.
--Sean
On 8/22/18 6:47 AM, Seán Coffey wrote:
This test is currently on the ProblemList for solaris-all in jdk8u-dev.
The test can fail on Solaris installs where the native pkcs11 library
might not be fully patched. I've modified the testcase to allow for such
failure and to
On 8/22/18 5:17 AM, Langer, Christoph wrote:
Hi,
I've seen the changes that should allow for keeping the GTE cybertrust root ca
around although it has expired on 14th of August, also this one:
http://mail.openjdk.java.net/pipermail/security-dev/2018-April/017023.html
However, I'd like to ask
I filed a bug for this improvement.
https://bugs.openjdk.java.net/browse/JDK-8209840
We may fix it in a near release.
Thanks,
Xuelei
On 8/22/2018 3:29 AM, Simone Bordet wrote:
Hi,
On 7/12/2018 1:17 PM, Simone Bordet wrote:
Currently:
- Server wraps 160, 6 and 907 in 3 wraps.
- Server *sen
Ouch! Sorry about that, and thanks for fixing it!
On 8/21/18 10:54 PM, Weijun Wang wrote:
Ivan, I'll file a bug and fix it.
On Aug 22, 2018, at 1:49 PM, Weijun Wang wrote:
Or, he renamed the test but forgot to rename the name on the @run line.
On Aug 22, 2018, at 1:46 PM, David Holmes w
Ping. I'd like to push on with this review.
Regards,
Sean.
On 16/08/18 17:53, Seán Coffey wrote:
Find new webrev here Max :
http://cr.openjdk.java.net/~coffeys/webrev.8209129.v2/webrev/
regards :
MD4.java:
110 void implReset() {
Add @Override.
There's a whole bunch of annotations
I just realized the CSR is not reviewed yet. Please take a look.
> On Aug 6, 2018, at 4:53 PM, Weijun Wang wrote:
>
> Ping again.
>
> Also please take a review at the CSR at
> https://bugs.openjdk.java.net/browse/JDK-8208689.
>
> Thanks
> Max
>
>> On Aug 2, 2018, at 10:28 AM, Weijun Wang wr
PBES2Core.java:
181 byte[] passwdBytes = key.getEncoded();
182 char[] passwdChars = null;
183 PBEKeySpec pbeSpec;
184 try {
185 if ((passwdBytes == null) ||
186 !(key.getAlgorithm().regionMatches(true, 0, "PBE", 0,
3))) {
187
Thanks for reviewing. comments inline..
On 22/08/18 15:50, Weijun Wang wrote:
PBES2Core.java:
181 byte[] passwdBytes = key.getEncoded();
182 char[] passwdChars = null;
183 PBEKeySpec pbeSpec;
184 try {
185 if ((passwdBytes == null) ||
186
I added my name as the reviewer.
Xuelei
On 8/22/2018 7:40 AM, Weijun Wang wrote:
I just realized the CSR is not reviewed yet. Please take a look.
On Aug 6, 2018, at 4:53 PM, Weijun Wang wrote:
Ping again.
Also please take a review at the CSR at
https://bugs.openjdk.java.net/browse/JDK-820
Hi Max, looks good, just a couple nit-picky things:
* Problem section
o "Sometimes user wants to..." --> "Sometimes a user wants to..."
* Compatibility Risk Description
o "...there is only behavior change..." --> "there is only a
behavior change..."
I've also added my name as
Hi Seán!
Just a minor comment.
I don't know if it's even measurable in this context, but I was under
impression that filling memory with zero *bytes* might be a slightly
more efficient then filling with any other constant.
Maybe it is better to use Arrays.fill(passwd, '\0') instead of
Array
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 literal, which is not guaranteed to be accurate.
Would you please help r
One thing I am curious about. Is there a reason why
getObject(ObjectInputFilter) requires a permission check?
In this case, the caller is the one creating the filter and passing it
in, so the caller can only cause harm to themselves, and the
ObjectInputStream is a local variable which is not r
On 22 August 2018 19:22:49 IST, Ivan Gerasimov
wrote:
>Hi Seán!
>
>Just a minor comment.
>
>I don't know if it's even measurable in this context, but I was under
>impression that filling memory with zero *bytes* might be a slightly
>more efficient then filling with any other constant.
>
>May
18 matches
Mail list logo
