>
> On 2020-08-28 16:07, Anders Rundgren wrote:
>> On 2020-08-28 15:58, Weijun Wang wrote:
>>> Is “Ed25519” what you need? It’s not available in JDK 11. See
>>> https://bugs.openjdk.java.net/browse/JDK-8199231.
>> I know, that's why I wrote that
Because of some very old incompatibility issue, we put a NULL there for most
algorithms:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/x509/AlgorithmId.java#L176
We are revisiting this decision now at
https://bugs.openjdk.java.net/browse/JDK-8252377. Th
On Mon, 7 Sep 2020 13:48:57 GMT, Sean Coffey wrote:
> Continuation of RFR thread from
> http://mail.openjdk.java.net/pipermail/security-dev/2020-August/022373.html
>
> CSR has been approved.
Marked as reviewed by weijun (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/56
This code change rewrites DerValue into a mostly immutable class and simplifies
DerInputStream as a wrapper for a
series of DerValues objects. DerInputBuffer is removed.
All existing methods of DerValue and DerInputStream should still work with the
exact same behavior, except for a few
places wh
xcept for a few
> places where bugs are fixed. For example, Indefinite length must be used with
> a constructed tag.
> Except for the ObjectIdentifier class where DerInputBuffer is directly
> referenced, no other code is touched.
Weijun Wang has updated the pull request incrementally
On Sun, 20 Sep 2020 14:14:51 GMT, Roger Riggs wrote:
>> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter
>>
>> Debugging functions that utilize ASN.1, DER, and BER encoded streams is
>> difficult without test utilities to show the contents.
>> The ASN.1 formatter reads a s
On Mon, 21 Sep 2020 08:19:28 GMT, Alexey Bakhtin wrote:
> Hi,
>
> Plaese review JDK-8245527 fix which implements LDAP Channel Binding support
> for Java GSS/Kerberos.
> Initial review is available at core-devs:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068197.html
> T
On Tue, 22 Sep 2020 22:21:20 GMT, Hai-May Chao wrote:
> This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the
> parameters field instead of encoding a
> Null tag.
I don't quite understand what the test is for. The bug is about encoding but
the test seems to be decoding t
On Wed, 23 Sep 2020 06:07:09 GMT, Hai-May Chao wrote:
>> I don't quite understand what the test is for. The bug is about encoding but
>> the test seems to be decoding the
>> certificates. Does the test fail before this fix and succeed after it?
>
> This is because the encoding of Algorithm Ident
Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274:
- new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in
jarsigner
- The ".RSA" and ".EC" block extension types (PKCS #7 SignedData inside a
signed JAR) are reused for new signature
algorithms
- A new Ja
On Wed, 23 Sep 2020 23:38:03 GMT, Anthony Scarpino
wrote:
>> This change removes the native elliptic curves library code; as well as, and
>> calls to that code, tests, and files
>> associated with those libraries. The makefiles have been changed to remove
>> from all source builds of the ec c
On Thu, 24 Sep 2020 21:15:34 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/conf/security/java.security line 636:
>>
>>> 634: #
>>> 635: jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage
>>> TLSServer, \
>>> 636: RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224
>>
On Thu, 24 Sep 2020 23:49:08 GMT, Hai-May Chao wrote:
>> This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the
>> parameters field instead of encoding a
>> Null tag.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last re
On Fri, 25 Sep 2020 04:21:04 GMT, Hai-May Chao wrote:
>> This change fixes the DER encoding for ECDSA AlgorithmIdentifier to omit the
>> parameters field instead of encoding a
>> Null tag.
>
> Hai-May Chao has updated the pull request incrementally with one additional
> commit since the last re
On Fri, 18 Sep 2020 21:25:28 GMT, Weijun Wang wrote:
>> This code change rewrites DerValue into a mostly immutable class and
>> simplifies DerInputStream as a wrapper for a
>> series of DerValues objects. DerInputBuffer is removed.
>> All existing methods of DerValue a
On Sat, 19 Sep 2020 00:36:23 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Enhance DerValue::getOctetString to be able to read multi-level
>> constructed value.
&
On Fri, 25 Sep 2020 02:47:59 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/sun/security/util/DerValue.java line 638:
>>
>>> 636: }
>>> 637: if (end == start) {
>>> 638: throw new IOException("No padding");
>>
>> Well, I find the original error message is cl
On Tue, 29 Sep 2020 01:01:12 GMT, Valerie Peng wrote:
>> Yes, this is because `DerValue::getOctetString` allows constructed value but
>> `DerInputStream::getOctetString` only
>> accepts primitive value. This is for compatibility.
>> All other methods will have tag checked inside the correspondin
On Tue, 29 Sep 2020 02:53:10 GMT, Valerie Peng wrote:
>> Yes. In fact I'm not quite confident on our usage of allowBER. In a lot of
>> cases we are actually quite strict. Since
>> this code change is meant to be a refactoring and does not intend to fix
>> many things, I don't intent to make man
On Tue, 29 Sep 2020 03:25:29 GMT, Valerie Peng wrote:
>> Maybe that's what I meant? The positive thing?
>>
>> I'll refactor `getBigIntegerInternal()` so this method will call it.
>
> Existing impl does not make it positive, so I am not sure why you changed it
> here.
I'll keep it signed.
On Tue, 29 Sep 2020 02:46:48 GMT, Valerie Peng wrote:
>> public for compatibility, and final because it won't need to change. I'll
>> see how many `@deprecated` I can add. Or,
>> I'll see if I can move all will-be-deprecated code together.
>
> Yeah, it'd be nice if all will-be-deprecated code ar
On Tue, 29 Sep 2020 03:59:40 GMT, Valerie Peng wrote:
>> I'll look into it. If there's anything wrong, will fix and add a regression
>> test. What if there is zero bit?
>>
>> And yes, the old exception message is better. Don't know why I modified it.
>
> 0-bit BitArray? Maybe no need for this s
On Tue, 29 Sep 2020 14:20:50 GMT, Roger Riggs wrote:
>> Just some comments based on the output example.
>
> Are there any other comments or suggestions?
Can you post an example output of that cert? What about indefinite length? (Ex:
0x24, (byte) 0x80, 4, 2, 'a', 'b', 4,
2, 'c', 'd', 0, 0)
xcept for a few
> places where bugs are fixed. For example, Indefinite length must be used with
> a constructed tag.
> Except for the ObjectIdentifier class where DerInputBuffer is directly
> referenced, no other code is touched.
Weijun Wang has updated the pull request with a new tar
On Sat, 26 Sep 2020 00:57:23 GMT, Weijun Wang wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Enhance DerValue::getOctetString to be able to read multi-level
>> constructed va
On Tue, 29 Sep 2020 17:52:11 GMT, Roger Riggs wrote:
>> # JDK-8252523: Add ASN.1 Formatter to work with test utility HexPrinter
>>
>> Debugging functions that utilize ASN.1, DER, and BER encoded streams is
>> difficult without test utilities to show the contents.
>> The ASN.1 formatter reads a s
Ah, yes. Will fix it soon.
Thanks,
Max
> On Sep 29, 2020, at 7:46 PM, Jade Koskela wrote:
>
> Hi,
>
> New contributor here. I have found a bug in sspi_bridge that requires a small
> change to fix.
> This causes failures to connect with Postgres JDBC using sspi_bridge.
>
> This line in sspi_b
For two principals to be the same, they are either all "user@R", or one is
"user" and the other is "user@R". The check
here wants to fail early if the length are different. "l" is the whole length
and "r" is the length of the name
(without realm). The comparison should be reflective but there is
On Wed, 30 Sep 2020 02:59:40 GMT, Weijun Wang wrote:
> For two principals to be the same, they are either all "user@R", or one is
> "user" and the other is "user@R". The check
> here wants to fail early if the length are different. "l" is the
xcept for a few
> places where bugs are fixed. For example, Indefinite length must be used with
> a constructed tag.
> Except for the ObjectIdentifier class where DerInputBuffer is directly
> referenced, no other code is touched.
Weijun Wang has updated the pull request incrementally
On Thu, 1 Oct 2020 02:24:47 GMT, Valerie Peng wrote:
>> Weijun Wang 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
On Thu, 17 Sep 2020 23:00:54 GMT, Weijun Wang wrote:
> This code change rewrites DerValue into a mostly immutable class and
> simplifies DerInputStream as a wrapper for a
> series of DerValues objects. DerInputBuffer is removed.
> All existing methods of DerValue and DerInputStream
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.
-
Commit messages:
- 8153005: Upgrade the default PKCS12 encryption/MAC algorithms
Changes: https://git.openjdk.java.net/jdk/
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.
TBD: We bumped iteration counts for PBE and HMAC to 5 and 1
On Fri, 2 Oct 2020 18:44:48 GMT, Sean Mullan 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.
>
> test/jdk/sun/security/mscapi/VeryLongAlias.java line 51:
>
>> 49: pub
On Sun, 4 Oct 2020 08:41:28 GMT, Alan Bateman wrote:
>> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274:
>>
>> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in
>> jarsigner
>>
>> - The ".RSA" and ".EC" block extension types (PKCS #7 SignedData in
mKey() and fromSignature() to simplify
> creating Signature and getting its AlgorithmId
>
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all
> old and new signature algorit
mKey() and fromSignature() to simplify
> creating Signature and getting its AlgorithmId
>
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all
> old and new signature algorit
On Sun, 4 Oct 2020 08:41:40 GMT, Alan Bateman 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.
>
> Changes requ
mKey() and fromSignature() to simplify
> creating Signature and getting its AlgorithmId
>
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all
> old and new signature algorithms
On Tue, 6 Oct 2020 18:34:34 GMT, Sean Mullan wrote:
>> I only know Windows Server 2019 can accept the new algorithms.
>
> Ok, but maybe we can split this test in two and use the jtreg @requires tag
> to run the newer algorithms on Windows
> Server 2019? It would be a useful test if this is the o
On Wed, 7 Oct 2020 22:06:28 GMT, Hai-May Chao 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.
>
> test/jdk/sun/security/mscapi/VeryLongAlias.java line 48:
>
>> 46:
>> 47:
On Wed, 7 Oct 2020 22:20:07 GMT, Hai-May Chao wrote:
>> Looks good. Only minor comments.
>
> CSR looks good. In "Sepcification" section: a typo in 'Thr iteration counts
> used by'. At the end, it describes the new
> system property will override the security properties and use the older and
> w
> 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 incrementally with one additional
commit since the last revision:
change ic
On Wed, 7 Oct 2020 22:49:09 GMT, Weijun Wang wrote:
>> CSR looks good. In "Sepcification" section: a typo in 'Thr iteration counts
>> used by'. At the end, it describes the new
>> system property will override the security properties and use the older an
On Thu, 8 Oct 2020 16:34:59 GMT, Sean Mullan wrote:
>> New commit updating ic to 1. I also created separate constants for
>> DEFAULT_CERT_PBE_ITERATION_COUNT and
>> DEFAULT_KEY_PBE_ITERATION_COUNT. I haven't made the change for
>> LEGACY_PBE_ITERATION_COUNT since they will never change.
>
>
On Fri, 9 Oct 2020 00:04:17 GMT, Weijun Wang wrote:
>> Are you still planning, or is it possible to add a test for Windows 2019?
>> Also, have you considered adding a test that
>> checks if the JDK can read OpenSSL PKCS#12 files and vice versa? Maybe we
>> can do t
> 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 incrementally with one additional
commit since the last revision:
update R
On Fri, 9 Oct 2020 00:07:39 GMT, Weijun Wang wrote:
>> I tried but cannot find a way to tell if a system is Windows Server 2016 or
>> 2019. Their os.version is all 10.0. I've
>> filed an enhancement at https://bugs.openjdk.java.net/browse/JDK-8254241 for
>> it. Tha
mKey() and fromSignature() to simplify
> creating Signature and getting its AlgorithmId
>
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all
> old and new signature algorithms
On Tue, 13 Oct 2020 13:24:50 GMT, Weijun Wang wrote:
>> Note: I force pushed a new commit to correct a typo in the summary line.
>
> Add support for [RFC 6211: Cryptographic Message Syntax (CMS) Algorithm
> Identifier Protection
> Attribute](https://tools.ietf.org/html/r
mKey() and fromSignature() to simplify
> creating Signature and getting its AlgorithmId
>
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all
> old and new signature algorit
On Sun, 4 Oct 2020 14:09:26 GMT, Weijun Wang wrote:
>> Changes requested by alanb (Reviewer).
>
> Note: I force pushed a new commit to correct a typo in the summary line.
Add support for [RFC 6211: Cryptographic Message Syntax (CMS) Algorithm
Identifier Protection
Attr
mKey() and fromSignature() to simplify
> creating Signature and getting its AlgorithmId
>
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all
> old and new signature algorithms
On Thu, 15 Oct 2020 18:15:35 GMT, Vicente Romero wrote:
> this one has nothing to do with javac so the `compiler` label should be
> removed
@vicente-romero-oracle Sorry for the noise, I should have removed it earlier.
All files in the `jdk.jartool` module are
under `compiler` in
https://githu
On Tue, 13 Oct 2020 23:50:05 GMT, Valerie Peng 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.
>
> src/jav
On Wed, 14 Oct 2020 00:00:38 GMT, Valerie Peng 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.
>
> src/jav
On Wed, 14 Oct 2020 04:03:46 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> signing time, jarsigner -directsign, and digest algorithm check
>
> src/java.base/s
On Wed, 14 Oct 2020 05:31:33 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> signing time, jarsigner -directsign, and digest algorithm check
>
> src/java.base/s
On Wed, 14 Oct 2020 19:18:04 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> signing time, jarsigner -directsign, and digest algorithm check
>
> src/java.base/share/c
On Thu, 15 Oct 2020 02:03:13 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> signing time, jarsigner -directsign, and digest algorithm check
>
> src/java.base/share/c
On Thu, 15 Oct 2020 20:42:30 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> signing time, jarsigner -directsign, and digest algorithm check
>
> src/java.base/s
On Fri, 16 Oct 2020 01:40:48 GMT, Valerie Peng 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.
>
> test/jd
On Fri, 16 Oct 2020 02:15:08 GMT, Valerie Peng wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> signing time, jarsigner -directsign, and digest algorithm check
>
> test/lib/j
On Fri, 16 Oct 2020 02:34:35 GMT, Weijun Wang wrote:
>> src/java.base/share/classes/sun/security/pkcs/SignerInfo.java line 549:
>>
>>> 547: return encAlg;
>>> 548: default:
>>> 549: String digAlg = digAlgId.getN
mKey() and fromSignature() to simplify
> creating Signature and getting its AlgorithmId
>
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all
> old and new signature algorithms
mKey() and fromSignature() to simplify
> creating Signature and getting its AlgorithmId
>
> - Use the new methods in PKCS10, X509CertImpl, and X509CRLImpl signing
>
> - Add a new (and intuitive, IMHO) PKCS7::generateNewSignedData capable of all
> old and new signature algorithms
On Wed, 23 Sep 2020 14:41:59 GMT, Weijun Wang wrote:
> Major points in CSR at https://bugs.openjdk.java.net/browse/JDK-8245274:
>
> - new sigalg "RSASSA-PSS", "EdDSA", "Ed25519" and "Ed448" can be used in
> jarsigner
>
> - The ".
The test calls Field::setAccessible and needs an "open" access to the internal
class.
-
Commit messages:
- 8255393: sun/security/util/DerValue/Indefinite.java fails with
---illegal-access=deny
Changes: https://git.openjdk.java.net/jdk/pull/864/files
Webrev: https://webrevs.openjd
> The test calls Field::setAccessible and needs an "open" access to the
> internal class.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
no new bug id with ---illegal-access=deny
-
Changes
On Mon, 26 Oct 2020 14:07:36 GMT, Weijun Wang wrote:
> The test calls Field::setAccessible and needs an "open" access to the
> internal class.
This pull request has now been integrated.
Changeset: e8b75b13
Author:Weijun Wang
URL: https://git.openjdk.java.net/jdk
On Tue, 27 Oct 2020 12:27:52 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 keys th
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
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: BouncyCastl
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 k
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 k
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: https://webrevs.openjdk.java.net/?repo=jdk&pr=
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 algorith
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 name/err
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, 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
> 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 exc
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/
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 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 digest algori
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 any
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, c
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 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 name/erro
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
> +++ b/src/
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
> +++ b/src/
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
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. There
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: https://
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
l 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 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
> 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 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:
>
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:
>
701 - 800 of 1811 matches
Mail list logo
