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
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
> 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
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:
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 ".
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 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
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 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 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 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 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 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 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 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 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 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
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 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 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 algorithms
>
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. That
> 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:
upda
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 d
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 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 and
>>
> 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: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
>
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:
>>
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
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 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
&
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 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
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:
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
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:
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
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
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 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
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
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
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
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
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
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)
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
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
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: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
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
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
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 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
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
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 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
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
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
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
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
>
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
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
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
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
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.
>
> 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 I cur
ote:
>
>
> On 28/08/2020 16:18, Weijun Wang wrote:
>> 1. Add a comment on how to generate ZIPBYTES in the test. Not the byte[]
>> declaration but how the original ZIP file is generated.
> I'll add a comment block to the test:
>> /*
>> * Created u
e added.
>
> http://cr.openjdk.java.net/~coffeys/webrev.8250968.v4/webrev/
>
> regards,
> Sean.
>
> On 27/08/2020 15:58, Weijun Wang wrote:
>>> Looks like it was a conscious design decision to only allow recording of
>>> POSIX permission bits for this field (& 0xFFF).
Is “Ed25519” what you need? It’s not available in JDK 11. See
https://bugs.openjdk.java.net/browse/JDK-8199231.
—Max
> On Aug 28, 2020, at 9:55 AM, Anders Rundgren
> wrote:
>
> On 2020-08-28 15:41, Weijun Wang wrote:
>> What version of java are you using and what’s your c
What version of java are you using and what’s your command to generate the key
pair?
Thanks,
Max
> On Aug 28, 2020, at 7:03 AM, Anders Rundgren
> wrote:
>
> Hi Crypto Experts,
>
> Please pardon my ignorance regarding curve25519, but I ran into problems [*]
> trying to recreate the sample
> On Aug 27, 2020, at 10:36 AM, Seán Coffey wrote:
>
> Thanks for the review Max. Comments inline..
>
> On 27/08/2020 14:45, Weijun Wang wrote:
>> I’m OK with using one warning, but prefer it to a little more formal like
>> "POSIX file permission an
ymlink
>> attributes detected. These attributes are ignored when signing and are not
>> protected by the signature."},
>>
>> regards,
>> Sean.
>>
>> On 26/08/2020 23:15, Weijun Wang wrote:
>>> Are you going to update the warning text or cr
Are you going to update the warning text or create a new one?
Thanks,
Max
> On Aug 26, 2020, at 2:26 PM, Seán Coffey wrote:
>
> This is a follow on from the recent 8218021 fix. The jarsigner tool removes
> symlink attribute data from zipfiles when signing them. jarsigner should
> preserve
Hi Bernd,
We've found out the problem inside JDK. There is a place where it takes for
granted that a trusted chain can be built and then uses the output directly
without checking for null. We'll most likely throw a SignatureException instead.
Is it still the same reason that the TSA server
Looks fine to me. Thanks for the quick fix.
—Max
> 在 2020年7月25日，12:36，Martin Balao 写道：
>
> Hello Max,
>
> I'd like to propose a patch for "8250582: Revert Principal Name type to
> NT-UNKNOWN when requesting TGS Kerberos tickets" [1].
>
> Webrev.00:
>
> *
nks,
Max
> On Jul 24, 2020, at 4:25 PM, Hai-May Chao wrote:
>
>
>
>> On Jul 15, 2020, at 12:16 AM, Weijun Wang wrote:
>>
>> The following lines are useless now:
>>
>
> Ok, this is a separate problem from the original bug to be addressed.
>
errors
}
}
Thanks,
Max
> On Jul 15, 2020, at 3:16 PM, Weijun Wang wrote:
>
> The following lines are useless now:
>
> 1053 if (badKeyUsage || badExtendedKeyUsage || badNetscapeCertType ||
> 1054 notYetValidCert || chainNotValidated || has
The following lines are useless now:
1053 if (badKeyUsage || badExtendedKeyUsage || badNetscapeCertType ||
1054 notYetValidCert || chainNotValidated || hasExpiredCert ||
1055 hasUnsignedEntry || signerSelfSigned || (legacyAlg != 0) ||
1056
) updated on the new JarSigner property at
https://bugs.openjdk.java.net/browse/JDK-8245274
Thanks,
Max
> On Jun 2, 2020, at 4:07 PM, Weijun Wang wrote:
>
> Updated again at
>
> https://cr.openjdk.java.net/~weijun/8242068/webrev.02
>
> Major changes this time:
>
> 1.
+1
Thanks,
Max
> On Jul 8, 2020, at 8:56 AM, Hai-May Chao wrote:
>
> Hi Tony,
>
> Looks good.
>
> Hai-May
>
>
>> On Jul 7, 2020, at 5:01 PM, Anthony Scarpino
>> wrote:
>>
>> Hi,
>>
>> I need a code review to fix some copyright headers. The diffs are below
>>
>> thanks
>>
>> Tony
>>
ervice(...) and
> check for ==. If there were another way to check service registration, then
> it makes sense to store Service object.
>
> Valerie
>
> On 7/7/2020 3:44 AM, Weijun Wang wrote:
>>> On Jul 7, 2020, at 12:33 AM, Valerie Peng wrote:
>>>
>&
in the map, and maybe later you can detect whether that Service is registered
and decide if you can simply return it or a create a new one by calling
getService().
Thanks,
Max
>
> Thanks,
> Valerie
> On 7/2/2020 9:05 PM, Weijun Wang wrote:
>> Hi Valerie,
>>
>> How abo
> On Jul 3, 2020, at 7:32 PM, Alexey Bakhtin wrote:
>
> Hello All,
>
> Thank you for review.
>
>> 1. If the change in java.security.jgss/share/classes/module-info.java is
>> unavoidable, can we create a sub-package for this single class so that we
>> only need to export it?
>
> As
The GSS and SASL changes look fine to me.
Two small questions:
1. If the change in java.security.jgss/share/classes/module-info.java is
unavoidable, can we create a sub-package for this single class so that we only
need to export it? Or, do you think we can define the sub-class inside
Hi Valerie,
How about the suggested fix from the bug reporter?
Thanks,
Max
> On Jul 3, 2020, at 4:52 AM, Valerie Peng wrote:
>
> Hi Max and Sean,
>
> Can you help reviewing this fix for JDK-8248505? This is the followup fix for
> JDK-8246613 "Choose the default SecureRandom algo based on
playground at
https://github.com/openjdk/playground/pull/9, but formal code review should
stay in this mail thread.
> On Apr 30, 2020, at 9:50 PM, Weijun Wang wrote:
>
> Webrev updated at
>
> http://cr.openjdk.java.net/~weijun/8243592/webrev.02/
>
> I removed my ol
-
src/java.base/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
@@ -248,7 +248,7 @@ private static X509CRL getCRL(URIName name) throws
CertStoreException {
debug.println("Trying to fetch CRL from DP " + uri);
}
Hi Siba,
Change looks fine to me.
Thanks,
Max
> On Jun 25, 2020, at 5:11 PM, sibabrata.sa...@oracle.com wrote:
>
> Hi,
>
> Please review a minor fix for the following patch,
> JBS: https://bugs.openjdk.java.net/browse/JDK-8247968
> Diff:
>
> diff -r 5f90d52615de
>
s for
>> looking this over, Max!
>>
>> --Jamil
>>
>> On 6/22/2020 12:42 AM, Weijun Wang wrote:
>>> Source change looks fine to me.
>>>
>>> One small suggestion: Is it possible to encode the bytes in the test as HEX
>>> instead of
Source change looks fine to me.
One small suggestion: Is it possible to encode the bytes in the test as HEX
instead of BASE64? If so, I can use my human eyes to look at the content.
HexPrinter in test/lib can be used to generate them and Utils.toByteArray can
be used to translate them back to
The 3 newly added log0() methods in com/sun/org/slf4j/internal/Logger.java are
declared public. This is a stupid typo. In fact, in the comment at the
beginning of that class [1] I specifically pointed out they are private.
Here is the patch. Noreg-trivial.
diff --git
Please take a review at
http://cr.openjdk.java.net/~weijun/8247907/webrev.00/
I also take this chance to get the class and method names correct in the log.
Thanks,
Max
; is just one-line.
>>
>> Will proceed with integration once the mach5 tests finish.
>>
>> Thanks!
>> Valerie
>> On 6/14/2020 2:21 AM, Weijun Wang wrote:
>>> Looks fine to me. Maybe you can also use "if (this instanceof Cloneable)"
>>> in
> sufficient to use "md instanceof Cloneable && md is not from PKCS11"?
>>>
>>> Valerie
>>>
>>> On 6/6/2020 9:10 AM, Xuelei Fan wrote:
>>>> As the the Delegate class takes care of the Cloneable SPI implementation,
>>>> it should be sufficie
901 - 1000 of 2902 matches
Mail list logo
