On Wed, 16 Nov 2022 16:57:14 GMT, Mark Powers wrote:
>> I would like a review of an update to the GCM code. A recent report showed
>> that GCM memory usage for TLS was very large. This was a result of in-place
>> buffers, which TLS uses, and how the code handled the combined intrinsic
>> met
On Wed, 16 Nov 2022 17:38:19 GMT, Mark Powers wrote:
>> I would like a review of an update to the GCM code. A recent report showed
>> that GCM memory usage for TLS was very large. This was a result of in-place
>> buffers, which TLS uses, and how the code handled the combined intrinsic
>> met
> The cache named `signerToCodeSource` in `JarVerifier` is never used now.
pandaapo 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 three additional com
On Fri, 18 Nov 2022 01:52:33 GMT, Weijun Wang wrote:
>> When `X509CRLSelector ` requires a CRL number extension but a CRL does not
>> have it, the CRL should not be selected.
>>
>> Note: the test uses a new internal API introduced in
>> https://github.com/openjdk/jdk/pull/11151.
>
> Weijun Wan
On Thu, 17 Nov 2022 16:23:03 GMT, Weijun Wang wrote:
> If "DSA" and "DH" can be grouped inside a single class, is it also possible
> to group "RSA" and "RSASSA-PSS", and "XDH" and "EdDSA"?
The sub-class name appears in the he benchmark result (See `EC` in
`KeyPairGeneratorBench.EC.generateKeyP
On Thu, 17 Nov 2022 23:07:46 GMT, Johannes Waigel wrote:
> Checking the instance is fundamental to find out the real cause.
Please don't do that in a serious application. The exception stack is belong
to implementation details, and may change any time.
-
PR: https://git.openjdk.o
On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote:
> Please review an update for the troff man pages, following the recent update
> to upgrade to use pandoc 2.19.2
> (See https://bugs.openjdk.org/browse/JDK-8297165)
>
> In conjunction with this, one javadoc test also needs to be updated,
On Tue, 15 Nov 2022 00:35:31 GMT, Weijun Wang wrote:
> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo`
> inside, a new static method `signNew` is introduced to create a newly signed
> certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure
> an
> When `X509CRLSelector ` requires a CRL number extension but a CRL does not
> have it, the CRL should not be selected.
>
> Note: the test uses a new internal API introduced in
> https://github.com/openjdk/jdk/pull/11151.
Weijun Wang has updated the pull request incrementally with one additiona
On Fri, 18 Nov 2022 01:43:00 GMT, Weijun Wang wrote:
>> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo`
>> inside, a new static method `signNew` is introduced to create a newly signed
>> certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure
>
> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo`
> inside, a new static method `signNew` is introduced to create a newly signed
> certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure
> an `X509CertImpl` is always signed and there is no read t
On Wed, 16 Nov 2022 13:21:49 GMT, Weijun Wang wrote:
>> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo`
>> inside, a new static method `signNew` is introduced to create a newly signed
>> certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure
>
On Thu, 17 Nov 2022 21:20:05 GMT, Sean Mullan wrote:
> Wondering why you named the methods "signNew" instead of just "sign" which
> seems simpler to me.
> Otherwise looks fine.
I just want to emphasize that a new object is created. If we can use "new" as a
verb, maybe "newSigned" is better. I
> Inside JDK we support a lot of X.509 certificate extensions. Almost every
> extension has a rule about what is legal or not. For example, the names in
> `SubjectAlternativeNameExtension` cannot be missing or empty. Usually, a rule
> is enforced in the `encode()` method, where the extension val
On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel wrote:
> The `PCSCException` is thrown, but the error type is not visible due to the
> "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception
> type explicitly in the catch.
Exactly what wangwe
Please review an update for the troff man pages, following the recent update to
upgrade to use pandoc 2.19.2
(See https://bugs.openjdk.org/browse/JDK-8297165)
In conjunction with this, one javadoc test also needs to be updated, to work
with the new form of output generated by the new version of
On Thu, 17 Nov 2022 15:57:40 GMT, Weijun Wang wrote:
>> Inside JDK we support a lot of X.509 certificate extensions. Almost every
>> extension has a rule about what is legal or not. For example, the names in
>> `SubjectAlternativeNameExtension` cannot be missing or empty. Usually, a
>> rule is
> Inside JDK we support a lot of X.509 certificate extensions. Almost every
> extension has a rule about what is legal or not. For example, the names in
> `SubjectAlternativeNameExtension` cannot be missing or empty. Usually, a rule
> is enforced in the `encode()` method, where the extension val
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is the
>> singleton Rand
On Wed, 16 Nov 2022 13:21:49 GMT, Weijun Wang wrote:
>> Instead if creating an "unsigned" `X509CertImpl` with only an `X509CertInfo`
>> inside, a new static method `signNew` is introduced to create a newly signed
>> certificate from an `X509CertInfo` object and a `PrivateKey`. Thus make sure
>
On Wed, 16 Nov 2022 21:12:09 GMT, Bernd wrote:
> Would it be easier to remove the state (singleton, thread local) caching
> completely? If somebody request a new instance just seed and return it. That
> might in some situations be even less seeding than once per thread and it
> decreases stat
On Thu, 17 Nov 2022 19:30:14 GMT, Vladimir Ivanov wrote:
>> Volodymyr Paprotski has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> vzeroall, no spill, reg re-map
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_poly.cpp line 377:
>
>> 375: _
> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
> message blocks at a time. For more details, left a lot of comments in
> `macroAssembler_x86_poly.cpp`.
>
> - Added new KAT test for Poly1305 and a fuzz test to compare intrinsic and
> java.
> - Would like to add an `I
On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel wrote:
> The `PCSCException` is thrown, but the error type is not visible due to the
> "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception
> type explicitly in the catch.
Making an exception
On Thu, 17 Nov 2022 19:50:32 GMT, Sean Mullan wrote:
> > Because `JarVerifier#setEagerValidation` will be removed, the field
> > `eagerValidation` will always be false.
> > There are some codes using this field:
> > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/uti
On Mon, 7 Nov 2022 16:54:32 GMT, Andrey Turbanov wrote:
> java.util.Enumeration is a legacy interface from java 1.0.
> There are a few places with cycles which use it to iterate over collections.
> We can replace this manual cycle with enchanced-for, which is shorter and
> easier to read.
This
On Wed, 16 Nov 2022 02:00:23 GMT, Bradford Wetmore wrote:
>> java.util.Enumeration is a legacy interface from java 1.0.
>> There are a few places with cycles which use it to iterate over collections.
>> We can replace this manual cycle with enchanced-for, which is shorter and
>> easier to read.
On Wed, 16 Nov 2022 20:59:24 GMT, Volodymyr Paprotski wrote:
> Any ideas why it is not scaling linearly with number of threads? One would
> think that random numbers are the 'definition' of data-independent and should
> scale linearly with number of CPUs
it could be that the singleton RandomIO
On Wed, 16 Nov 2022 07:41:45 GMT, pandaapo wrote:
> Because `JarVerifier#setEagerValidation` will be removed, the field
> `eagerValidation` will always be false.
>
> There are some codes using this field:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Ja
On Thu, 17 Nov 2022 03:23:49 GMT, Volodymyr Paprotski wrote:
>> Handcrafted x86_64 asm for Poly1305. Main optimization is to process 16
>> message blocks at a time. For more details, left a lot of comments in
>> `macroAssembler_x86_poly.cpp`.
>>
>> - Added new KAT test for Poly1305 and a fuzz
On Mon, 7 Nov 2022 05:55:18 GMT, Johannes Waigel wrote:
> The `PCSCException` is thrown, but the error type is not visible due to the
> "private-packe" access rule.
> By changing the visibility it is possible to handle / access this exception
> type explicitly in the catch.
Can you explain in
On Thu, 17 Nov 2022 18:24:07 GMT, Anthony Scarpino
wrote:
> Looking at this, it's not related to the same in-place issues. This is a
> result of the combined intrinsics requirement . Maybe some better tuning can
> be done, but I think this is unavoidable. I can consider this in a future PR
Th
On Thu, 10 Nov 2022 20:11:46 GMT, Jamil Nimeh wrote:
>> This PR delivers ChaCha20 intrinsics that accelerate the core block function
>> that generates key stream from the key, counter and nonce. Intrinsics have
>> been written for the following platforms and instruction sets:
>>
>> - x86_64:
On Wed, 16 Nov 2022 18:48:58 GMT, Anthony Scarpino
wrote:
> Thanks for looking into this, @ascarpino!
>
> In testing this using a local build, it improves performance in cases using
> heap buffers (a super-set of the socket case), however servers which use
> direct byte-buffers still exhibit
On Thu, 10 Nov 2022 20:11:46 GMT, Jamil Nimeh wrote:
>> This PR delivers ChaCha20 intrinsics that accelerate the core block function
>> that generates key stream from the key, counter and nonce. Intrinsics have
>> been written for the following platforms and instruction sets:
>>
>> - x86_64:
On Sun, 13 Nov 2022 19:58:30 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed?
>
> In the current key pair generation micro-benchmark, there is no cases for
> `EdDSA`, `XDH`, and `RSASSA-PSS`. This PR is trying to add these algorithms.
>
> BTW, here is the benchmarkin
When `X509CRLSelector ` requires a CRL number extension but a CRL does not have
it, the CRL should not be selected.
Note: the test uses a new internal API introduced in
https://github.com/openjdk/jdk/pull/11151.
-
Commit messages:
- the fix and the test
Changes: https://git.openj
> Inside JDK we support a lot of X.509 certificate extensions. Almost every
> extension has a rule about what is legal or not. For example, the names in
> `SubjectAlternativeNameExtension` cannot be missing or empty. Usually, a rule
> is enforced in the `encode()` method, where the extension val
On Mon, 14 Nov 2022 16:37:41 GMT, Xubo Zhang wrote:
>> NativePRNG SecureRandom doesn’t scale with number of threads. The
>> performance starts dropping as we increase the number of threads. Even going
>> from 1 thread to 2 threads shows significant drop. The bottleneck is the
>> singleton Rand
A doc edit to indicate that modifications of values in java.security conf file
would require a JVM restart in order for such changes to be detected.
-
Commit messages:
- 8286575: Document how properties in java.security are parsed
Changes: https://git.openjdk.org/jdk/pull/11208/fil
On Tue, 15 Nov 2022 20:46:43 GMT, Xubo Zhang wrote:
>> Xubo Zhang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/java.base/unix/classes/sun/security/provider/NativePRNG.java
>>
>> Co-authored-by: Andrey Turbanov
>
> Hi
41 matches
Mail list logo
