Integrated: 8267319: Use larger default key sizes and algorithms based on CNSA
On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! This pull request has now been integrated. Changeset: 313bc7f6 Author:Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/313bc7f64f69d8f352d495d2c35bea62aca910e4 Stats: 504 lines in 29 files changed: 326 ins; 8 del; 170 mod 8267319: Use larger default key sizes and algorithms based on CNSA Reviewed-by: weijun, xuelei - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v9]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Use uppercase for 1st letter in some comments. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/a48ccef5..8b7bc16a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=07-08 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8]
On Thu, 24 Mar 2022 06:41:11 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added comment regarding possible deadlocks. > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java > line 137: > >> 135: public static final int DEF_ED_KEY_SIZE; >> 136: public static final int DEF_XEC_KEY_SIZE; >> 137: // the logic for finding the max allowable value in >> getDefAESKeySize() > > Capital the 1st letter? Ok~ - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Added comment regarding possible deadlocks. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/1eb63292..a48ccef5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=06-07 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
On Wed, 23 Mar 2022 21:51:51 GMT, Xue-Lei Andrew Fan wrote: >> My very first prototype is to implement the AES keysize calculation as you >> commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. >> However, it is later discovered through testing that this leads to deadlocks >> as this interferes with provider loading. Given that AES key size is just a >> small piece of the whole puzzle, it seems safer to defer this to a later >> point when it's actually needed rather than touching the whole provider >> loading logic just to make this a static int. Performance-wise, this is a >> very small piece, generally should just be the AtomicInteger.get(). > > I see. > > Would you mind add a comment about the provider loading impact, just in case > someone else have similar questions in the future? Sure, I can do that. Will add a comment about this. - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
On Wed, 23 Mar 2022 04:46:48 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Minor code refactoring > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java > line 129: > >> 127: return currVal; >> 128: } >> 129: > > I'm not very sure of this method. Is it performance friendly if making the > default key size calculation in the static block (from line 142 to the end of > the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. > > Or did I miss something? My very first prototype is to implement the AES keysize calculation as you commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. However, it is later discovered through testing that this leads to deadlocks as this interferes with provider loading. Given that AES key size is just a small piece of the whole puzzle, it seems safer to defer this to a later point when it's actually needed rather than touching the whole provider loading logic just to make this a static int. Performance-wise, this is a very small piece, generally should just be the AtomicInteger.get(). - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor code refactoring - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/c8ae1655..1eb63292 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=05-06 Stats: 20 lines in 1 file changed: 1 ins; 7 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6]
On Tue, 15 Mar 2022 20:51:25 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before >> shifting to PQC, NSA replaced its Suite B cryptography recommendations with >> the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures >> (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. >> The changes are mostly in keytool, jarsigner and their regression tests, so >> @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional > commit since the last revision: > > Removed NPE from the catch statement. Could you please please review CSR at: https://bugs.openjdk.java.net/browse/JDK-8282995 Thanks! - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Removed NPE from the catch statement. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/48f562ab..c8ae1655 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
On Mon, 14 Mar 2022 21:24:15 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update again and undo DSA changes
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java
> line 122:
>
>> 120: default -> {
>> 121: throw new ProviderException
>> 122: ("Unrecognized algorithm for checking key
>> size");
>
> If it's an unknown key algorithm, is it possible we just ignore it and keep
> using `minKeyLen` and `maxKeyLen`?
Well, instead of ignore unknown key algorithm, perhaps safer to throw Exception
so it can be caught and handled during develop time. P11KeyPairGenerator class
is only used for known algorithms which it is registered for, so probably ok to
go either way. I'd prefer to play it safe and force a review of this block of
code when new algorithm is added.
-
PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
On Mon, 14 Mar 2022 21:18:56 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update again and undo DSA changes > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java > line 101: > >> 99: // set default key sizes and apply our own algorithm-specific >> limits >> 100: // override lower limit to disallow unsecure keys being >> generated >> 101: // override upper limit to deter DOS attack > > Not a P11 expert, but I assume `algorithm` here is already guaranteed to be > in uppercase? Yes, for P11KeyPairGenerator, its algorithm values are all in uppercase. I verified it with an existing regression test. - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
On Mon, 14 Mar 2022 21:08:30 GMT, Weijun Wang wrote:
>> Valerie Peng has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update again and undo DSA changes
>
> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java
> line 121:
>
>> 119: v = max;
>> 120: }
>> 121: } catch (NullPointerException | NoSuchAlgorithmException
>> ne) {
>
> There is no need to mention NPE.
Sure.
-
PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update again and undo DSA changes - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/f728aa7d..48f562ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=03-04 Stats: 45 lines in 9 files changed: 8 ins; 2 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v4]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to match the latest SignatureUtil.ifcFfcStrength() impl - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/099a6d92..f728aa7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]
On Wed, 9 Mar 2022 19:44:39 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update JarSigner javadoc to make it consistent with previous update > > src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > >> 437: * Specifically, if a DSA or RSA key with a key size no less >> than 7680 >> 438: * bits, or an EC key with a key size no less than 512 bits, >> 439: * SHA-512 will be used as the hash function for the signature. > > In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). Right, there are a few places which this is documented. Code and doc aren't closely coupled together plus changed course a few times... I will fix this and double check other files. Thanks! - PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update JarSigner javadoc to make it consistent with previous update - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/7f6fe4b5..099a6d92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=01-02 Stats: 16 lines in 2 files changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2]
> It's been several years since we increased the default key sizes. Before > shifting to PQC, NSA replaced its Suite B cryptography recommendations with > the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures > (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. > The changes are mostly in keytool, jarsigner and their regression tests, so > @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to use SHA-384 as long as the keysize permits. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/27e27836..7f6fe4b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7652=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7652=00-01 Stats: 27 lines in 7 files changed: 6 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA
On Wed, 2 Mar 2022 04:02:45 GMT, Anthony Scarpino wrote: > I have some compatibility concerns about the AES change breaking code that > expects a SecretKeySpec of 16 bytes. I can see situations where > '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, > I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will > throw an exception. I haven't looked at other modes. Well, I am not sure how specifying a 32-byte SecretKeySpec (instance of a SecretKey) with AES Cipher would trigger AES_128_GCM op? Shouldn't the keysize be detected when Cipher.init() is called and then invoking the right op? True that this default key size change would impact callers who do not specify key size but then made the assumption of key being 16-byte. Well, the key generator javadoc did warn about not setting a default, i.e. different providers may have different default key size and that the default key size may change later for the same provider. So, it's not like we have not warned about it... - PR: https://git.openjdk.java.net/jdk/pull/7652
RFR: 8267319: Use larger default key sizes and algorithms based on CNSA
It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: - SHA-384 for secure hashing - AES-256 for symmetric encryption - RSA with 3072 bit keys for digital signatures and for key exchange - Diffie Hellman (DH) with 3072 bit keys for key exchange - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? Thanks! - Commit messages: - 8267319: Use larger default key sizes and algorithms based on CNSA Changes: https://git.openjdk.java.net/jdk/pull/7652/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=7652=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267319 Stats: 479 lines in 29 files changed: 321 ins; 6 del; 152 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652
Re: RFR: 8271616: oddPart in MutableBigInteger::mutableModInverse contains info on final result
On Tue, 3 Aug 2021 19:05:55 GMT, Weijun Wang wrote: > `oddPart` contains a lot of info on the `modInverse` output, sometimes it's > even the same. Clearing it in case the result is sensitive. > > No new regression test since it's difficult to access a temporary local > variable in an internal class. Existing tier1-2 tests passed. Marked as reviewed by valeriep (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/4973
Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v3]
On Tue, 29 Jun 2021 00:07:41 GMT, Sean Coffey wrote: >> Sufficient permissions missing if this code was ever to run with >> SecurityManager. >> >> Cleanest approach appears to be use of InnocuousThread to create the >> cleaner/poller threads. >> Test case coverage extended to cover the SecurityManager scenario. >> >> Reviewer request: @valeriepeng > > Sean Coffey has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - Edits from review > - Merge remote-tracking branch 'origin/master' into pkcs11-perms > - Move TokenPoller to Runnable > - 8269034: AccessControlException for SunPKCS11 daemon threads Update looks good. Thanks, Valerie - Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk17/pull/117
Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v2]
On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey wrote:
>> Sufficient permissions missing if this code was ever to run with
>> SecurityManager.
>>
>> Cleanest approach appears to be use of InnocuousThread to create the
>> cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>>
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Move TokenPoller to Runnable
test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 63:
> 61: Policy.setPolicy(new SimplePolicy());
> 62: System.setSecurityManager(new SecurityManager());
> 63: }
Just curious, why split the loop into 2 and set the SecurityManager in between
the two loops? Can't we just set the policy/security manager before the loop?
test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 137:
> 135: perms.add(new SecurityPermission("insertProvider.*"));
> 136: perms.add(new SecurityPermission("removeProvider.*"));
> 137: }
The test still pass without the following permission:
perms.add(new RuntimePermission("accessClassInPackage.sun.*"));
perms.add(new
RuntimePermission("accessClassInPackage.sun.security.pkcs11.*"));
perms.add(new SecurityPermission("clearProviderProperties.*"));
Remove them?
test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh line 142:
> 140: -Dtest.src=${TESTSRC} \
> 141: -Dtest.classes=${TESTCLASSES} \
> 142: -Djava.security.debug=${DEBUG} \
Save these java options and use it for both invocation? This way it's easier to
tell that there is no difference among these two except for the extra argument.
test/jdk/sun/security/pkcs11/Provider/MultipleLogins.sh line 143:
> 141: -Dtest.classes=${TESTCLASSES} \
> 142: -Djava.security.debug=${DEBUG} \
> 143: MultipleLogins ${TESTSRC}${FS}MultipleLogins.policy || exit 11
There is no MultipleLogins.policy file. The test just uses the internal
SimplePolicy object. Maybe just use a string like "useSimplePolicy".
-
PR: https://git.openjdk.java.net/jdk17/pull/117
Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v2]
On Fri, 25 Jun 2021 19:39:22 GMT, Valerie Peng wrote:
>> Sean Coffey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move TokenPoller to Runnable
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line
> 952:
>
>> 950: AccessController.doPrivileged((PrivilegedAction) () -> {
>> 951: Thread t = InnocuousThread.newSystemThread(
>> 952: "Poller " + getName(),
>
> nit: "Poller " -> "Poller-" (like before)?
It seems that the AccessController.doPrivileged((PrivilegedAction) () ->
{} is un-necessary? I tried your test without it and test still passes.
-
PR: https://git.openjdk.java.net/jdk17/pull/117
Re: [jdk17] RFR: 8269034: AccessControlException for SunPKCS11 daemon threads [v2]
On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey wrote:
>> Sufficient permissions missing if this code was ever to run with
>> SecurityManager.
>>
>> Cleanest approach appears to be use of InnocuousThread to create the
>> cleaner/poller threads.
>> Test case coverage extended to cover the SecurityManager scenario.
>>
>> Reviewer request: @valeriepeng
>
> Sean Coffey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Move TokenPoller to Runnable
src/java.base/share/lib/security/default.policy line 131:
> 129: permission java.lang.RuntimePermission
> "accessClassInPackage.com.sun.crypto.provider";
> 130: permission java.lang.RuntimePermission
> "accessClassInPackage.jdk.internal.misc";
> 131: permission java.lang.RuntimePermission
> "accessClassInPackage.sun.security.*";
Can we just do necessary changes? I noticed that this file seems to have mixed
style, i.e. some lines are longer than 80 chars and some break into 2 lines
with length less than 80 chars. Since the whole file is mixed, maybe just do
what must be changed.
src/java.base/share/lib/security/default.policy line 142:
> 140: permission java.security.SecurityPermission
> "clearProviderProperties.*";
> 141: permission java.security.SecurityPermission
> "removeProviderProperty.*";
> 142: permission java.security.SecurityPermission
> "getProperty.auth.login.defaultCallbackHandler";
Same "avoid unnecessary changes" comment here.
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line
952:
> 950: AccessController.doPrivileged((PrivilegedAction) () -> {
> 951: Thread t = InnocuousThread.newSystemThread(
> 952: "Poller " + getName(),
nit: "Poller " -> "Poller-" (like before)?
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line
956:
> 954: assert t.getContextClassLoader() == null;
> 955: t.setDaemon(true);
> 956: t.setPriority(Thread.MIN_PRIORITY);
nit: supply this priority value as an argument to the
InnocuousThread.newSystemThread() call instead?
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line
1033:
> 1031: }
> 1032: cleaner = new NativeResourceCleaner();
> 1033: AccessController.doPrivileged((PrivilegedAction) () -> {
It seems that the AccessController.doPrivileged((PrivilegedAction) () -> {} is
un-necessary? I tried your test without it and test still passes.
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line
1039:
> 1037: assert t.getContextClassLoader() == null;
> 1038: t.setDaemon(true);
> 1039: t.setPriority(Thread.MIN_PRIORITY);
nit: supply this priority value as an argument to the
InnocuousThread.newSystemThread() call instead?
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line
1212:
> 1210:
> 1211: this.token = token;
> 1212: if (cleaner == null) {
This check seems duplicate to the one in createCleaner() call.
test/jdk/sun/security/pkcs11/Provider/MultipleLogins.java line 56:
> 54: System.out.println("No NSS config found. Skipping.");
> 55: return;
> 56: }
Move this if-check block of code up before the for-loop?
-
PR: https://git.openjdk.java.net/jdk17/pull/117
Re: RFR: 8252412: [macos11] system dynamic libraries removed from filesystem [v2]
On Mon, 18 Jan 2021 11:03:06 GMT, Martin Buchholz wrote: >> 8252412: [macos11] system dynamic libraries removed from filesystem > > Martin Buchholz has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. Marked as reviewed by valeriep (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/2119
Re: RFR: 8252412: [macos11] system dynamic libraries removed from filesystem [v2]
On Fri, 22 Jan 2021 22:55:22 GMT, Jiangli Zhou wrote: >> Ok, I see Java_sun_security_smartcardio_PlatformPCSC_initialize does dlopen >> using the 'jLibName' (string) obtained from getLibraryName() and throws >> IOException if dlopen fails. The change seems safe enough. >> >> I'm wondering if you want to check the file first then check the parent >> directory if the file does not exist. Not sure if that's a little more >> optimal on older macos, so I'll leave that to you to decide. >> >> For the jtreg test, how about converting Dominik's TestPCSC? As the file is >> a shared for 'unix' platforms, it feels safer at least with some level of >> unit test. Could you please give some more contexts about the >> functionalities associated with PCSC are broken on macos? > > Martin and I had an off-line chat and Martin convinced me that the existing > jtreg tests (such as test/jdk/javax/smartcardio and > test/jdk/sun/security/smartcardio are sufficient) to cover the case. Right, existing tests should cover this already since running the test requires that the library must be loaded. Changes look fine, thanks for fixing this. Kind of surprised the existing filtering didn't catch this as security-related changes and send this to security group for review. - PR: https://git.openjdk.java.net/jdk/pull/2119
Re: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v4]
On Mon, 18 Jan 2021 13:39:04 GMT, Claes Redestad wrote: >> - The MD5 intrinsics added by >> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that >> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics >> from which the MD5 intrinsic takes inspiration >> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to >> make it acceptable to use inline and replace the array in MD5 wholesale. >> This improves performance both in the presence and the absence of the >> intrinsic optimization. >> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element >> arrays), but allocating the array lazily gets most of the speed-up in the >> presence of an intrinsic while being neutral in its absence. >> >> Baseline: >> (digesterName) (length)Cnt Score >> Error Units >> MessageDigests.digestMD516 15 >> 2714.307 ± 21.133 ops/ms >> MessageDigests.digestMD5 1024 15 >> 318.087 ±0.637 ops/ms >> MessageDigests.digest SHA-116 15 >> 1387.266 ± 40.932 ops/ms >> MessageDigests.digest SHA-1 1024 15 >> 109.273 ±0.149 ops/ms >> MessageDigests.digestSHA-25616 15 >> 995.566 ± 21.186 ops/ms >> MessageDigests.digestSHA-256 1024 15 >> 89.104 ±0.079 ops/ms >> MessageDigests.digestSHA-51216 15 >> 803.030 ± 15.722 ops/ms >> MessageDigests.digestSHA-512 1024 15 >> 115.611 ±0.234 ops/ms >> MessageDigests.getAndDigest MD516 15 >> 2190.367 ± 97.037 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 >> 302.903 ±1.809 ops/ms >> MessageDigests.getAndDigestSHA-116 15 >> 1262.656 ± 43.751 ops/ms >> MessageDigests.getAndDigestSHA-1 1024 15 >> 104.889 ±3.554 ops/ms >> MessageDigests.getAndDigest SHA-25616 15 >> 914.541 ± 55.621 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 >> 85.708 ±1.394 ops/ms >> MessageDigests.getAndDigest SHA-51216 15 >> 737.719 ± 53.671 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 >> 112.307 ±1.950 ops/ms >> >> GC: >> MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 >> 312.011 ±0.005B/op >> MessageDigests.getAndDigest:·gc.alloc.rate.normSHA-116 15 >> 584.020 ±0.006B/op >> MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-25616 15 >> 544.019 ±0.016B/op >> MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-51216 15 >> 1056.037 ±0.003B/op >> >> Target: >> Benchmark (digesterName) (length)Cnt >> Score Error Units >> MessageDigests.digestMD516 15 >> 3134.462 ± 43.685 ops/ms >> MessageDigests.digestMD5 1024 15 >> 323.667 ±0.633 ops/ms >> MessageDigests.digest SHA-116 15 >> 1418.742 ± 38.223 ops/ms >> MessageDigests.digest SHA-1 1024 15 >> 110.178 ±0.788 ops/ms >> MessageDigests.digestSHA-25616 15 >> 1037.949 ± 21.214 ops/ms >> MessageDigests.digestSHA-256 1024 15 >> 89.671 ±0.228 ops/ms >> MessageDigests.digestSHA-51216 15 >> 812.028 ± 39.489 ops/ms >> MessageDigests.digestSHA-512 1024 15 >> 116.738 ±0.249 ops/ms >> MessageDigests.getAndDigest MD516 15 >> 2314.379 ± 229.294 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 >> 307.835 ±5.730 ops/ms >> MessageDigests.getAndDigestSHA-116 15 >> 1326.887 ± 63.263 ops/ms >> MessageDigests.getAndDigestSHA-1 1024 15 >> 106.611 ±2.292 ops/ms >> MessageDigests.getAndDigest SHA-25616 15 >> 961.589 ± 82.052 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 >> 88.646 ±0.194 ops/ms >> MessageDigests.getAndDigest SHA-51216 15 >> 775.417 ± 56.775 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 >> 112.904 ±2.014 ops/ms >>
Re: RFR: 8259498: Reduce overhead of MD5 and SHA digests [v2]
On Fri, 15 Jan 2021 23:36:35 GMT, Claes Redestad wrote: >> - The MD5 intrinsics added by >> [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that >> the `int[] x` isn't actually needed. This also applies to the SHA intrinsics >> from which the MD5 intrinsic takes inspiration >> - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to >> make it acceptable to use inline and replace the array in MD5 wholesale. >> This improves performance both in the presence and the absence of the >> intrinsic optimization. >> - Doing the exact same thing in the SHA impls would be unwieldy (64+ element >> arrays), but allocating the array lazily gets most of the speed-up in the >> presence of an intrinsic while being neutral in its absence. >> >> Baseline: >> (digesterName) (length)Cnt Score >> Error Units >> MessageDigests.digestMD516 15 >> 2714.307 ± 21.133 ops/ms >> MessageDigests.digestMD5 1024 15 >> 318.087 ±0.637 ops/ms >> MessageDigests.digest SHA-116 15 >> 1387.266 ± 40.932 ops/ms >> MessageDigests.digest SHA-1 1024 15 >> 109.273 ±0.149 ops/ms >> MessageDigests.digestSHA-25616 15 >> 995.566 ± 21.186 ops/ms >> MessageDigests.digestSHA-256 1024 15 >> 89.104 ±0.079 ops/ms >> MessageDigests.digestSHA-51216 15 >> 803.030 ± 15.722 ops/ms >> MessageDigests.digestSHA-512 1024 15 >> 115.611 ±0.234 ops/ms >> MessageDigests.getAndDigest MD516 15 >> 2190.367 ± 97.037 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 >> 302.903 ±1.809 ops/ms >> MessageDigests.getAndDigestSHA-116 15 >> 1262.656 ± 43.751 ops/ms >> MessageDigests.getAndDigestSHA-1 1024 15 >> 104.889 ±3.554 ops/ms >> MessageDigests.getAndDigest SHA-25616 15 >> 914.541 ± 55.621 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 >> 85.708 ±1.394 ops/ms >> MessageDigests.getAndDigest SHA-51216 15 >> 737.719 ± 53.671 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 >> 112.307 ±1.950 ops/ms >> >> GC: >> MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 >> 312.011 ±0.005B/op >> MessageDigests.getAndDigest:·gc.alloc.rate.normSHA-116 15 >> 584.020 ±0.006B/op >> MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-25616 15 >> 544.019 ±0.016B/op >> MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-51216 15 >> 1056.037 ±0.003B/op >> >> Target: >> Benchmark (digesterName) (length)Cnt >> Score Error Units >> MessageDigests.digestMD516 15 >> 3134.462 ± 43.685 ops/ms >> MessageDigests.digestMD5 1024 15 >> 323.667 ±0.633 ops/ms >> MessageDigests.digest SHA-116 15 >> 1418.742 ± 38.223 ops/ms >> MessageDigests.digest SHA-1 1024 15 >> 110.178 ±0.788 ops/ms >> MessageDigests.digestSHA-25616 15 >> 1037.949 ± 21.214 ops/ms >> MessageDigests.digestSHA-256 1024 15 >> 89.671 ±0.228 ops/ms >> MessageDigests.digestSHA-51216 15 >> 812.028 ± 39.489 ops/ms >> MessageDigests.digestSHA-512 1024 15 >> 116.738 ±0.249 ops/ms >> MessageDigests.getAndDigest MD516 15 >> 2314.379 ± 229.294 ops/ms >> MessageDigests.getAndDigest MD5 1024 15 >> 307.835 ±5.730 ops/ms >> MessageDigests.getAndDigestSHA-116 15 >> 1326.887 ± 63.263 ops/ms >> MessageDigests.getAndDigestSHA-1 1024 15 >> 106.611 ±2.292 ops/ms >> MessageDigests.getAndDigest SHA-25616 15 >> 961.589 ± 82.052 ops/ms >> MessageDigests.getAndDigest SHA-256 1024 15 >> 88.646 ±0.194 ops/ms >> MessageDigests.getAndDigest SHA-51216 15 >> 775.417 ± 56.775 ops/ms >> MessageDigests.getAndDigest SHA-512 1024 15 >> 112.904 ±2.014 ops/ms >>
Re: RFR: 8259498: Reduce overhead of MD5 and SHA digests
On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote: > - The MD5 intrinsics added by > [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that > the `int[] x` isn't actually needed. This also applies to the SHA intrinsics > from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to > make it acceptable to use inline and replace the array in MD5 wholesale. This > improves performance both in the presence and the absence of the intrinsic > optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element > arrays), but allocating the array lazily gets most of the speed-up in the > presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length)Cnt Score > Error Units > MessageDigests.digestMD516 15 > 2714.307 ± 21.133 ops/ms > MessageDigests.digestMD5 1024 15 > 318.087 ±0.637 ops/ms > MessageDigests.digest SHA-116 15 > 1387.266 ± 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 > 109.273 ±0.149 ops/ms > MessageDigests.digestSHA-25616 15 > 995.566 ± 21.186 ops/ms > MessageDigests.digestSHA-256 1024 15 > 89.104 ±0.079 ops/ms > MessageDigests.digestSHA-51216 15 > 803.030 ± 15.722 ops/ms > MessageDigests.digestSHA-512 1024 15 > 115.611 ±0.234 ops/ms > MessageDigests.getAndDigest MD516 15 > 2190.367 ± 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 > 302.903 ±1.809 ops/ms > MessageDigests.getAndDigestSHA-116 15 > 1262.656 ± 43.751 ops/ms > MessageDigests.getAndDigestSHA-1 1024 15 > 104.889 ±3.554 ops/ms > MessageDigests.getAndDigest SHA-25616 15 > 914.541 ± 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 > 85.708 ±1.394 ops/ms > MessageDigests.getAndDigest SHA-51216 15 > 737.719 ± 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 > 112.307 ±1.950 ops/ms > > GC: > MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 > 312.011 ±0.005B/op > MessageDigests.getAndDigest:·gc.alloc.rate.normSHA-116 15 > 584.020 ±0.006B/op > MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-25616 15 > 544.019 ±0.016B/op > MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-51216 15 > 1056.037 ±0.003B/op > > Target: > Benchmark (digesterName) (length)Cnt > Score Error Units > MessageDigests.digestMD516 15 > 3134.462 ± 43.685 ops/ms > MessageDigests.digestMD5 1024 15 > 323.667 ±0.633 ops/ms > MessageDigests.digest SHA-116 15 > 1418.742 ± 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 > 110.178 ±0.788 ops/ms > MessageDigests.digestSHA-25616 15 > 1037.949 ± 21.214 ops/ms > MessageDigests.digestSHA-256 1024 15 > 89.671 ±0.228 ops/ms > MessageDigests.digestSHA-51216 15 > 812.028 ± 39.489 ops/ms > MessageDigests.digestSHA-512 1024 15 > 116.738 ±0.249 ops/ms > MessageDigests.getAndDigest MD516 15 > 2314.379 ± 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 > 307.835 ±5.730 ops/ms > MessageDigests.getAndDigestSHA-116 15 > 1326.887 ± 63.263 ops/ms > MessageDigests.getAndDigestSHA-1 1024 15 > 106.611 ±2.292 ops/ms > MessageDigests.getAndDigest SHA-25616 15 > 961.589 ± 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 > 88.646 ±0.194 ops/ms > MessageDigests.getAndDigest SHA-51216 15 > 775.417 ± 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 > 112.904 ±2.014 ops/ms > > GC > MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 > 232.009 ±
Re: RFR: 8259498: Reduce overhead of MD5 and SHA digests
On Sun, 20 Dec 2020 20:27:03 GMT, Claes Redestad wrote: > - The MD5 intrinsics added by > [JDK-8250902](https://bugs.openjdk.java.net/browse/JDK-8250902) shows that > the `int[] x` isn't actually needed. This also applies to the SHA intrinsics > from which the MD5 intrinsic takes inspiration > - Using VarHandles we can simplify the code in `ByteArrayAccess` enough to > make it acceptable to use inline and replace the array in MD5 wholesale. This > improves performance both in the presence and the absence of the intrinsic > optimization. > - Doing the exact same thing in the SHA impls would be unwieldy (64+ element > arrays), but allocating the array lazily gets most of the speed-up in the > presence of an intrinsic while being neutral in its absence. > > Baseline: > (digesterName) (length)Cnt Score > Error Units > MessageDigests.digestMD516 15 > 2714.307 ± 21.133 ops/ms > MessageDigests.digestMD5 1024 15 > 318.087 ±0.637 ops/ms > MessageDigests.digest SHA-116 15 > 1387.266 ± 40.932 ops/ms > MessageDigests.digest SHA-1 1024 15 > 109.273 ±0.149 ops/ms > MessageDigests.digestSHA-25616 15 > 995.566 ± 21.186 ops/ms > MessageDigests.digestSHA-256 1024 15 > 89.104 ±0.079 ops/ms > MessageDigests.digestSHA-51216 15 > 803.030 ± 15.722 ops/ms > MessageDigests.digestSHA-512 1024 15 > 115.611 ±0.234 ops/ms > MessageDigests.getAndDigest MD516 15 > 2190.367 ± 97.037 ops/ms > MessageDigests.getAndDigest MD5 1024 15 > 302.903 ±1.809 ops/ms > MessageDigests.getAndDigestSHA-116 15 > 1262.656 ± 43.751 ops/ms > MessageDigests.getAndDigestSHA-1 1024 15 > 104.889 ±3.554 ops/ms > MessageDigests.getAndDigest SHA-25616 15 > 914.541 ± 55.621 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 > 85.708 ±1.394 ops/ms > MessageDigests.getAndDigest SHA-51216 15 > 737.719 ± 53.671 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 > 112.307 ±1.950 ops/ms > > GC: > MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 > 312.011 ±0.005B/op > MessageDigests.getAndDigest:·gc.alloc.rate.normSHA-116 15 > 584.020 ±0.006B/op > MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-25616 15 > 544.019 ±0.016B/op > MessageDigests.getAndDigest:·gc.alloc.rate.norm SHA-51216 15 > 1056.037 ±0.003B/op > > Target: > Benchmark (digesterName) (length)Cnt > Score Error Units > MessageDigests.digestMD516 15 > 3134.462 ± 43.685 ops/ms > MessageDigests.digestMD5 1024 15 > 323.667 ±0.633 ops/ms > MessageDigests.digest SHA-116 15 > 1418.742 ± 38.223 ops/ms > MessageDigests.digest SHA-1 1024 15 > 110.178 ±0.788 ops/ms > MessageDigests.digestSHA-25616 15 > 1037.949 ± 21.214 ops/ms > MessageDigests.digestSHA-256 1024 15 > 89.671 ±0.228 ops/ms > MessageDigests.digestSHA-51216 15 > 812.028 ± 39.489 ops/ms > MessageDigests.digestSHA-512 1024 15 > 116.738 ±0.249 ops/ms > MessageDigests.getAndDigest MD516 15 > 2314.379 ± 229.294 ops/ms > MessageDigests.getAndDigest MD5 1024 15 > 307.835 ±5.730 ops/ms > MessageDigests.getAndDigestSHA-116 15 > 1326.887 ± 63.263 ops/ms > MessageDigests.getAndDigestSHA-1 1024 15 > 106.611 ±2.292 ops/ms > MessageDigests.getAndDigest SHA-25616 15 > 961.589 ± 82.052 ops/ms > MessageDigests.getAndDigest SHA-256 1024 15 > 88.646 ±0.194 ops/ms > MessageDigests.getAndDigest SHA-51216 15 > 775.417 ± 56.775 ops/ms > MessageDigests.getAndDigest SHA-512 1024 15 > 112.904 ±2.014 ops/ms > > GC > MessageDigests.getAndDigest:·gc.alloc.rate.norm MD516 15 > 232.009 ±
Re: RFR: 8259498: Reduce overhead of MD5 and SHA digests
On Thu, 7 Jan 2021 18:50:05 GMT, Claes Redestad wrote: >> Removing the UUID clone cache and running the microbenchmark along with the >> changes in #1933: >> >> Benchmark (size) Mode >> CntScoreError Units >> UUIDBench.fromType3Bytes2 thrpt >> 122.182 ± 0.090 ops/us >> UUIDBench.fromType3Bytes:·gc.alloc.rate 2 thrpt >> 12 439.020 ± 18.241 MB/sec >> UUIDBench.fromType3Bytes:·gc.alloc.rate.norm2 thrpt >> 12 264.022 ± 0.003B/op >> >> The goal now is if to simplify the digest code and compare alternatives. > > I've run various tests and concluded that the `VarHandle`ized code is > matching or improving upon the `Unsafe`-riddled code in `ByteArrayAccess`. I > then went ahead and consolidated to use similar code pattern in > `ByteArrayAccess` for consistency, which amounts to a good cleanup. > > With MD5 intrinsics disabled, I get this baseline: > > Benchmark (size) Mode Cnt >ScoreError Units > UUIDBench.fromType3Bytes2 thrpt 12 >1.245 ± 0.077 ops/us > UUIDBench.fromType3Bytes:·gc.alloc.rate.norm2 thrpt 12 > 488.042 ± 0.004B/op > > With the current patch here (not including #1933): > Benchmark (size) Mode Cnt >ScoreError Units > UUIDBench.fromType3Bytes2 thrpt 12 >1.431 ± 0.106 ops/us > UUIDBench.fromType3Bytes:·gc.alloc.rate.norm2 thrpt 12 > 408.035 ± 0.006B/op > > If I isolate the `ByteArrayAccess` changes I'm getting performance neutral or > slightly better numbers compared to baseline for these tests: > > Benchmark (size) Mode Cnt >ScoreError Units > UUIDBench.fromType3Bytes2 thrpt 12 >1.317 ± 0.092 ops/us > UUIDBench.fromType3Bytes:·gc.alloc.rate.norm2 thrpt 12 > 488.042 ± 0.004B/op Thanks for the performance enhancement, I will take a look. - PR: https://git.openjdk.java.net/jdk/pull/1855
Re: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes [v2]
On Fri, 8 Jan 2021 21:30:14 GMT, Martin Balao wrote: >> As described in JDK-8259319 [1], this fix proposal is to set proper access >> permissions so the SunPKCS11 provider can create instances of SunJCE classes >> when a Security Manager is installed and the fallback scheme is used. >> >> No regressions found in jdk/sun/security/pkcs11 tests category. >> >> -- >> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 > > Martin Balao has updated the pull request incrementally with two additional > commits since the last revision: > > - Limit P11Util::getProvider privileged access to the required > 'accessClassInPackage' RuntimePermission only. > - New line character inserted at the end of IllegalPackageAccess.java test > file Changes look good. - Marked as reviewed by valeriep (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1961
Re: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote:
> As described in JDK-8259319 [1], this fix proposal is to set proper access
> permissions so the SunPKCS11 provider can create instances of SunJCE classes
> when a Security Manager is installed and the fallback scheme is used.
>
> No regressions found in jdk/sun/security/pkcs11 tests category.
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8259319
src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java line 102:
> 100: }
> 101: }
> 102: });
Sean's suggestion is to add additional arguments here, e.g. null, new
RuntimePermission("accessClassInPackage." + ).
-
PR: https://git.openjdk.java.net/jdk/pull/1961
Re: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote: > As described in JDK-8259319 [1], this fix proposal is to set proper access > permissions so the SunPKCS11 provider can create instances of SunJCE classes > when a Security Manager is installed and the fallback scheme is used. > > No regressions found in jdk/sun/security/pkcs11 tests category. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java line 96: > 94: } > 95: > 96: } nit: add a newline here, to get rid of the red icon... - PR: https://git.openjdk.java.net/jdk/pull/1961
Re: RFR: 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes
On Wed, 6 Jan 2021 15:33:59 GMT, Martin Balao wrote: > As described in JDK-8259319 [1], this fix proposal is to set proper access > permissions so the SunPKCS11 provider can create instances of SunJCE classes > when a Security Manager is installed and the fallback scheme is used. > > No regressions found in jdk/sun/security/pkcs11 tests category. > > -- > [1] - https://bugs.openjdk.java.net/browse/JDK-8259319 Obscure bug, thanks for report and the fix. I will take a look. - PR: https://git.openjdk.java.net/jdk/pull/1961
RFR: 8172366: Support SHA-3 based signatures
Could someone please help review this RFE? Enhance default JDK providers except SunPKCS11 with signatures using SHA-3 family of digests. SunPKCS11 provider will be updated separately (JDK-8242332). This changes covers SUN, SunRsaSign, and SunEC providers. Changes are straightforward, just add SHA-3 digests to various signature algorithms. Please review the corresponding CSR as well. It's at: https://bugs.openjdk.java.net/browse/JDK-8252260 Thanks! Valerie - Commit messages: - 8172366: Support SHA-3 based signatures Changes: https://git.openjdk.java.net/jdk/pull/102/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=102=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8172366 Stats: 613 lines in 20 files changed: 541 ins; 8 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/102.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/102/head:pull/102 PR: https://git.openjdk.java.net/jdk/pull/102
Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos
I am also concerned about the changes in GSSLibStub.c about the default
value being GSS_C_AF_UNSPECinstead of GSS_C_AF_NULLADDR (line 194-195).
Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd
prefer to not changing the default value for addresstype for the same
reason which Michael has already stated.
Thanks,
Valerie
On 5/25/2020 8:33 AM, Alexey Bakhtin wrote:
Hello Michael, Thomas,
Thank you a lot for review and suggestions.
I’ve fixed most of the issues except of fundamental one
I need more time to evaluate suggested usage of UnspecEmptyInetAddress subtype.
Updated webrev is available at:
http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/
Also, please see my comments below.
Regards
Alexey
On 24 May 2020, at 02:38, Michael Osipov <1983-01...@gmx.net> wrote:
Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin:
Hello,
Could you please review the following patch:
JBS: https://bugs.openjdk.java.net/browse/JDK-8245527
Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/
Let's go through your changes statically:
* The JIRA issue title has a typo
Thank you. Fixed in Jira
* The word "cannot" is incorrectly spelled throughout all exception messages
Fixed from “can not” to “cannot"
+if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName()))
{
+throw new UnsupportedOperationException("LdapCtx: " +
+TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not
supported");
"LdapCtx: " is redundant because the stacktrace will contain the class
name already. A better message would be: "Channel binding type '%s' is
not supported". Not just the plain value.
Exception message is corrected
+} else if
(cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) {
+if (connectTimeout == -1)
+throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + "
property requires " +
+CONNECT_TIMEOUT + " property is set.");
* Same here with the message
Not sure, What’s wrong with the message ?
* The IAE is wrong because passed value is correct, but leads to an
invalid state because connection timeout is -1. You need an
IllegalStateException here.
Thank you. You are right again. Changed to IllegalStateException
Stupid question: how can one create a GSS security context when the TLS
security context has not been established yet?
This logic already existed here. It could be a reason for it and I don’t want
change it without strong purpose.
The only changes here is to prevent double setting of channel binding data.
---
old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java
2020-05-18 19:39:46.0 +0300
+++
new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java
2020-05-18 19:39:46.0 +0300
@@ -531,9 +531,12 @@
public void setChannelBinding(ChannelBinding channelBindings)
throws GSSException {
-if (mechCtxt == null)
+if (mechCtxt == null) {
+if (this.channelBindings != null) {
+throw new GSSException(GSSException.BAD_BINDINGS);
+}
this.channelBindings = channelBindings;
-
+}
}
I don't understand the purpose of this hunk. Is this safeguard to set
bindings only once?
private static final int CHANNEL_BINDING_AF_INET = 2;
private static final int CHANNEL_BINDING_AF_INET6 = 24;
private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255;
+private static final int CHANNEL_BINDING_AF_UNSPEC = 0;
This should sort from 0 to 255 and not at the end.
OK. Moved to the top.
private int getAddrType(InetAddress addr) {
-int addressType = CHANNEL_BINDING_AF_NULL_ADDR;
+int addressType = CHANNEL_BINDING_AF_UNSPEC;
// initialize addrtype in CB first
- cb->initiator_addrtype = GSS_C_AF_NULLADDR;
- cb->acceptor_addrtype = GSS_C_AF_NULLADDR;
+ cb->initiator_addrtype = GSS_C_AF_UNSPEC;
+ cb->acceptor_addrtype = GSS_C_AF_UNSPEC;
This looks wrong to me -- as you already mentioned -- this violates RFC
2744, section 3.11, last sentence:
or omit addressing information, specifying
GSS_C_AF_NULLADDR as the address-types.
/* release initiator address */
- if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) {
+ if (cb->initiator_addrtype != GSS_C_AF_NULLADDR &&
+ cb->initiator_addrtype != GSS_C_AF_UNSPEC) {
resetGSSBuffer(&(cb->initiator_address));
}
/* release acceptor address */
- if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) {
+ if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR &&
+ cb->acceptor_addrtype != GSS_C_AF_UNSPEC) {
resetGSSBuffer(&(cb->acceptor_address));
}
Unspecified does not mean that it is null.
+final byte[] prefix =
(TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes();
+byte[] cbData =
hg: jdk8/tl/jdk: 2 new changesets
Changeset: d922c8aba2f8 Author:valeriep Date: 2013-12-03 17:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d922c8aba2f8 8029158: sun/security/pkcs11/Signature/TestDSAKeyLength.java does not compile (or run) Summary: Add the missing library path and skip testing against NSS 1.14 or later due to known NSS issue Reviewed-by: vinnie, ascarpino ! test/sun/security/pkcs11/Signature/TestDSAKeyLength.java Changeset: 75165f6c1c50 Author:valeriep Date: 2013-12-03 17:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75165f6c1c50 Merge
hg: jdk8/tl/jdk: 7200306: SunPKCS11 provider delays the check of DSA key size for SHA1withDSA to sign() instead of init()
Changeset: 8d5a9245b9ca Author:valeriep Date: 2013-11-25 11:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d5a9245b9ca 7200306: SunPKCS11 provider delays the check of DSA key size for SHA1withDSA to sign() instead of init() Summary: Add key length checks to P11Signature class Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/Token.java + test/sun/security/pkcs11/Signature/TestDSAKeyLength.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 93826827e8b4 Author:valeriep Date: 2013-11-19 15:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93826827e8b4 8026943: SQE test jce/Global/Cipher/SameBuffer failed Summary: Always use different input/output buffers when calling FeedbackCipher objects Reviewed-by: mullan ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java + test/com/sun/crypto/provider/Cipher/AES/TestCopySafe.java Changeset: 06d155a7c9b0 Author:valeriep Date: 2013-11-21 11:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06d155a7c9b0 Merge
hg: jdk8/tl/jdk: 5 new changesets
Changeset: 1597066b58ee Author:valeriep Date: 2013-10-08 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1597066b58ee 7196382: PKCS11 provider should support 2048-bit DH Summary: Query and enforce range checking using the values from native PKCS11 library. Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java + test/sun/security/pkcs11/KeyPairGenerator/TestDH2048.java Changeset: 3da8be8d13bf Author:valeriep Date: 2013-10-08 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3da8be8d13bf 8012900: CICO ignores AAD in GCM mode Summary: Change GCM decryption to not return result until tag verification passed Reviewed-by: xuelei ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherFeedback.java ! src/share/classes/com/sun/crypto/provider/CounterMode.java ! src/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java ! src/share/classes/com/sun/crypto/provider/GCTR.java ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/OutputFeedback.java ! src/share/classes/com/sun/crypto/provider/PCBC.java ! src/share/classes/javax/crypto/CipherSpi.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCMAndAAD.java Changeset: f4305254f92f Author:valeriep Date: 2013-10-08 11:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f4305254f92f 8014374: Cannot initialize AES/GCM/NoPadding on wrap/unseal on solaris with OracleUcrypto Summary: Removed OracleUcrypto provider regression tests from OpenJDK Reviewed-by: xuelei - test/com/oracle/security/ucrypto/TestAES.java - test/com/oracle/security/ucrypto/TestDigest.java - test/com/oracle/security/ucrypto/TestRSA.java - test/com/oracle/security/ucrypto/UcryptoTest.java Changeset: e044b0151858 Author:valeriep Date: 2013-10-08 14:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e044b0151858 8025967: addition of -Werror broke the old build Summary: Fixed and suppressed compiler warnings on rawtypes Reviewed-by: vinnie ! src/share/classes/com/sun/jndi/ldap/LdapCtxFactory.java ! src/share/classes/com/sun/jndi/ldap/LdapPoolManager.java ! src/share/classes/com/sun/net/ssl/internal/www/protocol/https/HttpsURLConnectionOldImpl.java ! src/share/classes/java/lang/instrument/Instrumentation.java ! src/share/classes/java/net/ContentHandler.java ! src/share/classes/javax/crypto/JceSecurityManager.java ! src/share/classes/sun/instrument/InstrumentationImpl.java ! src/share/classes/sun/net/www/content/image/gif.java ! src/share/classes/sun/net/www/content/image/jpeg.java ! src/share/classes/sun/net/www/content/image/png.java ! src/share/classes/sun/net/www/content/image/x_xbitmap.java ! src/share/classes/sun/net/www/content/image/x_xpixmap.java ! src/share/classes/sun/net/www/protocol/https/HttpsURLConnectionImpl.java ! src/share/classes/sun/reflect/misc/MethodUtil.java ! src/share/classes/sun/security/provider/AuthPolicyFile.java ! src/share/classes/sun/security/provider/SubjectCodeSource.java ! src/share/classes/sun/security/tools/jarsigner/Main.java ! src/share/classes/sun/security/tools/keytool/Main.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java Changeset: 7a7b73a40bb1 Author:valeriep Date: 2013-10-09 13:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7a7b73a40bb1 Merge - src/share/classes/com/sun/jdi/connect/package.html - src/share/classes/com/sun/jdi/connect/spi/package.html - src/share/classes/com/sun/jdi/event/package.html - src/share/classes/com/sun/jdi/package.html - src/share/classes/com/sun/jdi/request/package.html - src/share/classes/com/sun/management/package.html - src/share/classes/com/sun/tools/attach/package.html - src/share/classes/com/sun/tools/attach/spi/package.html - src/share/classes/com/sun/tools/jconsole/package.html
hg: jdk8/tl/jdk: 8020321: Problem in PKCS11 regression test TestRSAKeyLength
Changeset: 162c015c434a Author:valeriep Date: 2013-07-11 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/162c015c434a 8020321: Problem in PKCS11 regression test TestRSAKeyLength Summary: Corrected the isValidKeyLength array Reviewed-by: xuelei ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java
hg: jdk8/tl/jdk: 7 new changesets
Changeset: f225da733291 Author:valeriep Date: 2013-07-05 13:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f225da733291 8012637: Adjust CipherInputStream class to work in AEAD/GCM mode Summary: Ensure the Cipher.doFinal() is called only once Reviewed-by: xuelei ! src/share/classes/javax/crypto/CipherInputStream.java + test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCM.java Changeset: 6e2a5637b286 Author:valeriep Date: 2013-07-05 13:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6e2a5637b286 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful Summary: Check equality based on component values instead of encoding which may vary due to optional components Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/DHKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHPrivateKey.java ! src/share/classes/com/sun/crypto/provider/DHPublicKey.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: f321b78c7009 Author:ascarpino Date: 2013-07-08 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f321b78c7009 6755701: SunJCE DES/DESede SecretKeyFactory.generateSecret throws InvalidKeySpecExc if passed SecretKeySpec Reviewed-by: valeriep, wetmore, xuelei ! src/share/classes/com/sun/crypto/provider/DESKeyFactory.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java + test/com/sun/crypto/provider/Cipher/DES/DESSecretKeySpec.java Changeset: 869bfa39d923 Author:valeriep Date: 2013-07-08 11:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/869bfa39d923 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java Changeset: 4fcac826628c Author:valeriep Date: 2013-07-09 15:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fcac826628c Merge Changeset: 7bd2993e03fa Author:valeriep Date: 2013-07-10 18:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bd2993e03fa 8020310: JDK-6356530 broke the old build Summary: Add serialVersionUID to AuthProvider and P11Key class. Reviewed-by: xuelei ! src/share/classes/java/security/AuthProvider.java ! src/share/classes/sun/security/pkcs11/P11Key.java Changeset: 4c95c032c395 Author:valeriep Date: 2013-07-11 17:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c95c032c395 Merge
hg: jdk8/tl/jdk: 5 new changesets
Changeset: 2ec31660cc0e Author:valeriep Date: 2013-05-07 14:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2ec31660cc0e 8010134: A finalizer in sun.security.pkcs11.wrapper.PKCS11 perhaps should be protected Summary: Change the finalize method of PKCS11 class to be protected. Reviewed-by: xuelei ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java Changeset: 991420add35d Author:valeriep Date: 2013-05-07 14:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/991420add35d 7196009: SunPkcs11 provider fails to parse config path containing parenthesis Summary: Enhanced to allow quoted string as library path values. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java ! test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/cspQuotedPath.cfg Changeset: 804da1e9bd04 Author:ascarpino Date: 2013-05-07 14:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/804da1e9bd04 8001284: Buffer problems with SunPKCS11-Solaris and CKM_AES_CTR Summary: Changed output length calculation to include incomplete blocks for CTR mode. Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java Changeset: fc70416beef3 Author:valeriep Date: 2013-05-13 16:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc70416beef3 Merge - make/com/sun/script/Makefile - make/sun/org/Makefile - make/sun/org/mozilla/Makefile - make/sun/org/mozilla/javascript/Makefile - src/share/classes/com/sun/script/javascript/ExternalScriptable.java - src/share/classes/com/sun/script/javascript/JSAdapter.java - src/share/classes/com/sun/script/javascript/JavaAdapter.java - src/share/classes/com/sun/script/javascript/META-INF/services/javax.script.ScriptEngineFactory - src/share/classes/com/sun/script/javascript/RhinoClassShutter.java - src/share/classes/com/sun/script/javascript/RhinoCompiledScript.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java - src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java - src/share/classes/com/sun/script/javascript/RhinoTopLevel.java - src/share/classes/com/sun/script/javascript/RhinoWrapFactory.java - src/share/classes/com/sun/script/util/BindingsBase.java - src/share/classes/com/sun/script/util/BindingsEntrySet.java - src/share/classes/com/sun/script/util/BindingsImpl.java - src/share/classes/com/sun/script/util/InterfaceImplementor.java - src/share/classes/com/sun/script/util/ScriptEngineFactoryBase.java - src/share/classes/java/beans/ReflectionUtils.java - test/java/awt/Focus/OverrideRedirectWindowActivationTest/OverrideRedirectWindowActivationTest.java - test/sun/security/provider/certpath/X509CertPath/ForwardBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ReverseBuildCompromised.java - test/sun/security/provider/certpath/X509CertPath/ValidateCompromised.java Changeset: 59357ea7f131 Author:valeriep Date: 2013-05-15 18:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/59357ea7f131 Merge - src/share/classes/java/time/format/DateTimeFormatSymbols.java - src/share/classes/sun/nio/cs/ext/META-INF/services/java.nio.charset.spi.CharsetProvider - test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java - test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java
hg: jdk8/tl/jdk: 7155720: PKCS11 minor issues in native code
Changeset: 7d4e30730f80 Author:valeriep Date: 2013-04-04 20:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d4e30730f80 7155720: PKCS11 minor issues in native code Summary: Added OOM handling to address the two issues found by parfait. Reviewed-by: weijun ! src/solaris/native/sun/security/pkcs11/wrapper/p11_md.c
hg: jdk8/tl/jdk: 4 new changesets
Changeset: 46e6a4b7ca26 Author:valeriep Date: 2013-01-07 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e6a4b7ca26 6996769: support AEAD cipher Summary: Added implementation for GCM mode under AES cipher Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherTextStealing.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java + src/share/classes/com/sun/crypto/provider/GCMParameters.java + src/share/classes/com/sun/crypto/provider/GCTR.java + src/share/classes/com/sun/crypto/provider/GHASH.java + src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/spec/GCMParameterSpec.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512524.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512704.java ! test/com/sun/crypto/provider/Cipher/AES/Test4517355.java ! test/com/sun/crypto/provider/Cipher/AES/Test4626070.java + test/com/sun/crypto/provider/Cipher/AES/TestGCMKeyAndIvCheck.java + test/com/sun/crypto/provider/Cipher/AES/TestKATForGCM.java ! test/javax/crypto/Cipher/GCMAPI.java Changeset: 5333a4c8cade Author:valeriep Date: 2013-01-07 14:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5333a4c8cade Merge Changeset: 3c5a62290939 Author:valeriep Date: 2013-01-08 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c5a62290939 8004044: Lazily instantiate SunJCE.RANDOM Summary: Replace the static initialization of SunJCE.RANDOM object w/ lazy initialization Reviewed-by: mchung ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/ISO10126Padding.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBES2Core.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java Changeset: 9b6a29cb04ac Author:valeriep Date: 2013-01-08 13:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b6a29cb04ac Merge
hg: jdk8/tl/jdk: 2 new changesets
Changeset: f0aa997ad78b Author:valeriep Date: 2012-09-25 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0aa997ad78b 7199941: test about AES/ECB mode fails Summary: Fixed the problem of field blockMode not having correct value for AES algorithms. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 4fcbddfd97f0 Author:valeriep Date: 2012-09-25 11:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4fcbddfd97f0 7199939: DSA 576 and 640 bit keys fail when initializing for No precomputed parameters Summary: Fixed initialize(int, SecureRandom) call to not error out when no precomputed params available. Reviewed-by: vinnie ! src/share/classes/sun/security/provider/DSAKeyPairGenerator.java ! src/share/classes/sun/security/provider/DSAParameterGenerator.java ! src/share/classes/sun/security/provider/ParameterCache.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: e129833555f6 Author:valeriep Date: 2012-09-04 18:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e129833555f6 7044060: Need to support NSA Suite B Cryptography algorithms Summary: Add support for DSA parameter generation and OIDs for NSA Suite B algorithms. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/AESWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/java/security/interfaces/DSAKeyPairGenerator.java + src/share/classes/java/security/spec/DSAGenParameterSpec.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/provider/DSA.java ! src/share/classes/sun/security/provider/DSAKeyPairGenerator.java ! src/share/classes/sun/security/provider/DSAParameterGenerator.java ! src/share/classes/sun/security/provider/ParameterCache.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! test/com/sun/crypto/provider/KeyAgreement/TestExponentSize.java + test/sun/security/pkcs11/ec/TestECDH2.java + test/sun/security/pkcs11/ec/TestECDSA2.java + test/sun/security/provider/DSA/TestAlgParameterGenerator.java + test/sun/security/provider/DSA/TestDSA2.java ! test/sun/security/provider/DSA/TestKeyPairGenerator.java Changeset: cc5a6c4d600e Author:valeriep Date: 2012-09-05 10:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc5a6c4d600e Merge
hg: jdk8/tl/jdk: 3 new changesets
Changeset: 114fbbeb8f75 Author:valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/114fbbeb8f75 7107613: scalability bloker in javax.crypto.CryptoPermissions Summary: Changed the type of field perms from Hashtable to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/CryptoPermissions.java Changeset: 175036ada2e3 Author:valeriep Date: 2012-08-10 13:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/175036ada2e3 7107616: scalability bloker in javax.crypto.JceSecurityManager Summary: Changed the type of field exemptCache from HashMap to ConcurrentHashMap. Reviewed-by: weijun, xuelei ! src/share/classes/javax/crypto/JceSecurityManager.java Changeset: 9e97dacbfd35 Author:valeriep Date: 2012-08-10 13:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e97dacbfd35 7185471: Avoid key expansion when AES cipher is re-init w/ the same key Summary: Saved the last cipher key value and skip key expansion if key value is the same. Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/crypto/provider/AESCrypt.java
hg: jdk8/tl/jdk: 7169496: Problem with the SHA-224 support for SunMSCAPI provider
Changeset: af1030be726a Author:valeriep Date: 2012-05-18 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af1030be726a 7169496: Problem with the SHA-224 support for SunMSCAPI provider Summary: Remove SHA224withRSA signature from SunMSCAPI provider due to lack of windows support. Reviewed-by: vinnie ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java
hg: jdk8/tl/jdk: 3 new changesets
Changeset: 3e3017eba8ac Author:valeriep Date: 2012-05-08 17:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e3017eba8ac 4963723: Implement SHA-224 Summary: Add support for SHA-224, SHA224withRSA, SHA224withECDSA, HmacSHA224 and OAEPwithSHA-224AndMGF1Padding. Reviewed-by: vinnie ! src/share/classes/com/sun/crypto/provider/HmacCore.java ! src/share/classes/com/sun/crypto/provider/HmacMD5.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/OAEPParameters.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/java/security/spec/MGF1ParameterSpec.java ! src/share/classes/java/security/spec/PSSParameterSpec.java ! src/share/classes/sun/security/ec/ECDSASignature.java ! src/share/classes/sun/security/ec/SunECEntries.java ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/P11Mac.java ! src/share/classes/sun/security/pkcs11/P11Signature.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! src/share/classes/sun/security/pkcs11/wrapper/Functions.java ! src/share/classes/sun/security/provider/DigestBase.java ! src/share/classes/sun/security/provider/MD2.java ! src/share/classes/sun/security/provider/MD4.java ! src/share/classes/sun/security/provider/MD5.java ! src/share/classes/sun/security/provider/SHA.java ! src/share/classes/sun/security/provider/SHA2.java ! src/share/classes/sun/security/provider/SHA5.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/classes/sun/security/rsa/RSASignature.java ! src/share/classes/sun/security/rsa/SunRsaSignEntries.java ! src/share/classes/sun/security/x509/AlgorithmId.java ! src/windows/classes/sun/security/mscapi/RSASignature.java ! src/windows/classes/sun/security/mscapi/SunMSCAPI.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPParameterSpec.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPWithParams.java ! test/com/sun/crypto/provider/KeyGenerator/Test4628062.java ! test/com/sun/crypto/provider/Mac/MacClone.java ! test/com/sun/crypto/provider/Mac/MacKAT.java ! test/sun/security/mscapi/SignUsingNONEwithRSA.java ! test/sun/security/mscapi/SignUsingSHA2withRSA.java ! test/sun/security/pkcs11/MessageDigest/DigestKAT.java ! test/sun/security/pkcs11/MessageDigest/TestCloning.java ! test/sun/security/pkcs11/Signature/TestRSAKeyLength.java ! test/sun/security/pkcs11/ec/TestCurves.java ! test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java ! test/sun/security/pkcs11/rsa/TestSignatures.java ! test/sun/security/provider/MessageDigest/DigestKAT.java ! test/sun/security/provider/MessageDigest/Offsets.java ! test/sun/security/provider/MessageDigest/TestSHAClone.java ! test/sun/security/rsa/TestKeyPairGenerator.java ! test/sun/security/rsa/TestSignatures.java Changeset: dfce31760a2f Author:valeriep Date: 2012-05-08 18:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfce31760a2f Merge Changeset: 9f8210f23773 Author:valeriep Date: 2012-05-10 11:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f8210f23773 Merge
hg: jdk8/tl/jdk: 7146728: Inconsistent length for the generated secret using DH key agreement impl from SunJCE and PKCS11
Changeset: 4c4d2337dfad Author:valeriep Date: 2012-03-20 15:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c4d2337dfad 7146728: Inconsistent length for the generated secret using DH key agreement impl from SunJCE and PKCS11 Summary: Always return the secret in the same length as the modulus. Reviewed-by: wetmore ! src/share/classes/com/sun/crypto/provider/DHKeyAgreement.java ! src/share/classes/sun/security/pkcs11/P11KeyAgreement.java ! test/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement2.java + test/sun/security/pkcs11/KeyAgreement/TestInterop.java ! test/sun/security/pkcs11/KeyAgreement/TestShort.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: bdbc32b2f920 Author:valeriep Date: 2012-03-15 14:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdbc32b2f920 7130959: Tweak 7058133 fix for JDK 8 (javah makefile changes) Summary: Fixed JAVAHFLAGS setting to use -bootclasspath. Reviewed-by: wetmore ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile Changeset: e48136bb8fdd Author:valeriep Date: 2012-03-15 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e48136bb8fdd Merge
hg: jdk8/tl/jdk: 7136538: typo in test/Makefile under the jdk_security3 target
Changeset: ff24779c147f Author:valeriep Date: 2012-01-27 15:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff24779c147f 7136538: typo in test/Makefile under the jdk_security3 target Summary: Fixed the typo of secrity. Reviewed-by: wetmore ! test/Makefile
hg: jdk8/tl/jdk: 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck.
Changeset: 313da5d059bf Author:valeriep Date: 2012-01-19 12:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/313da5d059bf 7092825: javax.crypto.Cipher.Transform.patternCache is synchronizedMap and became scalability bottleneck. Summary: Changed patternCache from synchronizedMap to ConcurrentHashMap. Reviewed-by: mullan ! src/share/classes/javax/crypto/Cipher.java
hg: jdk8/tl/jdk: 2 new changesets
Changeset: ef3b6736c074 Author:valeriep Date: 2012-01-12 16:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef3b6736c074 7088989: Improve the performance for T4 by utilizing the newly provided crypto APIs Summary: Added the OracleUcrypto provider for utilizing the Solaris ucrypto API. Reviewed-by: weijun ! make/com/oracle/Makefile + make/com/oracle/net/Makefile + make/com/oracle/nio/Makefile + make/com/oracle/security/ucrypto/FILES_c.gmk + make/com/oracle/security/ucrypto/Makefile + make/com/oracle/security/ucrypto/mapfile-vers + make/com/oracle/util/Makefile ! src/share/lib/security/java.security-solaris ! test/Makefile + test/com/oracle/security/ucrypto/TestAES.java + test/com/oracle/security/ucrypto/TestDigest.java + test/com/oracle/security/ucrypto/TestRSA.java + test/com/oracle/security/ucrypto/UcryptoTest.java ! test/java/security/Provider/DefaultPKCS11.java Changeset: a7ad2fcd7291 Author:valeriep Date: 2012-01-12 18:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7ad2fcd7291 Merge
hg: jdk8/tl/jdk: 2 new changesets
Changeset: cdc128128044 Author:valeriep Date: 2012-01-05 18:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdc128128044 6414899: P11Digest should support cloning Summary: Enhanced the PKCS11 Digest implementation to support cloning Reviewed-by: vinnie ! make/sun/security/pkcs11/mapfile-vers ! src/share/classes/sun/security/pkcs11/P11Digest.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/share/lib/security/sunpkcs11-solaris.cfg ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h + test/sun/security/pkcs11/MessageDigest/TestCloning.java Changeset: e6ef778c1df4 Author:valeriep Date: 2012-01-06 11:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6ef778c1df4 Merge
hg: jdk8/tl/jdk: 6839886: Array overrun in pkcs11
Changeset: a9dfdc523c2c Author:valeriep Date: 2011-12-21 14:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a9dfdc523c2c 6839886: Array overrun in pkcs11 Summary: Fix the wrong value when dealing w/ month and day. Reviewed-by: mullan ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c
hg: jdk8/tl/jdk: 2 new changesets
Changeset: e93679cf1e1a Author:valeriep Date: 2011-06-30 18:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e93679cf1e1a 7058133: Javah should use the freshly built classes instead of those from the BOOTDIR jdk Summary: Changed javah to use the newly built classes specified by $(CLASSDESTDIR) Reviewed-by: vinnie ! make/sun/security/ec/Makefile ! make/sun/security/mscapi/Makefile Changeset: f0ec49c21d09 Author:valeriep Date: 2011-07-01 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ec49c21d09 Merge
hg: jdk7/tl/jdk: 7036252: sunpkcs11-solaris.cfg needs a review
Changeset: 40e2b3a25533 Author:valeriep Date: 2011-04-29 13:31 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/40e2b3a25533 7036252: sunpkcs11-solaris.cfg needs a review Summary: Updated the disabled mechanisms section since Solaris bug 6306708 has been fixed. Reviewed-by: mullan ! src/share/lib/security/sunpkcs11-solaris.cfg
hg: jdk7/tl/jdk: 7035115: sun/security/pkcs11/Provider/ConfigShortPath.java compilation failed
Changeset: 131ed7967996 Author:valeriep Date: 2011-04-15 15:56 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/131ed7967996 7035115: sun/security/pkcs11/Provider/ConfigShortPath.java compilation failed Summary: Updated the test to use reflection and skip when SunPKCS11 provider not present. Reviewed-by: weijun ! test/sun/security/pkcs11/Provider/ConfigShortPath.java
hg: jdk7/tl/jdk: 2 new changesets
Changeset: 5d132f3bfbbf Author:valeriep Date: 2011-04-12 15:57 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5d132f3bfbbf 7001094: Can't initialize SunPKCS11 more times than PKCS11 driver maxSessionCount Summary: Changed SessionManager to keep track of session count for each instance Reviewed-by: mullan ! src/share/classes/sun/security/pkcs11/SessionManager.java Changeset: a3de1543568b Author:valeriep Date: 2011-04-12 16:09 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a3de1543568b 6986789: Sun pkcs11 provider fails to parse path name containing + Summary: Modified to accept '+' as valid character. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java ! test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/cspPlus.cfg
hg: jdk7/tl/jdk: 7001933: Deadlock in java.lang.classloader.getPackage()
Changeset: 4a7da412db38 Author:valeriep Date: 2011-03-15 18:42 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a7da412db38 7001933: Deadlock in java.lang.classloader.getPackage() Summary: Modified to not holding the packages lock when calling parent CL. Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/ClassLoader.java
hg: jdk7/tl/jdk: 6994008: PKCS11 should support RSA and RSA/ECB/NoPadding ciphers
Changeset: a52da0bada39 Author:valeriep Date: 2011-03-07 14:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a52da0bada39 6994008: PKCS11 should support RSA and RSA/ECB/NoPadding ciphers Summary: Add support for RSA_X_509 mechanism and aliasing of RSA to RSA/ECB/PKCS1Padding. Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java ! test/sun/security/pkcs11/Cipher/TestRSACipher.java ! test/sun/security/pkcs11/Cipher/TestRSACipherWrap.java + test/sun/security/pkcs11/Cipher/TestRawRSACipher.java
hg: jdk7/tl/jdk: 6604496: Support for CKM_AES_CTR (counter mode)
Changeset: 75216854fb53 Author:valeriep Date: 2011-02-22 12:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75216854fb53 6604496: Support for CKM_AES_CTR (counter mode) Summary: Enhanced SunPKCS11 provider to support AES/CTR/NoPadding transformation. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java + src/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java ! src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c + src/share/native/sun/security/pkcs11/wrapper/pkcs-11v2-20a3.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java
hg: jdk7/tl/jdk: 6581254: pkcs11 provider fails to parse configuration file contains windows short path
Changeset: d4c2d2d72cfc Author:valeriep Date: 2010-12-22 18:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d4c2d2d72cfc 6581254: pkcs11 provider fails to parse configuration file contains windows short path Summary: Modified configuration parsing code to support ~. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java + test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/csp.cfg
hg: jdk7/tl/jdk: 2 new changesets
Changeset: 6deeca9378c0 Author:valeriep Date: 2010-11-19 16:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6deeca9378c0 6203816: Can not run test/java/security/Security/ClassLoaderDeadlock.sh from the command line Summary: Fixed the script to not delete the provider sub-directory Reviewed-by: weijun ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh Changeset: 784f2f094051 Author:valeriep Date: 2010-11-19 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/784f2f094051 6720456: New 4150 may have larger blowfish keysizes Summary: Changed to use TBD value instead of FAIL Reviewed-by: weijun ! test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java
hg: jdk7/tl/jdk: 3 new changesets
Changeset: 86ea594c1d10 Author:valeriep Date: 2010-11-15 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/86ea594c1d10 6848930: JSN security test jce/Global/Cipher/PKCS5Padding cannot thrown expected BadPaddingException Summary: Disabled CKM_DES_CBC_PAD, CKM_DES3_CBC_PAD, CKM_AES_CBC_PAD mechs by default and use our own internal padding impl. Reviewed-by: wetmore ! src/share/lib/security/sunpkcs11-solaris.cfg Changeset: cb10e1177801 Author:valeriep Date: 2010-11-15 14:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb10e1177801 6687725: Internal PKCS5Padding impl should throw IllegalBlockSizeException and not BadPaddingException Summary: Changed to throw IllegalBlockSizeException when the data length isn't multiples of block size Reviewed-by: wetmore ! src/share/classes/sun/security/pkcs11/P11Cipher.java + test/sun/security/pkcs11/Cipher/TestPKCS5PaddingError.java Changeset: 8134c0b75da5 Author:valeriep Date: 2010-11-16 11:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8134c0b75da5 Merge
hg: jdk7/tl/jdk: 2 new changesets
Changeset: 96d78263fdf7 Author:valeriep Date: 2010-10-14 17:59 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/96d78263fdf7 6988081: Use GetPrimitiveArrayCritical instead GetByteArray to Reduce allocation in some sunpkcs jni wrappers Summary: Changed to use GetPrimitiveArrayCritical for encryption and decryption. Reviewed-by: vinnie ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c Changeset: 6b4e02e3be8e Author:valeriep Date: 2010-10-14 18:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6b4e02e3be8e 6850402: Deadlock on sun.security.jca.ProviderConfig starting from jdk7-b55 Summary: Reduced the scope of locking Reviewed-by: vinnie ! src/share/classes/sun/security/jca/Providers.java
hg: jdk7/tl/jdk: 6887853: javadoc for java.lang.Classloader should be more clear
Changeset: 1b430727f00d Author:valeriep Date: 2010-10-12 17:05 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1b430727f00d 6887853: javadoc for java.lang.Classloader should be more clear Summary: Updated the relevant javadoc description of java.lang.ClassLoader class w/ additional clarification. Reviewed-by: mullan ! src/share/classes/java/lang/ClassLoader.java
