On Fri, 29 Jan 2021 20:51:04 GMT, Phil Race wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> same behavior as before -- empty realm map
>
> make/modules/java.security.
> Clean up temporary byte array, char array, and keyspec around keys and
> passwords.
>
> No new regression test.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
drbg
only in patch2:
unchanged:
--
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860
This fix covers both
- [[macOS]: Remove JNF dependency from
libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
- [[macOS]: Remove JNF dependency from
libosxkrb5/SCDynamicStoreConfig.m](https://bugs.openjdk.java.net/browse/JDK-8257860)
-
Commit
On Fri, 18 Dec 2020 19:20:47 GMT, Weijun Wang wrote:
> This fix covers both
>
> - [[macOS]: Remove JNF dependency from
> libosxsecurity/KeystoreImpl.m](https://bugs.openjdk.java.net/browse/JDK-8257858)
> - [[macOS]: Remove JNF dependency from
> libosxkrb5/SCDynamicSt
> Clean up temporary byte array, char array, and keyspec around keys and
> passwords.
>
> No new regression test.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
cleanups for key generations
-
Changes:
On Fri, 22 Jan 2021 21:25:25 GMT, Weijun Wang wrote:
>> New commit. However, I was writing test to detect leak in
>> `RSAPrivateKeySpec` conversion and add more key->spec->key for other
>> algorithms and find more leaks. Will fix in another commit.
>
> Anothe
On Tue, 26 Jan 2021 18:42:02 GMT, Anton Kozlov wrote:
>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>>
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and
>> windows/aarch64.
>>
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of
On Fri, 22 Jan 2021 17:23:12 GMT, Sean Mullan wrote:
> This change enables the XML Signature secure validation mode by default. This
> will improve out of the box security by restricting signatures that contain
> potentially unsafe content by default.
>
> Please also review the CSR:
On Sat, 23 Jan 2021 16:12:43 GMT, Weijun Wang wrote:
>> src/jdk.crypto.ec/share/classes/sun/security/ec/ECPrivateKeyImpl.java line
>> 133:
>>
>>> 131: out.putInteger(1); // version 1
>>> 132: out.putOctetString(sOctets);
>>>
On Sat, 23 Jan 2021 05:09:46 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> keyfactory operations on own keyspec
>
> src/java.base/share/classes/com/sun/crypto/p
On Sat, 23 Jan 2021 03:59:12 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> more wrap, less copy
>
> src/java.base/share/classes/sun/security/pkcs/PKC
On Fri, 22 Jan 2021 15:39:53 GMT, Weijun Wang wrote:
>> Just pushed a new commit. First I merged into the RSA PKCS #1 code change
>> from @valeriepeng, and then reapplied the cleanup to `RSAKeyFactory`. Most
>> new code change is inside `RSAPrivateCrtKeyImpl`. I also
> Clean up temporary byte array, char array, and keyspec around keys and
> passwords.
>
> No new regression test.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
keyfactory operations on own keyspec
-
Chan
On Thu, 21 Jan 2021 16:25:13 GMT, Weijun Wang wrote:
>>> please add noreg label to the JBS bug.
>>
>> Added. Thanks.
>
> Just pushed a new commit. First I merged into the RSA PKCS #1 code change
> from @valeriepeng, and then reapplied the cleanup to `RSAKeyFac
> Clean up temporary byte array, char array, and keyspec around keys and
> passwords.
>
> No new regression test.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
more wrap, less copy
-
Changes:
On Fri, 22 Jan 2021 08:18:15 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - rsa
>> - Merge
>> - 8258915: More temporary buffe
On Fri, 22 Jan 2021 07:44:41 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - rsa
>> - Merge
>> - 8258915: More temporary buffe
On Fri, 22 Jan 2021 07:18:22 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains three commits:
>>
>> - rsa
>> - Merge
>> - 8258915: More temporary buffe
On Thu, 14 Jan 2021 02:52:08 GMT, Weijun Wang wrote:
>> please add noreg label to the JBS bug.
>
>> please add noreg label to the JBS bug.
>
> Added. Thanks.
Just pushed a new commit. First I merged into the RSA PKCS #1 code change from
@valeriepeng, and then
> Clean up temporary byte array, char array, and keyspec around keys and
> passwords.
>
> No new regression test.
Weijun Wang has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains three commits:
- rsa
- Merge
- 8258915: Mo
On Thu, 14 Jan 2021 06:32:37 GMT, Jamil Nimeh wrote:
> This is the security libs portion of the effort to replace
> archaic/non-inclusive words with more neutral terms (see JDK-8253315 for
> details).
>
> Here are the changes covering core libraries code and tests. Terms were
> changed as
On Wed, 13 Jan 2021 22:19:00 GMT, Rajan Halade wrote:
> please add noreg label to the JBS bug.
Added. Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/2070
Clean up temporary byte array, char array, and keyspec around keys and
passwords.
No new regression test.
-
Commit messages:
- 8258915: More temporary buffer cleanup
Changes: https://git.openjdk.java.net/jdk/pull/2070/files
Webrev:
On Fri, 8 Jan 2021 19:08:34 GMT, Weijun Wang wrote:
> More temporary byte array, char array, keyspec cleanup around keys and
> passwords.
>
> No new regression test.
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk16/pull/98
On Wed, 13 Jan 2021 00:54:16 GMT, Valerie Peng wrote:
>> Can someone help review this?
>>
>> This change enhances RSA KeyFactory impl of SunRsaSign and SunPKCS11
>> providers to accept RSA keys in PKCS#1 format and encoding and translate
>> them to provider-specific RSA keys. Updated the
On Wed, 13 Jan 2021 01:21:14 GMT, Hai-May Chao wrote:
>> The jarsigner tool currently provides warning associated with the signer’s
>> cert when it uses weak algorithms, but not for the CA certs. This change is
>> to process the signer’s cert chain to warn if CA certs use weak algorithms.
>
>
On Mon, 11 Jan 2021 17:31:38 GMT, Weijun Wang wrote:
>> Marked as reviewed by xuelei (Reviewer).
>
> I've force pushed a new series of commits from scratch. The difference:
>
> 1. The `s/Portions copyright/Copyright/` change is inside auto import.
> 2. Some `s/Sun Microsy
On Sun, 10 Jan 2021 05:17:23 GMT, Xue-Lei Andrew Fan wrote:
>> Weijun Wang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 13 commits:
>>
>> - No more newInstance calls
>> - Support RSA-PSS with pa
of internal method signature changes.
>
> The "Support RSA-PSS with parameters" commit introduces a new public API and
> would need a CSR.
>
> The last patch is one we just fixed several days ago.
Weijun Wang has updated the pull request with a new target base due to a merge
or a
On Sun, 10 Jan 2021 04:55:38 GMT, Xue-Lei Andrew Fan wrote:
>> Weijun Wang 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.
>
> s
On Sat, 9 Jan 2021 07:22:50 GMT, Xue-Lei Andrew Fan wrote:
> There are a few test paths mentioned in test cases, for example:
> `// Test test/javax/net/ssl/NewAPIs/SSLEngine/LargePacket will check
> `
> The test path is no longer good as test directories were re-orged in the past.
>
>
On Sat, 12 Dec 2020 02:46:45 GMT, Weijun Wang wrote:
> @wangweij This pull request has been inactive for more than 4 weeks and will
> be automatically closed if another 4 weeks passes without any activity. To
> avoid this, simply add a new comment to the pull request. Feel fr
More temporary byte array, char array, keyspec cleanup around keys and
passwords.
No new regression test.
-
Commit messages:
- 8258915: More temporary buffer cleanup
Changes: https://git.openjdk.java.net/jdk16/pull/98/files
Webrev:
On Thu, 7 Jan 2021 18:26:12 GMT, Rajan Halade wrote:
> 8039278: console.sh failed Automatically with exit code 1
Marked as reviewed by weijun (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1981
On Wed, 23 Dec 2020 19:15:48 GMT, Valerie Peng wrote:
> Max, can you help taking a look? This trivial change fixes the inconsistent
> registration properties to match the actual implementation.
>
> In addition to the DH->EC KeyFactory inconsistency, the new test finds
> another MAC->Mac typo.
On Tue, 22 Dec 2020 15:47:05 GMT, Weijun Wang wrote:
> The method is useless now since the related TLS cipher suite was removed long
> ago.
This pull request has now been integrated.
Changeset: 9e463d1a
Author:Weijun Wang
URL: https://git.openjdk.java.net/jdk/commit/9e463d1a
On Tue, 22 Dec 2020 15:47:05 GMT, Weijun Wang wrote:
> The method is useless now since the related TLS cipher suite was removed long
> ago.
> /label remove core-libs
Oops, https://github.com/openjdk/skara/pull/980 filed.
-
PR: https://git.openjdk.java.net/jdk/pull/1865
The method is useless now since the related TLS cipher suite was removed long
ago.
-
Commit messages:
- 8258631: Remove sun.security.jgss.krb5.Krb5Util.getSubject()
Changes: https://git.openjdk.java.net/jdk/pull/1865/files
Webrev:
On Tue, 15 Dec 2020 19:16:22 GMT, Weijun Wang wrote:
> Some array allocation is not necessary, and the content can be cleaned.
This pull request has now been integrated.
Changeset: b97fe6c4
Author: Weijun Wang
URL: https://git.openjdk.java.net/jdk16/commit/b97fe6c4
Stats:
On Tue, 15 Dec 2020 20:31:28 GMT, Valerie Peng wrote:
> Need a noreg-xxx label since there is no regression test.
`noreg-cleanup` Added. Thanks.
-
PR: https://git.openjdk.java.net/jdk16/pull/26
Some array allocation is not necessary, and the content can be cleaned.
-
Commit messages:
- 8258419: RSA cipher buffer cleanup
Changes: https://git.openjdk.java.net/jdk16/pull/26/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk16=26=00
Issue:
On Fri, 13 Nov 2020 22:00:26 GMT, Weijun Wang wrote:
>> This is a multi-commits PR that upgrades xmldsig to be equivalent to
>> Santuario 2.2.0.
>>
>> The first step is an auto-import. The JDK implementation is removed first
>> and Santuario code are impo
On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman wrote:
>> Also, to clarify, for me there is a fundamental difference between
>> `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files
>> that are part of the module, owned by the content team, and the `$MODULE`
>> part is
On Fri, 27 Nov 2020 19:40:35 GMT, Weijun Wang wrote:
> There should only be one curve having type BD or PD in CurveDB.java for any
> given length. Here we keep the last one (sect163r2) so there's no behavior
> change.
>
> I tried to search on the net to see if there is a con
On Mon, 30 Nov 2020 21:07:03 GMT, Valerie Peng wrote:
> > > Based on CurveDB line 141, it seems we uses the first one and discards
> > > the rest? Are you sure we keep the last one?
> > > Don't have answers for your questions though.
> >
> >
> > Before this change both sect163k1 and sect163r2
On Mon, 30 Nov 2020 18:34:40 GMT, Valerie Peng wrote:
> Based on CurveDB line 141, it seems we uses the first one and discards the
> rest? Are you sure we keep the last one?
> Don't have answers for your questions though.
Before this change both sect163k1 and sect163r2 have "BD" so both will
There should only be one curve having type BD or PD in CurveDB.java for any
given length. Here we keep the last one (sect163r2) so there's no behavior
change.
I tried to search on the net to see if there is a consensus on which curve is
meant to be the default one for a size, but cannot find
On Thu, 26 Nov 2020 18:33:15 GMT, Bradford Wetmore wrote:
>> This is to fix some out-of-date information in the javadoc for the SHA1PRNG
>> that has generated a customer bug.
>
> Bradford Wetmore has updated the pull request incrementally with one
> additional commit since the last revision:
>
On Thu, 26 Nov 2020 17:55:06 GMT, Bradford Wetmore wrote:
>> src/java.base/share/classes/sun/security/provider/SecureRandom.java line 78:
>>
>>> 76: *
>>> 77: * The first time this constructor is called in a given Virtual
>>> Machine,
>>> 78: * it may take several seconds of CPU
On Thu, 26 Nov 2020 16:59:11 GMT, Bradford Wetmore wrote:
>> This is to fix some out-of-date information in the javadoc for the SHA1PRNG
>> that has generated a customer bug.
>
> Bradford Wetmore has updated the pull request incrementally with one
> additional commit since the last revision:
>
Is “keystore.pkcs12.*” better? Or, maybe more clear?
See the security properties starting with `keystore.pkcs12` in the
`java.security` file for detailed information.
Thanks,
Max
> On Nov 24, 2020, at 11:23 AM, Sean Mullan wrote:
>
> On 11/17/20 4:38 PM, Weijun Wang wrote:
>
On Mon, 23 Nov 2020 15:08:13 GMT, Sean Mullan wrote:
> This change removes five root certificates with 1024-bit RSA public keys from
> the system-wide `cacerts` keystore. These are older VeriSign and Thawte root
> CA certificates which are no longer necessary to retain and should have
>
On Fri, 20 Nov 2020 20:22:33 GMT, Jamil Nimeh wrote:
>> src/java.base/share/classes/sun/security/ssl/CertificateRequest.java line
>> 139:
>>
>>> 137: if (cct.isAvailable) {
>>> 138: cct.keyAlgorithm.forEach(key -> {
>>> 139: if
On Fri, 20 Nov 2020 18:09:26 GMT, Xue-Lei Andrew Fan wrote:
>> Jamil Nimeh 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 seven additional
>>
On Thu, 19 Nov 2020 17:48:34 GMT, Jamil Nimeh wrote:
>> Hello all,
>> This change brings in support for certificates with EdDSA keys (both Ed25519
>> and Ed448) allowing those signature algorithms to be used both on the
>> certificates themselves and used during the handshaking process for
> This is a micro benchmark for various algorithm settings of PKCS keystores.
> Strong for new algorithms and weak for old ones. Different iteration counts
> are tried. The result should show that the current setting (strong1) is
> more efficient than old setting (weak50000).
On Tue, 17 Nov 2020 21:46:38 GMT, Weijun Wang wrote:
> This is a micro benchmark for various algorithm settings of PKCS keystores.
> Strong for new algorithms and weak for old ones. Different iteration counts
> are tried. The result should show that the current setting (strong1) i
On Thu, 19 Nov 2020 07:58:36 GMT, Aleksey Shipilev wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> not static anymore
>
> test/micro/org/openjdk/bench/java/security/PKCS12KeyStores.
> This is a micro benchmark for various algorithm settings of PKCS keystores.
> Strong for new algorithms and weak for old ones. Different iteration counts
> are tried. The result should show that the current setting (strong1) is
> more efficient than old setting (weak50000).
On Wed, 18 Nov 2020 13:50:14 GMT, Aleksey Shipilev wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> not static anymore
>
> I think the benchmark can be simplified.
New commit.
On Wed, 18 Nov 2020 13:46:04 GMT, Aleksey Shipilev wrote:
>> This is a micro benchmark for various algorithm settings of PKCS keystores.
>> Strong for new algorithms and weak for old ones. Different iteration counts
>> are tried. The result should show that the current setting (strong1) is
On Fri, 13 Nov 2020 21:13:54 GMT, Weijun Wang wrote:
> Without this method, `PSSParameterSpec::toString` shows something like:
> MD: SHA-256
> MGF: java.security.spec.MGF1ParameterSpec@77b52d12
> SaltLength: 32
> TrailerField: 1
> This is ugly.
>
> Noreg-trivial.
This p
This is a micro benchmark for various algorithm settings of PKCS keystores.
Strong for new algorithms and weak for old ones. Different iteration counts are
tried. The result should show that the current setting (strong1) is more
efficient than old setting (weak5).
-
Commit
> On Apr 10, 2020, at 5:03 AM, Weijun Wang wrote:
>
> Please take a review at
>
> CSR : 8228481: Upgrade the default PKCS12 encryption/MAC algorithms
> Release note : https://bugs.openjdk.java.net/browse/JDK-8242069
I forget if the release note has be
On Tue, 17 Nov 2020 19:36:31 GMT, Sean Mullan wrote:
>> New commit and the output will look like:
>> PSSParameterSpec[hashAlgorithm=SHA-256,
>> maskGenAlgorithm=MGF1ParameterSpec[hashAlgorithm=SHA-256], saltLength=32,
>> trailerField=1]
>> I'm using the ASN.1 field names here. (Precisely the
On Mon, 16 Nov 2020 16:30:04 GMT, Sean Mullan wrote:
>> minor comment on spacing for MGF1 toString()
>
>> Do you want me to consolidate `PSSParameterSpec::toString` into one line?
>> Multi-line toString is usually not very friendly to debug output (esp for
>> grep).
>
> Good question.
> Without this method, `PSSParameterSpec::toString` shows something like:
> MD: SHA-256
> MGF: java.security.spec.MGF1ParameterSpec@77b52d12
> SaltLength: 32
> TrailerField: 1
> This is ugly.
>
> Noreg-trivial.
Weijun Wang has updated the pull request incrementally wit
On Mon, 16 Nov 2020 22:04:21 GMT, Sean Mullan wrote:
>> I like the 2nd one better, but I'll see how Sean thinks about the verbose
>> record-style toString.
>
> 99% of the time, it will probably be one of the MGF1ParameterSpec constants.
> For those, perhaps it would be nice to just use the
On Fri, 13 Nov 2020 17:22:10 GMT, Weijun Wang wrote:
> This is a multi-commits PR that upgrades xmldsig to be equivalent to
> Santuario 2.2.0.
>
> The first step is an auto-import. The JDK implementation is removed first and
> Santuario code are imported. Some unrelated files
On Mon, 16 Nov 2020 18:37:13 GMT, Valerie Peng wrote:
>> The current MGF part shows `MGF: MGF1:SHA-256`. An extra space would looks a
>> little strange, and you don't know if the key is `MGF: MGF1` or `MGF`. I'd
>> rather keep the current output.
>
> How about just MGF: MGF1SHA-256 or MGF:
On Mon, 16 Nov 2020 16:19:16 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> make PSSParameterSpec one line
>>
>> only in patch2:
>> unchanged:
>
On Mon, 16 Nov 2020 08:14:00 GMT, Sean Coffey wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> make PSSParameterSpec one line
>>
>> only in patch2:
>> unchanged:
>
> Without this method, `PSSParameterSpec::toString` shows something like:
> MD: SHA-256
> MGF: java.security.spec.MGF1ParameterSpec@77b52d12
> SaltLength: 32
> TrailerField: 1
> This is ugly.
>
> Noreg-trivial.
Weijun Wang has updated the pull request incrementally wit
On Fri, 13 Nov 2020 17:22:10 GMT, Weijun Wang wrote:
> This is a multi-commits PR that upgrades xmldsig to be equivalent to
> Santuario 2.2.0.
>
> The first step is an auto-import. The JDK implementation is removed first and
> Santuario code are imported. Some unrelated files
of internal method signature changes.
>
> The "Support RSA-PSS with parameters" commit introduces a new public API and
> would need a CSR.
>
> The last patch is one we just fixed several days ago.
Weijun Wang has refreshed the contents of this pull request, and previous
commits h
On Fri, 13 Nov 2020 21:13:54 GMT, Weijun Wang wrote:
> Without this method, `PSSParameterSpec::toString` shows something like:
> MD: SHA-256
> MGF: java.security.spec.MGF1ParameterSpec@77b52d12
> SaltLength: 32
> TrailerField: 1
> This is ugly.
>
> Noreg-trivial.
Do yo
Without this method, `PSSParameterSpec::toString` shows something like:
MD: SHA-256
MGF: java.security.spec.MGF1ParameterSpec@77b52d12
SaltLength: 32
TrailerField: 1
This is ugly.
Noreg-trivial.
-
Commit messages:
- 8256363: Define toString() for MGF1ParameterSpec
Changes:
This is a multi-commits PR that upgrades xmldsig to be equivalent to Santuario
2.2.0.
The first step is an auto-import. The JDK implementation is removed first and
Santuario code are imported. Some unrelated files (Ex: encryption) are removed,
and package names are renamed to be internal.
On Tue, 10 Nov 2020 17:14:42 GMT, Weijun Wang wrote:
>> …ineResolveURI().
>>
>> Actual fix looks like this, due to git diff there are lot of changes(
>> mostly because of the spaces) being displayed.
>>
>> --- a/src/share/classes/org/jcp/xml/dsig/interna
On Tue, 10 Nov 2020 11:37:04 GMT, Prajwal Kumaraswamy
wrote:
> …ineResolveURI().
>
> Actual fix looks like this, due to git diff there are lot of changes( mostly
> because of the spaces) being displayed.
>
> --- a/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
> +++
On Tue, 10 Nov 2020 11:37:04 GMT, Prajwal Kumaraswamy
wrote:
> …ineResolveURI().
>
> Actual fix looks like this, due to git diff there are lot of changes( mostly
> because of the spaces) being displayed.
>
> --- a/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java
> +++
On Wed, 4 Nov 2020 20:52:11 GMT, Valerie Peng wrote:
>> Could someone please help review this PKCS#11 v3.0 header files update?
>>
>> Changes are straight-forward as below:
>> 1) Updated pkcs11.h, pkcs11f.h, pkcs11t.h to v3.0
>> 2) Updated java side w/ the new constants definitions and
On Mon, 2 Nov 2020 21:33:31 GMT, Weijun Wang wrote:
>>>
>>>
>>> Just curious, can the Java files be generated during the build process?
>>
>> Hmm, maybe, by the java files, do you just mean PKCS11Constants class or
>> more? I am not familiar wit
On Fri, 30 Oct 2020 21:47:51 GMT, Valerie Peng wrote:
> > Just curious, can the Java files be generated during the build process?
>
> Hmm, maybe, by the java files, do you just mean PKCS11Constants class or
> more? I am not familiar with how to generate Java files during the build
> process,
On Fri, 30 Oct 2020 21:55:10 GMT, Valerie Peng wrote:
> > The constants in PKCS11Exception are duplicated in PKCS11Constants.
> > ```
> > 0x,
> > ```
> >
> >
> > vs
> > ```
> > public static final long CKR_OK = 0xL;
> > ```
> >
> >
> > Is there
On Wed, 28 Oct 2020 21:01:44 GMT, Weijun Wang wrote:
> This is a regression made by
> [JDK-8242068](https://bugs.openjdk.java.net/browse/JDK-8242068). When the
> digest algorithm is not the same as the hash part of the signature algorithm,
> we used to combine the dige
On Thu, 29 Oct 2020 03:18:33 GMT, Weijun Wang wrote:
>> Changes look good. Only minor comments.
>
> Just curious, can the Java files be generated during the build process?
The constants in PKCS11Exception are duplicated in PKCS11Constants.
0x,
vs
public stati
On Wed, 28 Oct 2020 20:56:31 GMT, Weijun Wang wrote:
> I regret adding the `directsign` property/option to JarSigner/jarsigner. See
> the bug for details.
This pull request has now been integrated.
Changeset: a7563207
Author:Weijun Wang
URL: https://git.openjdk.java.net/jdk/
> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
> Please also review the CSR at
> https://bugs.openjdk.java.net/browse/JDK-8228481.
Weijun Wang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev
On Thu, 1 Oct 2020 20:02:34 GMT, Weijun Wang wrote:
> Default algorithms are bumped to be based on PBES2 with AES-256 and SHA-256.
> Please also review the CSR at
> https://bugs.openjdk.java.net/browse/JDK-8228481.
This pull request has now been integrated.
Changeset: f77a65
ithm into a new signature algorithm and use it when generating a
> signature. The previous code change uses the signature algorithm in the
> SignerInfo directly. This bugfix will revert to the old behavior.
Weijun Wang has updated the pull request incrementally with one additional
commit si
On Thu, 29 Oct 2020 02:18:00 GMT, Hai-May Chao wrote:
>> Could someone please help review this PKCS#11 v3.0 header files update?
>>
>> Changes are straight-forward as below:
>> 1) Updated pkcs11.h, pkcs11f.h, pkcs11t.h to v3.0
>> 2) Updated java side w/ the new constants definitions and
This is a regression made by
[JDK-8242068](https://bugs.openjdk.java.net/browse/JDK-8242068). When the
digest algorithm is not the same as the hash part of the signature algorithm,
we used to combine the digest algorithm with the key part of the signature
algorithm into a new signature
I regret adding the `directsign` property/option to JarSigner/jarsigner. See
the bug for details.
-
Commit messages:
- 8255536: Remove the directsign property and option
Changes: https://git.openjdk.java.net/jdk/pull/915/files
Webrev:
On Tue, 27 Oct 2020 17:58:35 GMT, Alexey Bakhtin wrote:
>> Hi All,
>>
>> DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12
>> keystores.
>> This issue prevents the migration of legacy applications to PKCS#12
>> keystore. For example, an application has some old 3DES
On Tue, 27 Oct 2020 17:46:35 GMT, Alexey Bakhtin wrote:
>> Hi All,
>>
>> DES and DESede keys are supported by JKS/JCEKS but not supported by PKCS#12
>> keystores.
>> This issue prevents the migration of legacy applications to PKCS#12
>> keystore. For example, an application has some old 3DES
On Tue, 27 Oct 2020 16:52:03 GMT, Alexey Bakhtin wrote:
>> Yes I can see the OIDs. I was just wondering if other vendors are also using
>> the OID for DES/ECB when storing a DES key. After all, this is only a key
>> and it can can be used with all Cipher modes.
>
> Verified with BC:
On Tue, 27 Oct 2020 14:44:09 GMT, Alexey Bakhtin wrote:
>> src/java.base/share/classes/sun/security/util/KnownOIDs.java line 355:
>>
>>> 353: // OIW secsig 1.3.14.3.*
>>> 354: OIW_DES_CBC("1.3.14.3.2.7", "DES/CBC"),
>>> 355: OIW_DES_ECB("1.3.14.3.2.6", "DES/ECB", "DES"),
>>
>> What
801 - 900 of 2902 matches
Mail list logo
