> This is a follow up update per comments in [JDK-8287384
> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
> open part looks good to me. Please help to run Mach5 just case the closed
> test cases are impacted.
Xue-Lei Andrew Fan has updated the
On Mon, 13 Jun 2022 22:21:18 GMT, Mandy Chung wrote:
>> test/lib/jdk/test/lib/util/ForceGC.java line 44:
>>
>>> 42: */
>>> 43: public static boolean wait(BooleanSupplier booleanSupplier) {
>>> 44: return wait(booleanSupplier, 1L);
>>
>> For the max waiting time, instead of
On Mon, 13 Jun 2022 22:37:52 GMT, Mandy Chung wrote:
>> Xue-Lei Andrew Fan has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains ten commits:
>>
>> - Merge
>> - Merge master
>> - Merge
>>
ooks good to me. Please help to
> run Mach5 just case the closed test cases are impacted.
Xue-Lei Andrew Fan has updated the pull request incrementally with one
additional commit since the last revision:
remove trailing whitespaces
-
Changes:
- all: https://git.openjdk.org/j
ooks good to me. Please help to
> run Mach5 just case the closed test cases are impacted.
Xue-Lei Andrew Fan has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 13 commits:
- Master
- use Reference.refersTo
- remove trailing whites
On Thu, 16 Jun 2022 16:08:04 GMT, Roger Riggs wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> remove trailing whitespaces
>
> test/jdk/java/io/ObjectStreamClass/TestOSCClassLoa
On Fri, 17 Jun 2022 16:05:38 GMT, Ryan Ernst wrote:
> Applied required casts in jdk.crypto.ec for the upcoming warning.
> Verified by cherry-picking @asotona's patch.
Marked as reviewed by xuelei (Reviewer).
src/jdk.crypto.ec/share/classes/sun/security/ec/XDHPublicKeyImpl.java line 79:
> 77:
On Sat, 18 Jun 2022 05:55:32 GMT, Xue-Lei Andrew Fan wrote:
>> This is a follow up update per comments in [JDK-8287384
>> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
>> open part looks good to me. Please help to run Mach5 just case the closed
On Thu, 30 Jun 2022 15:53:10 GMT, Roger Riggs wrote:
>> Xue-Lei Andrew Fan has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 13 commits:
>>
>> - Master
>> - use Reference.refersTo
>> - r
> This is a follow up update per comments in [JDK-8287384
> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
> open part looks good to me. Please help to run Mach5 just case the closed
> test cases are impacted.
Xue-Lei Andrew Fan has updated the
On Thu, 30 Jun 2022 15:48:07 GMT, Roger Riggs wrote:
>> Xue-Lei Andrew Fan has updated the pull request with a new target base due
>> to a merge or a rebase. The pull request now contains 13 commits:
>>
>> - Master
>> - use Reference.refersTo
>> - r
On Fri, 1 Jul 2022 08:12:59 GMT, Daniel Fuchs wrote:
>> True, knowing when GC is 'done' is not deterministic except for a specify
>> Reference to a specific object.
>> System.gc is just a request, the checking for an object can more quickly
>> exit the loop.
>> The code is as is, and already co
> This is a follow up update per comments in [JDK-8287384
> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
> open part looks good to me. Please help to run Mach5 just case the closed
> test cases are impacted.
Xue-Lei Andrew Fan has updated the pull re
On Thu, 30 Jun 2022 18:44:30 GMT, Xue-Lei Andrew Fan wrote:
>> This is a follow up update per comments in [JDK-8287384
>> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
>> open part looks good to me. Please help to run Mach5 just case the closed
On Fri, 1 Jul 2022 15:28:36 GMT, Roger Riggs wrote:
> > Could someone in Oracle help me run Mach 5 testing?
>
> The CI Passed for Tiers 1-3.
Thanks a lot!
-
PR: https://git.openjdk.org/jdk/pull/8979
On Fri, 1 Jul 2022 14:45:44 GMT, Alan Bateman wrote:
> Does this address JDK-8288286 and allow ReflectionCallerCacheTest.java to be
> removed from ProblemList-Xcomp.txt?
I think JDK-8288286 should be addressed, but I would like to have it further
evaluated via more Mach5 testing before remove
On Wed, 1 Jun 2022 19:08:03 GMT, Xue-Lei Andrew Fan wrote:
> This is a follow up update per comments in [JDK-8287384
> PR](https://github.com/openjdk/jdk/pull/8907). The tier1 and tier2 test in
> open part looks good to me. Please help to run Mach5 just case the closed
> te
On Mon, 18 Jul 2022 15:22:16 GMT, Hollow Man wrote:
> inifinity -> infinity
> nonnce -> nonce
> hasg -> hash
>
> Signed-off-by: Hollow Man
Looks good to me. Thanks!
-
Marked as reviewed by xuelei (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9541
On Thu, 21 Jul 2022 08:53:31 GMT, jquanC wrote:
> There are some doc errors in sun.security.util.DerOutputStream, like the
> followings,
>
>
> /**
> * Private helper routine for writing DER encoded string values.
> * @param s the string to write
> * @param stringTag one of the DER string ta
On Fri, 22 Jul 2022 01:43:06 GMT, jquanC wrote:
> On the second point, I have some doubts. 1) Here don't need to add
> ***@***.*** charset" because it's clear to everyone? ***@***.*** enc" does
> not seem to be used in the method. Shouldn't it be deleted?
Sorry for the confusing.
I think it i
On Fri, 22 Jul 2022 14:56:34 GMT, jquanC wrote:
>> There are some doc errors in sun.security.util.DerOutputStream, like the
>> followings,
>>
>>
>> /**
>> * Private helper routine for writing DER encoded string values.
>> * @param s the string to write
>> * @param stringTag one of the DER s
On Fri, 22 Jul 2022 17:59:51 GMT, Mark Powers wrote:
> https://bugs.openjdk.org/browse/JDK-8290887
Marked as reviewed by xuelei (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9616
On Sat, 23 Jul 2022 05:29:07 GMT, jquanC wrote:
>> There are some doc errors in sun.security.util.DerOutputStream, like the
>> followings,
>>
>>
>> /**
>> * Private helper routine for writing DER encoded string values.
>> * @param s the string to write
>> * @param stringTag one of the DER s
In the SunJSSE implementation, there are a few unexpected extending of static
class SupportedGroups. It may be nice to clean them up so that the code is
easier to read. Please review this simple code clean up.
-
Commit messages:
- 8291949: Unexpected extending of SupportedGroups
This update is to support key exchange named groups customization for
individual (D)TLS connection. Please review the CSR as well:
CSR: https://bugs.openjdk.org/browse/JDK-8291950
RFE: https://bugs.openjdk.org/browse/JDK-8281236
Release-note: https://bugs.openjdk.org/browse/JDK-8291975
This is an
On Sat, 6 Aug 2022 15:12:44 GMT, raspberry-hu wrote:
> remove unused imports
Looks good to me.
-
Marked as reviewed by xuelei (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9792
wse/JDK-8291975
>
> This is an effort similar to [JDK-8280494: "(D)TLS signature
> schemes"](https://bugs.openjdk.org/browse/JDK-8280494)
Xue-Lei Andrew Fan has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the un
> In the SunJSSE implementation, there are a few unexpected extending of static
> class SupportedGroups. It may be nice to clean them up so that the code is
> easier to read. Please review this simple code clean up.
Xue-Lei Andrew Fan has updated the pull request with a new target ba
On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeliński wrote:
> Fix `SSLEngineService` test class to make sure it does not discard any
> network data between `handshaking` and `receive`.
>
> With TLS1.3 the client starts sending application data immediately after
> sending the Finished message. The
On Fri, 5 Aug 2022 12:25:36 GMT, Daniel Jeliński wrote:
> Fix `SSLEngineService` test class to make sure it does not discard any
> network data between `handshaking` and `receive`.
>
> With TLS1.3 the client starts sending application data immediately after
> sending the Finished message. The
On Wed, 10 Aug 2022 16:33:27 GMT, Daniel Jeliński wrote:
> > Could it be a TLS implementation problem that the server should not read
> > application data as handshaking data?
>
> Not really; `SSLEngine#unwrap` does not have to consume the entire
> ByteBuffer, and it's the application's respon
On Fri, 5 Aug 2022 05:23:15 GMT, Xue-Lei Andrew Fan wrote:
> In the SunJSSE implementation, there are a few unexpected extending of static
> class SupportedGroups. It may be nice to clean them up so that the code is
> easier to read. Please review this simple code clean up.
On Wed, 3 Aug 2022 15:40:54 GMT, Weibing Xiao wrote:
> Log the debugging info for server cipher suites when setting javax.net.debug
> == ssl, handshake.
src/java.base/share/classes/sun/security/ssl/ServerHello.java line 409:
> 407: if (shc.sslConfig.preferLocalCipherSuites) {
> 408
On Fri, 19 Aug 2022 15:13:34 GMT, Weijun Wang wrote:
> The two tests are no longer manual and should be removed from the problem
> list.
Marked as reviewed by xuelei (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9943
On Fri, 19 Aug 2022 18:47:40 GMT, Weijun Wang wrote:
> The final version of the CSR at https://bugs.openjdk.org/browse/JDK-8290119
> uses `@implNote` for the new text, but the code change was not updated before
> the integration.
Per the CSR, this is a straightforward update to me.
--
On Fri, 19 Aug 2022 19:01:10 GMT, Weijun Wang wrote:
> Sigh. I removed the test file itself long time ago but forgot to remove a
> line on it in the problem list.
Marked as reviewed by xuelei (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/9951
On Tue, 23 Aug 2022 20:03:19 GMT, Sean Coffey wrote:
>> So, do you want to make the log where the configuration happens? Logging in
>> one place cannot have the accuracy debug log where the problem happens, and
>> cannot easy the analysis of the debug. One just gets the configuration
>> info
On Wed, 24 Aug 2022 20:38:07 GMT, Weibing Xiao wrote:
>> Thanks for the comments. I'm not sure if it is really helpful for
>> developers to understand and debug the failure by reading the additionally
>> dumped cipher suites and/or key exchange configuration. Given the server
>> cipher suite
On Thu, 25 Aug 2022 20:00:45 GMT, Sean Coffey wrote:
>> Even the cipher suites are the same between client and server, it may still
>> fail with "no common in cipher suites" error. The cause of the bug is not
>> only about "no common in cipher suites" between client and server, but also
>> ab
On Thu, 25 Aug 2022 21:03:35 GMT, Xue-Lei Andrew Fan wrote:
>> @XueleiFan - I think it's fair to say that the current "no cipher suites in
>> common" exception message is misleading for some scenarios. If not
>> misleading, it's ambiguous. You could be de
On Thu, 25 Aug 2022 16:00:54 GMT, Rajan Halade wrote:
> This fix adds Certigna root CA to cacerts trust store.
Marked as reviewed by xuelei (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/10030
On Fri, 26 Aug 2022 12:03:33 GMT, Sean Coffey wrote:
> ... on your "preference of client or server suites" data point question
It is not expected to break the connection by changing the preference even
there are multiple key exchange algs. There may be bugs, but did you see
failures caus
On Tue, 9 Aug 2022 15:30:57 GMT, Xue-Lei Andrew Fan wrote:
>> This update is to support key exchange named groups customization for
>> individual (D)TLS connection. Please review the CSR as well:
>> CSR: https://bugs.openjdk.org/browse/JDK-8291950
>> RFE: https://bug
On Tue, 13 Sep 2022 14:58:11 GMT, Sean Coffey wrote:
> Ensure that security properties are only overridden if the override security
> properties file exists.
> Refactored some of the code in Security class initialization also.
> Extra test coverage for security properties file options.
Is it a
Hi,
Please review this simple code cleanup.
The following checking for key in the makeSessionKey() method is redundant as
it the same checking has been performance before calling the method.
if (k == null) {
throw new InvalidKeyException("Empty key");
}
if (
On Tue, 13 Sep 2022 14:58:11 GMT, Sean Coffey wrote:
> Ensure that security properties are only overridden if the override security
> properties file exists.
> Refactored some of the code in Security class initialization also.
> Extra test coverage for security properties file options.
Looks g
InvalidKeyException("Empty key");
> }
> if (!isKeySizeValid(k.length)) {
> throw new InvalidKeyException("Invalid AES key length: " +
>k.length + " bytes");
> }
>
>
> N
On Wed, 14 Sep 2022 13:25:41 GMT, Sean Mullan wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - remove unused throws in comment
>> - remove unused throws
>
> src/ja
InvalidKeyException("Empty key");
> }
> if (!isKeySizeValid(k.length)) {
> throw new InvalidKeyException("Invalid AES key length: " +
>k.length + " bytes");
> }
>
>
> N
On Wed, 14 Sep 2022 17:48:22 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/AESCrypt.java line 605:
>>
>>> 603: */
>>> 604: private void makeSessionKey(byte[] k) throws InvalidKeyException {
>>> 605: int ROUNDS = getRounds(k.length);
>>
On Wed, 14 Sep 2022 18:14:21 GMT, Xue-Lei Andrew Fan wrote:
>> Actually, NM, init still has to call MessageDigest.isEqual so eliminating
>> keys of invalid length before that is probably more efficient.
>
> Good point. Modified to use less checking.
>
> If the ke
On Thu, 15 Sep 2022 05:21:52 GMT, Daniel Jeliński wrote:
>> Speaking of MessageDigest.isEqual, we don't need constant time comparison
>> here. We could use Arrays.equals for some extra performance.
>
> Actually, never mind that. We need constant time comparison to avoid leaking
> information ab
On Wed, 14 Sep 2022 05:58:10 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this simple code cleanup.
>
> The following checking for key in the makeSessionKey() method is redundant as
> it the same checking has been performance before calling the method.
>
>
Hi,
Please review this simple fix for readability.
In the AES cipher implementation, the AESCipher class is defined as abstract.
As is not necessary as there is no abstract method in this class. Code reader
may try to search for abstract methods if the abstract keyword is present.
BTW, I also
Hi,
In the message digest implementation, for example SHA256, in JDK, two bitwise
operations could be improved with equivalent arithmetic, and then the number
bitwise operations could be reduced accordingly. Specifically
"(x and y) xor ((complement x) and z)" could be replaced with the equivale
On Wed, 21 Sep 2022 12:06:31 GMT, Aleksey Shipilev wrote:
>> Hi,
>>
>> In the message digest implementation, for example SHA256, in JDK, two
>> bitwise operations could be improved with equivalent arithmetic, and then
>> the number bitwise operations could be reduced accordingly. Specifically
On Wed, 21 Sep 2022 18:29:08 GMT, Aleksey Shipilev wrote:
> Maybe older X86 and AArch64 are our targets, since it is not guaranteed to
> have SHA hardware intrinsics?
Yes, the platforms that do not support SHA intrinsics are the targets. If I
read the OpenJDK CPU code correctly, RISC-V and AR
Hi,
Please review this performance improvement for Secp256R1 implementation in
OpenJDK. With this update, there is an about 20% performance improvement for
Secp256R1 key generation and signature.
Basically, 256 bits EC curves could use 9 integer limbs for the computation.
The current impleme
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Sat, 24 Sep 2022 08:17:56 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> Please review this performance improvement for Secp256R1 implementation in
>> OpenJDK. With this update, there is an about 20% performance improvement
>> for Secp256R1 key generation and si
On Thu, 22 Sep 2022 20:40:08 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> Please review this performance improvement for Secp256R1 implementation in
> OpenJDK. With this update, there is an about 20% performance improvement for
> Secp256R1 key generation and signature.
>
>
On Wed, 28 Sep 2022 08:12:09 GMT, Ferenc Rakoczi wrote:
>> Hi,
>>
>> In the message digest implementation, for example SHA256, in JDK, two
>> bitwise operations could be improved with equivalent arithmetic, and then
>> the number bitwise operations could be reduced accordingly. Specifically
>
Hi,
May I have this simple code clean-up patch reviewed?
In the AES cipher implementation, the override of engineDoFinal() method in the
following code is not necessary as it only calls super. The throws
descriptions are missed in the method description. I may be better to remove
this overri
On Tue, 4 Oct 2022 17:06:53 GMT, Valerie Peng wrote:
> Thanks for the clean up.
Thank you for the review.
-
PR: https://git.openjdk.org/jdk/pull/10545
Hi,
May I have this patch reviewed?
This is one of a few steps to improve the EC performance. The multiplicative
inverse implementation could be improved for better performance.
For secp256r1 prime p, the current multiplicative inverse impl needs 256
square and 128 multiplication. With the
On Wed, 5 Oct 2022 11:24:57 GMT, Daniel Jeliński wrote:
> This PR removes the implementation of `dispose()` method for AEAD SSLCiphers.
>
> Invocations of
> [readCipher.dispose](https://github.com/openjdk/jdk/blob/4cec141a90bc5d3b8ec17c024291d9c74a112cd4/src/java.base/share/classes/sun/security
Hi,
May I have the code clean up reviewed?
There is a lot of computation in AESCrypt class load, which could be avoid by
using the computation result directly. The computation takes 6.971875
milliseconds in a MacOS M1 laptop. Although it is a one-time computation, but
removing the computation
On Mon, 3 Oct 2022 19:18:20 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this simple code clean-up patch reviewed?
>
> In the AES cipher implementation, the override of engineDoFinal() method in
> the following code is not necessary as it only calls super. The thro
thrpt 15 1437.364 ± 8.291 ops/s
>
>
> It looks like the performance improvement is no significant enough for now.
> But it may be 2+ times more in numbers when the scalar multiplication
> implementation is improved in a follow-up enhancement in another pull request.
>
> En
On Wed, 5 Oct 2022 17:44:39 GMT, Daniel Fuchs wrote:
> I wonder if it would be worthwhile to have a static method that could be
> called in an assert (or in a test using --patch-module) to verify that the
> various statically initialized arrays are the same than those that would have
> been co
On Thu, 6 Oct 2022 16:11:17 GMT, Mark Powers wrote:
> It seems to me the scalar multiplication enhancement should be done first, or
> maybe integrated with this fix. Do you have a bug number for the scalar
> multiplication enhancement?
I did not file the scalar multiplication enhancement in JB
On Thu, 6 Oct 2022 18:33:51 GMT, Xue-Lei Andrew Fan wrote:
>> It seems to me the scalar multiplication enhancement should be done first,
>> or maybe integrated with this fix.
>> Do you have a bug number for the scalar multiplication enhancement?
>
>> It seems to m
oreError Units
> Signatures.sign 64 thrpt 15 1486.764 ± 17.908 ops/s
> Signatures.sign 512 thrpt 15 1494.801 ± 14.072 ops/s
> Signatures.sign 2048 thrpt 15 1500.170 ± 6.998 ops/s
> Signatures.sign 16384 thrpt 15 1
On Thu, 6 Oct 2022 19:35:09 GMT, Daniel Jeliński wrote:
> could you also try using precomputed powers of t between 0-15? similar to
> what we do in
> [ECOperations.multiply](https://github.com/openjdk/jdk/blob/2ae8e3118385bdf93c50bca550334734b69bc2b6/src/jdk.crypto.ec/share/classes/sun/security
Hi,
May I have this update reviewed? With this update, the result will be always
reduced in EC limbs addition and subtraction operations in the JDK
implementation.
In the current implementation, the EC limbs addition and subtraction result is
not reduced before the value is returned. This be
On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed? With this update, the result will be always
> reduced in EC limbs addition and subtraction operations in the JDK
> implementation.
>
> In the current implementation,
On Mon, 10 Oct 2022 16:46:25 GMT, Mark Powers wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computation takes 6.971875
>> milliseconds in a MacOS M1
uted result explicitly. The
> existing regression and inter-op tests should be sufficient to ensure that
> the tables are correctly copied from the dumping of the old computation code
> results.
>
> Except that, I also cleaned up some code warnings from the IDE I used.
>
On Mon, 10 Oct 2022 17:43:52 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have the code clean up reviewed?
>>
>> There is a lot of computation in AESCrypt class load, which could be avoid
>> by using the computation result directly. The computation
On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed? With this update, the result will be always
> reduced in EC limbs addition and subtraction operations in the JDK
> implementation.
>
> In the current implementation,
On Sun, 9 Oct 2022 06:53:19 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed? With this update, the result will be always
> reduced in EC limbs addition and subtraction operations in the JDK
> implementation.
>
> In the current implementation,
On Tue, 11 Oct 2022 00:05:05 GMT, Valerie Peng wrote:
> Mach5 result looks ok. There is one unexpected test failure but it seems
> unrelated
> (https://mach5.us.oracle.com:10060/api/v1/results/vpeng-jdkOh-20221010-1957-37280778-open_test_lib-test-linux-x64-122-1665432715-16/log)
> . So, it sho
On Wed, 5 Oct 2022 05:43:32 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have the code clean up reviewed?
>
> There is a lot of computation in AESCrypt class load, which could be avoid by
> using the computation result directly. The computation takes 6.971875
> milli
On Fri, 7 Oct 2022 21:11:39 GMT, Daniel Jeliński wrote:
> This patch rewrites some BigInteger and curve point operations used in EC
> calculations:
> - coefficient * 2^power is equivalent to coefficient << power
> - number mod 2^n is equivalent to number & (2^n-1)
> - pair of IntegerModuloP oper
On Tue, 11 Oct 2022 18:53:54 GMT, Daniel Jeliński wrote:
>> This patch fixes the issue where a thread doing SSLSocket.close() could
>> destroy the read cipher while it was used by another thread doing
>> SSLSocket.read().
>>
>> The reported issue was triggered by SSLSocket.close() calling
>>
On Wed, 12 Oct 2022 12:31:20 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java
>> line 332:
>>
>>> 330:
>>> 331: protected void setLimbsValuePositive(BigInteger v, long[] limbs) {
>>> 332: assert bitsPerLimb < 32;
>>
>
On Wed, 12 Oct 2022 12:43:09 GMT, Daniel Jeliński wrote:
>> This patch rewrites some BigInteger and curve point operations used in EC
>> calculations:
>> - coefficient * 2^power is equivalent to coefficient << power
>> - number mod 2^n is equivalent to number & (2^n-1)
>> - pair of IntegerModulo
or Units
> KeyPairGenerators.keyPairGen thrpt 15 1367.162 ± 50.322 ops/s
>
>
> with improved limbs (from 10 to 9):
>
> Benchmark Mode Cnt ScoreError Units
> KeyPairGenerators.keyPairGen thrpt 15 1713.097 ± 8.003 ops/s
>
> If con
or Units
> KeyPairGenerators.keyPairGen thrpt 15 1367.162 ± 50.322 ops/s
>
>
> with improved limbs (from 10 to 9):
>
> Benchmark Mode Cnt ScoreError Units
> KeyPairGenerators.keyPairGen thrpt 15 1713.097 ± 8.003 ops/s
>
> If con
0
> ops/s
> Signatures.sign Ed25519 2048 thrpt 15 1144.818 ± 5.768
> ops/s
> Signatures.sign Ed2551916384 thrpt 15 1081.061 ± 8.283
> ops/s
> Signatures.signEd448 64 thrpt 15 321.304 ± 0.638
> ops/s
> S
On Fri, 21 Oct 2022 19:54:57 GMT, Mark Powers wrote:
> https://bugs.openjdk.org/browse/JDK-8293093
There are some other places, for example in updatePkey(), that use cka_id. Did
you have a chance to check if NPE is possible there as well?
-
PR: https://git.openjdk.org/jdk/pull/10
On Tue, 25 Oct 2022 17:49:49 GMT, Mark Powers wrote:
>> Mark Powers has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add getIDNullSafe
>
> Thanks Tony!
@mcpowers Did you want to update line line 203-207 as well? It might be safe
to rem
On Tue, 25 Oct 2022 15:57:56 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8293093
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> add getIDNullSafe
Marked as reviewed by xuelei (Reviewer).
-
On Tue, 25 Oct 2022 17:56:10 GMT, Xue-Lei Andrew Fan wrote:
>> Thanks Tony!
>
> @mcpowers Did you want to update line line 203-207 as well? It might be safe
> to remove the current getID(byte[]) method. If the parameter is null, there
> is an NPE (unexpected); otherwi
On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote:
> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
> to parse or construct any URL.
>
> The `java.net.URL` class does not itself encode or decode any URL components
> according to the escaping mechanism defined in
On Wed, 26 Oct 2022 17:24:59 GMT, Daniel Fuchs wrote:
>> src/java.base/share/classes/java/net/URL.java line 852:
>>
>>> 850: * @since 20
>>> 851: */
>>> 852: public static URL fromURI(URI uri, URLStreamHandler streamHandler)
>>
>> What do you think to have this method in URI inste
On Thu, 27 Oct 2022 14:21:19 GMT, Sean Mullan wrote:
> For timestamp nonces, change the PKCS7 code to use the default SecureRandom
> PRNG (which varies depending on the OS), instead of SHA1PRNG.
Marked as reviewed by xuelei (Reviewer).
-
PR: https://git.openjdk.org/jdk/pull/10883
1 - 100 of 385 matches
Mail list logo
