Changeset: 74bc85c0f2a9
Author:valeriep
Date: 2008-03-20 16:02 -0700
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/74bc85c0f2a9
4898461: Support for ECB and CBC/PKCS5Padding
Summary: Add support for ECB mode and PKCS5Padding
Reviewed-by: andreas
! src/share/classes/sun/security/
Changeset: 8805ae9d160c
Author:valeriep
Date: 2008-03-31 11:09 -0700
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/8805ae9d160c
6681652: Two new regression test failures in pkcs11 code
Summary: Fixed the test to not assume SunJCE provider being the provider for DES
Reviewed-by: w
Changeset: 17e93b7fb97d
Author:valeriep
Date: 2008-03-31 16:12 -0700
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/17e93b7fb97d
6682411: JCK test failed w/ ArrayIndexOutOfBoundException (-1) when decrypting
with no data
Summary: Fixed PKCS5Padding class with additional check and
Changeset: 51eab854cb1a
Author:valeriep
Date: 2008-04-25 15:19 -0700
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/51eab854cb1a
6524501: inconsistency with PKCS#11 spec - 0-value flags in CK_SLOT_INFO struct
returned by C_GetSlotInfo()
Reviewed-by: mullan
! src/share/classes/su
Changeset: 27719467fb93
Author:valeriep
Date: 2008-04-30 11:10 -0700
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/27719467fb93
6695818: New regression test (KerberosTixDateTest) for Kerberos failing on
(probably) all platforms.
Reviewed-by: mullan
! test/javax/security/auth/ke
Changeset: da9d0283a496
Author:valeriep
Date: 2009-03-03 19:50 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/da9d0283a496
6812738: SSL stress test with GF leads to 32 bit max process size in less than
5 minutes with PCKS11 provider
Summary: Removed finalize() and add more e
Changeset: 45ff1a9d4edb
Author:valeriep
Date: 2009-04-06 18:46 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/45ff1a9d4edb
4735126: (cl) ClassLoader.loadClass locks all instances in chain when delegating
Summary: Added support for parallel-capable class loaders
Reviewed-by: a
Changeset: 6f99dbd58123
Author:valeriep
Date: 2009-04-13 18:20 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f99dbd58123
6829098: Regression test
java/security/Security/ClassLoaderDeadlock/Deadlock2.java error - missing ";"
Summary: Added back the missing ";"
Reviewed-by:
Changeset: beb5e5cad3ae
Author:valeriep
Date: 2009-07-13 15:14 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/beb5e5cad3ae
6832540: IllegalArgumentException in ClassLoader.definePackage when classes are
loaded in parallel
Summary: Modified to handle race condition for parall
Changeset: cd7758c85d13
Author:valeriep
Date: 2009-07-22 17:52 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd7758c85d13
6823905: crash in sun.security.pkcs11.wrapper.PKCS11.C_Sign during stress-test
Summary: Initialize relevant return value to NULL
Reviewed-by: vinnie
! s
Changeset: c52f292a8f86
Author:valeriep
Date: 2010-03-18 17:05 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c52f292a8f86
6695485: SignedObject constructor throws ProviderException if it's called using
provider "SunPKCS11-Solaris"
Summary: Added checking for RSA key lengths
Changeset: 6b641c576e77
Author:valeriep
Date: 2010-04-07 17:20 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6b641c576e77
6918573: sun.security.pkcs11.P11RSACipher.finalize() is a scalability blocker
Summary: Removed the finalize() methods and use PhantomReference in Session
The changes look fine although I prefer the later, e.g. explicitly
specifies SunJCE to be used, slightly since it does not depend on other
provider(s).
Thanks,
Valerie
Brad Wetmore wrote:
Valerie,
Here's that PBE memory leak bug which was calling "new SunJCE" for every
PBE key created.
Why do you assume that the key is generated in software?
You use the KeyGenerator API to generate a key, this key can be
generated on the HSM if you have SunPKCS11 provider configured to be the
most preferred provider. This key should actually just encapsulate the
native key handle (not the act
ate key object.
If we want to use HSM vendors tools to manipulate objects this usually causes
problems because they mostly rely on an alias.
So finally :-) this is why an alias parameter to KeyPairGenerator would be
useful.
Cheers,
Tomas
On 03/30/2010 08:34 PM, Valerie (Yu-Ching) Peng wrote:
I've looked at the changes and they look fine to me. If you can work w/
Andrew to get this in, e.g. bug id, integration, etc., that'd be good.
Thanks,
Valerie
On 04/14/10 23:49, Bradford Wetmore wrote:
Valerie, did you want to look at this, or I can work with Andrew on
getting this in. It's
rwise it is not
possible to generate key because the HSM will throw an error, usually
invalid_template.
Does this happen for all keys or just for EC keys?
Cheers,
Tomas
Valerie (Yu-Ching) Peng wrote:
If the default PKCS11 config is used, I'd expect that KeyPairGen
RIVATE_KEY,*) = {
CKA_EXTRACTABLE = false
CKA_DECRYPT = true
CKA_SIGN = true
CKA_UNWRAP = true
}
-
The results are the same as in 2. Only the certificate has a label
when listing the objects in the HSM (with 'cmu list').
Kind regards,
Tomas
Valerie (Yu-Ching) Peng wrote:
You
Hi, Max,
Your fixes look fine.
Thanks,
Valerie
On 05/17/10 03:06, Weijun Wang wrote:
Hi Valerie
A new bug 6950930 filed for the same problem.
So ping again. Webrev small update at --
http://cr.openjdk.java.net/~weijun/6882687/webrev.01
Changes:
1. 2009 -> 2010
2. new fields now private
Max,
Changes look fine to me.
Thanks,
Valerie
On 06/01/10 01:33, Weijun Wang wrote:
Hi All
Please review this webrev:
http://cr.openjdk.java.net/~weijun/6844907/webrev.00/
Three notes:
1. The etype order change has effect on keys in a keytab file. In KeyTab.java,
I've made the followi
Vinnie is on vacation, so I'll take a shot of answering this.
According to the bug record, the fix for 6763530 is in jdk7, openjdk6
and not in Oracle's jdk6 update release.
Not all bugs are backported, it's subject to RE's discretion.
I've opened a subCR against this particular release train an
Looks fine except the following minor nit:
- Why not return realm on line 1224 after a match is found? Doesn't seem
necessary to continue w/ the whole for-loop.
Thanks,
Valerie
On 07/15/10 23:23, Weijun Wang wrote:
Updated webrev:
http://cr.openjdk.java.net/~weijun/6969292/webrev.01/
Chang
right? Can you rename them so it's clearer?
There is no checking in getKeys() and if called out of sequence, it
looks to me that it'll error out w/ NPE since eType is still null.
Thanks,
Valerie
On 07/21/10 12:32, Valerie (Yu-Ching) Peng wrote:
On 06/13/10 08:02, Weijun Wa
Hi, Brad,
Do you have time to review these two PKCS11 fixes? They are straight
forward.
6687725: Internal PKCS5Padding impl should throw
IllegalBlockSizeException and not BadPaddingException
Webrev - http://cr.openjdk.java.net/~valeriep/6687725
6848930: JSN security test jce/Global/Cipher/P
Hi, Sean,
Do you have time to review these two fixes?
6850402: Deadlock on sun.security.jca.ProviderConfig starting from jdk7-b55
http://cr.openjdk.java.net/~valeriep/6850402
Note: verify by re-running the stress test
6887853: javadoc for java.lang.Classloader should be more clear
http://cr.ope
st
of the week.
Brad
On 8/31/2010 5:20 PM, Valerie (Yu-Ching) Peng wrote:
Hi, Brad,
Do you have time to review these two PKCS11 fixes? They are straight
forward.
6687725: Internal PKCS5Padding impl should throw
IllegalBlockSizeException and not BadPaddingException
Webrev - http://cr.o
Trivial fix - just add null check and OOM error handling for the 2
malloc calls inside src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c.
Please find webrev against JDK8 at:
http://cr.openjdk.java.net/~valeriep/7107615/webrev.00/
Thanks,
Valerie
Yes, please find the correct webrev at:
http://cr.openjdk.java.net/~valeriep/7155720/webrev.00/
Thanks,
Valerie
On 04/01/13 07:43, Sean Mullan wrote:
On 03/29/2013 08:32 PM, Valerie (Yu-Ching) Peng wrote:
Trivial fix - just add null check and OOM error handling for the 2
malloc calls inside
Makes sense. I will update the fix accordingly.
Thanks,
Valerie
On 04/04/13 00:33, Florian Weimer wrote:
On 04/01/2013 08:26 PM, Valerie (Yu-Ching) Peng wrote:
Yes, please find the correct webrev at:
http://cr.openjdk.java.net/~valeriep/7155720/webrev.00/
I think in the second hunk of the
Changes look good, don't forget to update the copyright years though.
Thanks,
Valerie
On 04/03/13 04:31, Weijun Wang wrote:
http://cr.openjdk.java.net/~weijun/8011124/webrev.00/
KerberosTime is a very basic data type and it is nice to be immutable.
One test is updated. No new regression test f
The fixes look fine.
Thanks,
Valerie
On 04/16/13 05:30, Xuelei Fan wrote:
Hi Valerie,
Are you available to review the HAMC impl update in JCE/TLS?
Webrev: http://cr.openjdk.java.net./~xuelei/8006935/webrev.00/
The issue comes from the practice that the industry starts to use large
Diffie-Hel
Max,
Do you have time to review the following fix?
7196009: SunPkcs11 provider fails to parse config path containing
parenthesis
I made the adjustments to support quoted strings for the library path
settings in the PKCS11 provider configuration file.
If the path contain parenthesis or spaces,
Xuelei,
Do you have time to review the following two fixes?
7196382: PKCS11 provider should support 2048-bit DH
8010134: A finalizer in sun.security.pkcs11.wrapper.PKCS11 perhaps
should be protected
The first one removes the hardcoded limit of 1024 for DH and the second
one is making the fina
t; -Max
>
> 在 Apr 19, 2013，10:38，"Valerie (Yu-Ching) Peng" 写道：
>
>> Max,
>>
>> Do you have time to review the following fix?
>> 7196009: SunPkcs11 provider fails to parse config path containing parenthesis
>>
>> I made the adjustments to support q
The concurrent config parsing impl in SunPKCS11 provider may seem more
complicated than necessary at the first sight.
However, it has several advantages: this strict parsing can detect
invalid settings right at parsing time and fail if any error is
detected. Special handling for different keys
Both fixes look fine.
However, for easier tracking, it's better to separate them out into 2
separate webrevs under their corresponding bug ids.
Can you please do that?
Thanks,
Valerie
On 04/22/13 14:18, Anthony Scarpino wrote:
This code review is for the following two bugs:
- 8001284 Buffer p
Won't this change break systems which don't have libpcsclite.so.1?
Changes like this need to be thought through. What happens when
libpcsclite.so.2 comes out?
As for API changes, shouldn't there be some compatibility requirement on
APIs as libpcsclite.so evolves?
Valerie
On 04/24/13 04:05, Fl
additional algorithm-specific check (e.g. multiples
of 64 bits) that can't be expressed through the ranges. I am still
testing out the changes. Will post an updated webrev for 7196382 once I
am done testing...
Thanks!
Valerie
On 04/18/13 21:45, Xuelei Fan wrote:
On 4/19/2013 10:43 AM, Valerie
Xuelei,
I have updated the webrev for 7196382 so it uses the key size range info
from the underlying PKCS library for key size checking:
http://cr.openjdk.java.net/~valeriep/7196382/webrev.01/
Thanks,
Valerie
On 04/25/13 10:59, Valerie (Yu-Ching) Peng wrote:
Xuelei,
Thanks for the review
So, has this changes been tested against the existing regression tests
on Mac?
After this, is the native JGSS provider get used on Mac for most if not
all Kerberos operation or is it still Java Kerberos?
Otherwise, changes look ok to me.
Valerie
On 03/18/13 05:38, Erik Joelsson wrote:
The b
Vinnie,
Hmm, so, are we taking the salt and ic value from the key object for
decrypt mode?
If yes, then the if-cond checking on line 214 will have to be deferred
to a later point where we checked both key and the parameters.
Do we check for consistent values of salt and ic if both key and
pa
Changes look fine.
Thanks,
Valerie
On 05/06/13 19:47, Weijun Wang wrote:
Webrev at
http://cr.openjdk.java.net/~weijun/8012679/webrev.00/
Thanks
Max
Vinnie,
Could you please help reviewing the fixes for 8013069 "javax.crypto
tests fail with new PBE algorithm names"?
Given that the current javax.crypto.Mac API doesn't provide a way to
return algorithm parameters (unlike most of other crypto engine
classes), I think it's better to error ou
ic' be expanded to 'iteration count' in the
exception message
in HmacPKCS12PBESHA1.java and PBMAC1Core.java?
On 8 May 2013, at 02:08, Valerie (Yu-Ching) Peng wrote:
Vinnie,
Could you please help reviewing the fixes for 8013069 "javax.crypto tests fail with
new PBE algori
John,
1) 332-333 can be replaced w/ a deleteGSSOID(nameType) call. Also, with
this deleteGSSOID(nameType) call, we should also add the following line:
resetGSSBuffer(env, jnameVal, &nameVal);
2) I think the ExceptionCheck block on line 932 should also be enhanced
w/ resetGSSBuffer(env, j
The resetGSSBuffer(..) call on line 829 should be removed as the inToken
structure isn't even initialized yet (initGSSBuffer call is on line 833).
Rest looks fine.
Thanks,
Valerie
On 05/22/13 11:54, John Zavgren wrote:
Greetings:
I just updated:
/jdk/src/share/native/sun/security/jgss/wrapper/G
On 05/12/13 22:39, Weijun Wang wrote:
Hi Valerie
Please take a look at
http://cr.openjdk.java.net/~weijun/8014196/webrev.01/
KeyTab.getInstance() used to return null if the keytab file does not
exists, but since we supported dynamic ktab, the result is never null.
But the KeyTab object ha
Vinnie,
Can you help reviewing my fix for 7196805 "DH Key interoperability
testing between SunJCE and JsafeJCE not successful"?
In SunJCE provider, the equality check for DH private/public keys is
based on DER encoding which may not be correct all the time due to the
optional L value defined
One question:
In DflCache.java, you mentioned that the old style block is always
created even if a new style is available.
When both are present, Is it always new style before old one? The impl
in DflCache.java seems to assume this.
Thanks,
Valerie
On 05/28/13 01:45, Weijun Wang wrote:
Pleas
Xuelei,
Can you help review this one-line fix?
8012637: Adjust CipherInputStream class to work in AEAD/GCM mode
The webrev is at:
http://cr.openjdk.java.net/~valeriep/8012637/webrev.00/
Thanks,
Valerie
Xuelei,
Here is another GCM and CipherInputStream/CipherOutputStream related
fix, i.e. for
8012900: CICO ignores AAD in GCM mode
The key changes are in CipherCore.java, GalorisCounterMode.java, the
rest files only have minor changes.
Essentially, when using AES/GCM cipher in decryption mode,
Changes look fine.
Just curious, what's the reason for the changes in KeyTab.java?
Valerie
On 06/07/13 00:31, Weijun Wang wrote:
Ding dong.
On 5/27/13 10:06 AM, Weijun Wang wrote:
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8014310/webrev.00/
The reason is that
Ok, I have no more comments.
Thanks,
Valerie
On 06/12/13 15:16, Wang Weijun wrote:
>
> 在 Jun 13, 2013，4:14 AM，"Valerie (Yu-Ching) Peng" 写道：
>
>> Changes look fine.
>> Just curious, what's the reason for the changes in KeyTab.java?
> There was an EType.get
e: RFR JDK-8014307
Date: Wed, 22 May 2013 16:18:33 -0700
From: Valerie (Yu-Ching) Peng
Reply-To: valerie.p...@oracle.com
To: security-dev@openjdk.java.net
The resetGSSBuffer(..) call on line 829 should be removed as the inToken
structure isn't even initialized yet (initGSSBuffer call
/java/javase/documentation/codeconventions-142311.html#15395
- if (!done) cipher.doFinal();
+ if (!done) {
+ cipher.doFinal();
+ }
Xuelei
On 6/12/2013 6:52 AM, Valerie (Yu-Ching) Peng wrote:
Xuelei,
Can you help review this one-line fix?
8012637: Adjust CipherInputStream class to work
ss the central authority specifies a private-value
length l, in which case the integer shall satisfy 2^(l-1)<=
x< 2^l.
I will re-test everything and let you know once I have the webrev updated.
Thanks,
Valerie
Thanks
Max
On 5/29/13 9:25 AM, Valerie (Yu-Ching) Peng wrote:
Vinnie,
Can y
I recall reviewing this use-after-free problem a while ago?
Isn't this the same one that's caught by parfait earlier?
The synopsis for 8007636 is "[parfait] False positive buffer overrun
error in jdk/src/solaris/transport/socket/socket_md.c".
Your changes do not seem to match the bug description
I have updated the webrev to address your comments:
http://cr.openjdk.java.net/~valeriep/7196805/webrev.01/
As for using JDK 8 default method feature, I think maybe it's better to
delay the adoption to a later release since it's easier for sustaining
to just grab current changes and apply to ea
John,
Just wondering that if you have checked other PKCS11 native code in the
same directory for similar problems?
It seems to me that at least p11_crypt.c, p11_digest.c, p11_general.c,
also contains similar usage pattern.
Thanks,
Valerie
On 06/18/13 19:27, John Zavgren wrote:
Greetings:
t.
Thanks,
Valerie
On 06/24/13 21:20, Weijun Wang wrote:
Code change looks fine. No regression test?
--Max
On 6/20/13 4:45 AM, Valerie (Yu-Ching) Peng wrote:
I have updated the webrev to address your comments:
http://cr.openjdk.java.net/~valeriep/7196805/webrev.01/
As for using JDK 8 default method
- The private static native boolean nssInit(...) method should be
removed? It seems obsolete by nssInitWithOptions(...) and I didn't see
it being used anywhere. Same goes for the corresponding JNI method impl,
i.e. Java_sun_security_pkcs11_Secmod_nssInit, in the j2secmod.c file.
- Particul
Great, thanks for the review!
Valerie
On 06/25/13 16:34, Wang Weijun wrote:
>
> 在 Jun 26, 2013，6:51 AM，"Valerie (Yu-Ching) Peng" 写道：
>
>> It's covered by SQE interoperability tests.
> That's enough.
>
>> In terms of regression tests, I think we sh
Sure, zapping the nssInit() for only JDK 8 is fine. Being a private
static method, I doubt that its removal will break anything though.
Thanks,
Valerie
On 06/26/13 11:38, Vincent Ryan wrote:
Thanks for the review Valerie. Comments below.
On 26 Jun 2013, at 00:23, Valerie (Yu-Ching) Peng
Well, I don't think there is anything wrong with the
SecretKeyFactory.generateSecret API.
DESKeySpec/DESedeKeySpec do check the length of the key bytes when
constructed.
If we were to accept the SecretKeySpec object as generic key spec, then
we should add additional checkings and throw Invalid
As I mentioned in my earlier email, I think you should add a check to
ensure that the result from theSecretKeySpec.getEncoded() has the right
length (i.e. 8 for DES, 24 for DESede) before passing them to
DESKey/DESedeKey.
Valerie
On 07/03/13 11:46, Anthony Scarpino wrote:
I updated the webre
cation tag checking failure). The data may have been
write to the I/O, therefor, applications who want to use GCM and CI/CO
may need to take additional actions to handle the IOException.
Xuelei
On 6/12/2013 7:16 AM, Valerie (Yu-Ching) Peng wrote:
Xuelei,
Here is another GCM and CipherInputStream/Cip
7:29 AM, Valerie (Yu-Ching) Peng wrote:
Xuelei,
I have updated the webrev for 7196382 so it uses the key size range info
from the underlying PKCS library for key size checking:
http://cr.openjdk.java.net/~valeriep/7196382/webrev.01/
107 //TBD: auto-adjust default keysize in case it's ou
While working w/ Dave for a JCE provider build, I ran into a build
failure due to a javac change, i.e. 6356530 " -Xlint:serial does not
flag abstract classes with concrete methods/members". The new-infra
build does not have this problem, only the old build does.
Here is the bug id and its web
Tony,
Did someone review this yet?
Since there are 3 bug fixes, can you separate them out into 3 webrevs?
I believe that has been the convention to have one webrev corresponding
to one bug.
Otherwise, things can get confusing for both reviewers as well as
sustaining if later they tried to back
Anyone has one minute to review this trivial and straight forward fix to
existing PKCS11 regression test?
8020321: Problem in PKCS11 regression test TestRSAKeyLength
webrev: http://cr.openjdk.java.net/~valeriep/8020321/webrev.00/
Thanks,
Valerie
Need to make sure this won't happen again by adding a check.
Thanks for another quick review,
Valerie
On 07/10/13 18:30, Xuelei Fan wrote:
Wow, you are so careful about the hard-coded arrays. Looks fine.
Xuelei
On 7/11/2013 9:10 AM, Valerie (Yu-Ching) Peng wrote:
Anyone has one minu
n may vary.
Thanks,
Valerie
On 07/10/13 21:56, Anthony Scarpino wrote:
Sure I'll break it up if that's easier and someone will review it.
thanks
Tony
On 07/10/2013 06:07 PM, Valerie (Yu-Ching) Peng wrote:
Tony,
Did someone review this yet?
Since there are 3 bug fixes, can you se
Please find comments inline.
On 07/17/13 13:51, Anthony Scarpino wrote:
I have broken these into two webrev. The first:
JDK-8012971 PKCS11Test hiding exception failures
http://cr.openjdk.java.net/~ascarpino/8012971/webrev.01/
handles the minimum changes needed for PKCS11Test to function and
Just noticed that the newly-added import statement on line 32 seems
redundant?
Webrev seems the same?
Thanks,
Valerie
On 07/18/13 15:17, Anthony Scarpino wrote:
On 07/18/2013 02:49 PM, Valerie (Yu-Ching) Peng wrote:
Please find comments inline.
On 07/17/13 13:51, Anthony Scarpino wrote
t was necessary, but I found the unused variable that was triggering
the compile error without it.
Tony
On 07/18/2013 03:40 PM, Valerie (Yu-Ching) Peng wrote:
Just noticed that the newly-added import statement on line 32 seems
redundant?
Webrev seems the same?
Thanks,
Valerie
On 07/18/13
The changes look fine.
However, the dateCheckedAgainst argument for method SingleResponse
constructor becomes obsolete and not used at all.
Should it be removed from the method signature, i.e. any reason to keep
this?
Thanks,
Valerie
On 07/19/13 09:39, Vincent Ryan wrote:
Please review the f
263 System.arraycopy(data, 900, data, 0, 100);
264 is.read(data, 0, 900);
Do you really mean to overwrite the data[0..99] that you just copied on
line 263 with line 264?
In addition, don't you want to know how much is read in order to exclude
the data from ea
On 07/24/13 13:53, Anthony Scarpino wrote:
On 07/23/2013 06:00 PM, Valerie (Yu-Ching) Peng wrote:
263 System.arraycopy(data, 900, data, 0, 100);
264 is.read(data, 0, 900);
Do you really mean to overwrite the data[0..99] that you just copied on
line 263 with
Looks good~
Thanks,
Valerie
On 07/25/13 15:17, Anthony Scarpino wrote:
On 07/24/2013 06:37 PM, Valerie (Yu-Ching) Peng wrote:
On 07/24/13 13:53, Anthony Scarpino wrote:
On 07/23/2013 06:00 PM, Valerie (Yu-Ching) Peng wrote:
263 System.arraycopy(data, 900, data, 0, 100
Sounds like Xuelie is referring to the general model between the XXX and
XXXSpi classes, i.e. XXX is the public class which encapsulate XXXSpi
(the underlying engine class that service providers implement). For
example, javax.crypto.Cipher and javax.crypto.CipherSpi is one example.
But I recall
Was catching up on other tasks, will come back to this today or tomorrow...
Thanks,
Valerie
On 08/06/13 20:49, Weijun Wang wrote:
Ping again.
On 7/29/13 5:11 PM, Weijun Wang wrote:
Hi Valerie
Please review the capaths code change at
http://cr.openjdk.java.net/~weijun/8012615/webrev.01/
1. Line 255, "returns if keys exists" should be "returns true if key
exists".
2. Line 257, "@see get" should be "@see get0"?
3. You may want to add the following to the public getAll(String...
keys) method.
@throws IllegalArgumentException ...
looks fine
Before I looked at Realm.java, I
08/22/13 21:55, Weijun Wang wrote:
On 8/23/13 10:39 AM, Valerie (Yu-Ching) Peng wrote:
1. Line 255, "returns if keys exists" should be "returns true if key
exists".
2. Line 257, "@see get" should be "@see get0"?
I meant looking at the how IAE is thrown
The changes look fine - I don't care for supporting the chaining since
it complicates up the parsing code very much. Oh-well.
But at least the new code is way shorter than the older one.
It's unfortunate that in order to support this chaining, we ended up
wasting more cycles processing the who
Fixes look fine.
Thanks,
Valerie
On 09/18/13 06:59, Weijun Wang wrote:
Hi Valerie
I've backported 8012615 to 7u60. Please take a review
http://cr.openjdk.java.net/~weijun/8012615/7u-dev/webrev.00/
Changes include:
1. Direct copy of parseCapaths and parseHierarchy from jdk8, except for
Xuelei,
Since the source for OracleUcrypto provider isn't included in OpenJDK,
it probably makes more sense to have its regression tests off OpenJDK as
well. Please find the changes for the test relocation under 8014374:
Webrev: http://cr.openjdk.java.net/~valeriep/8014374/webrev.00/
Thanks,
The new tests in the closed repo will also be addressed under 8014374.
So, you won't see them until this fix is integrated.
Thanks,
Valerie
On 09/27/13 17:34, Bradford Wetmore wrote:
On 9/27/2013 4:49 PM, Valerie (Yu-Ching) Peng wrote:
Xuelei,
Since the source for OracleUcrypto pro
Well, can someone please review the following trivial fix today or early
Monday?
8025967: addition of -Werror broke the old build
JCE is still using the legacy build and as a result, I have to fix build
warnings in other components in order for the whole build to succeed.
The changes are all
look over the
non-security component changes.
--Sean
On 10/04/2013 06:24 PM, Valerie (Yu-Ching) Peng wrote:
Well, can someone please review the following trivial fix today or early
Monday?
8025967: addition of -Werror broke the old build
JCE is still using the legacy build and as a result, I ha
Can someone help review my fixes for 8026943 "SQE test
jce/Global/Cipher/SameBuffer failed"?
According to Cipher javadoc, both its update(...) and doFinal(...)
methods should be copy-safe, meaning the |input| and |output| buffers
can reference the same byte array and no unprocessed input dat
If the test passed, these temporary files should be removed, shouldn't they?
Thanks,
Valerie
On 11/19/13 07:29, Vincent Ryan wrote:
On 19/11/2013 14:30, Weijun Wang wrote:
Why not just put the file in the current directory? That's the real
scratch dir. Or the cfg file needs an absolute path?
Can someone please help review my fixes for 7200306: SunPKCS11 provider
delays the check of DSA key size for SHA1withDSA to sign() instead of
init()?
Native PKCS11 libraries don't seem to check the key during the
initialization calls (triggered by initSign()/initVerify()).
Rather, it errors
:37 PM, Valerie (Yu-Ching) Peng wrote:
Can someone please help review my fixes for 7200306: SunPKCS11 provider
delays the check of DSA key size for SHA1withDSA to sign() instead of
init()?
Native PKCS11 libraries don't seem to check the key during the
initialization calls (triggered by ini
Thanks for the prompt review~
Valerie
On 11/22/13 12:20, Sean Mullan wrote:
On 11/22/2013 02:54 PM, Valerie (Yu-Ching) Peng wrote:
Even if Solaris PKCS11 provider starts to support 2048-bit DSA keys, its
SHA1withDSA signature impl should still only accept up-to-1024-bit DSA
keys. The longer
Please help review this regression test fix which addresses the setting
on test utility classes
as well as skip testing against newer NSS libraries for a problem with NSS.
The webrev can be found at:
http://cr.openjdk.java.net/~valeriep/8029158/webrev.00/
Thanks,
Valerie
Changes look fine.
Thanks,
Valerie
On 12/27/13 01:59, Weijun Wang wrote:
Hi All
Please review the code changes at
http://cr.openjdk.java.net/~weijun/8031046/webrev.00/
In 8016594, we updated Windows LSA retrieval so that when the existing
TGT has a session key whose etype is not supporte
Well, there are some changes that look strange which I need more time to
figure out.
For example, the purpose for the 2 new pkg private methods of poll(Pool)
and release(Pool, Session) of the static class Pool.
Also, now that every P11Cipher "object" has its own session pool, will
this have
Please see comments inline.
On 02/10/14 16:30, Anthony Scarpino wrote:
On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote:
Well, there are some changes that look strange which I need more time to
figure out.
For example, the purpose for the 2 new pkg private methods of poll(Pool)
and
Max,
Changes look fine.
However, I noticed some calls which may throw exceptions but no check is
added, e.g.
593 (*env)->SetObjectArrayElement(env, address_list, index, address);
BTW, I noticed there are several existing calls to
ExceptionOccurred(...) which can be replaced with Ex
Can someone please review the fixes which checks for pending exceptions
in native code "pcsc_md.c"?
The fix is trivial scope-wise.
Webrev: http://cr.openjdk.java.net/~valeriep/8033571/webrev.00/
Thanks,
Valerie
1 - 100 of 265 matches
Mail list logo
