On Mon, 21 Oct 2024 13:45:47 GMT, Hannes Wallnöfer wrote:
> Please review a doc-only change to fix the order of javadoc `@param` tags in
> module java.base.
>
> We are working on a javadoc feature to add an opt-in doclint warning for
> `@param` tags that don't match the order of parameters in
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
> To fix scalability issue usage of the shared variable was removed. According
> to specjvm2008::crypto.rsa workload one thread performance drop for less than
> 1% while score for the 224 threads increased in ~2 times.
> Numbers for my run on 2 socket server with the Xeon 8480+ looks as:
> 1 thre
On Mon, 21 Oct 2024 13:08:09 GMT, Weijun Wang wrote:
>> Fernando Guallini has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Convert bits to bytes when necessary
>
> Have you timed the differences? I remember we've deliberately used small k
On Thu, 17 Oct 2024 22:20:56 GMT, Vladimir Ivanov wrote:
> To fix scalability issue usage of the shared variable was removed. According
> to specjvm2008::crypto.rsa workload one thread performance drop for less than
> 1% while score for the 224 threads increased in ~2 times.
> Numbers for my ru
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
> https://bugs.openjdk.org/browse/JDK-8336665
Mark Powers has updated the pull request incrementally with one additional
commit since the last revision:
more precise exception message
-
Changes:
- all: https://git.openjdk.org/jdk/pull/20528/files
- new: https://git.openjdk.or
On Fri, 18 Oct 2024 13:50:13 GMT, Sean Mullan wrote:
>> Does the test need to be modified to test for more than one name? I could go
>> either way.
>
> Are you able to easily create test CRLs with more than one entry? If not, I
> think the existing test is ok.
I know how to create a Certificat
On Mon, 21 Oct 2024 13:45:47 GMT, Hannes Wallnöfer wrote:
> Please review a doc-only change to fix the order of javadoc `@param` tags in
> module java.base.
>
> We are working on a javadoc feature to add an opt-in doclint warning for
> `@param` tags that don't match the order of parameters in
On Fri, 18 Oct 2024 13:40:38 GMT, Sean Mullan wrote:
>> Mark Powers has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> allow more than one name
>
> src/java.base/share/classes/sun/security/x509/X509CRLImpl.java line 296:
>
>> 294:
On Sat, 19 Oct 2024 07:54:07 GMT, Alan Bateman wrote:
> There are a couple of micro benchmarks in test/micro that fork with
> `jvmArgsPrepend={"-Djava.security.manager=allow"})`, they will need to be
> examined.
Fixed, will be in next drop. There are a couple of other micro tests that test
th
> Check for unexpected plaintext alert message during TLSv1.3 handshake. This
> can happen if client doesn't receive ServerHello due to network timeout and
> tries to close the connection by sending an alert message.
Artur Barashev has updated the pull request with a new target base due to a
me
> Check for unexpected plaintext alert message during TLSv1.3 handshake. This
> can happen if client doesn't receive ServerHello due to network timeout and
> tries to close the connection by sending an alert message.
Artur Barashev has updated the pull request incrementally with one additional
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
On Wed, 16 Oct 2024 18:47:44 GMT, Matthew Donovan wrote:
> In this PR, I removed hard-coded security providers and replaced them with a
> system property, test.provider.name. If the property is not specified, the
> provider originally used in the test is used:
>
> Cipher c = Cipher.getInstance
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
> Several tests are identified to use weak key parameters (prime modulus,
> private/public values) and certs with weak keys. As these tests purpose is
> not to exercise weak keys, these are updated in this PR to use a modulus with
> 2048-bit, base 2 and certificates with key size 2048
Fernando
On Fri, 18 Oct 2024 19:52:35 GMT, Sean Mullan wrote:
>> I assume for the second one above you mean
>> `javax.security.auth.kerberos.ServicePermission`. These classes still have a
>> lot of words like "grant" and "trust". I will make some changes to the
>> class descriptions of those classes,
> Several tests currently use weak key and salt sizes. Since the purpose of
> these tests is not to evaluate weak keys, they can be updated to use stronger
> keys length (2048-bits) and stronger Salt (16 bytes). This PR does not intend
> to update the tests to use stronger algorithms.
>
> There
On Mon, 21 Oct 2024 12:50:53 GMT, Fernando Guallini
wrote:
>> Several tests currently use weak key and salt sizes. Since the purpose of
>> these tests is not to evaluate weak keys, they can be updated to use
>> stronger keys length (2048-bits) and stronger Salt (16 bytes). This PR does
>> not
> Several tests currently use weak key and salt sizes. Since the purpose of
> these tests is not to evaluate weak keys, they can be updated to use stronger
> keys length (2048-bits) and stronger Salt (16 bytes). This PR does not intend
> to update the tests to use stronger algorithms.
>
> There
> Several tests are identified to use weak key parameters (prime modulus,
> private/public values) and certs with weak keys. As these tests purpose is
> not to exercise weak keys, these are updated in this PR to use a modulus with
> 2048-bit, base 2 and certificates with key size 2048
Fernando
> Several tests currently use weak key and salt sizes. Since the purpose of
> these tests is not to evaluate weak keys, they can be updated to use stronger
> keys length (2048-bits) and stronger Salt (16 bytes). This PR does not intend
> to update the tests to use stronger algorithms.
>
> There
On Wed, 16 Oct 2024 18:47:44 GMT, Matthew Donovan wrote:
> In this PR, I removed hard-coded security providers and replaced them with a
> system property, test.provider.name. If the property is not specified, the
> provider originally used in the test is used:
>
> Cipher c = Cipher.getInstance
> Several tests currently use weak key and salt sizes. Since the purpose of
> these tests is not to evaluate weak keys, they can be updated to use stronger
> keys length (2048-bits) and stronger Salt (16 bytes). This PR does not intend
> to update the tests to use stronger algorithms.
>
> There
Please review a doc-only change to fix the order of javadoc `@param` tags in
module java.base.
We are working on a javadoc feature to add an opt-in doclint warning for
`@param` tags that don't match the order of parameters in the documented
element. The warning will be enabled in OpenJDK builds
On Mon, 21 Oct 2024 13:45:47 GMT, Hannes Wallnöfer wrote:
> Please review a doc-only change to fix the order of javadoc `@param` tags in
> module java.base.
>
> We are working on a javadoc feature to add an opt-in doclint warning for
> `@param` tags that don't match the order of parameters in
On Mon, 21 Oct 2024 17:12:04 GMT, Mark Powers wrote:
>> https://bugs.openjdk.org/browse/JDK-8336665
>
> Mark Powers has updated the pull request incrementally with one additional
> commit since the last revision:
>
> more precise exception message
test/jdk/sun/security/x509/X509CRLImpl/Unexp
On Fri, 18 Oct 2024 20:12:57 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another P
On Mon, 21 Oct 2024 18:10:29 GMT, Valerie Peng wrote:
>> Kevin Driver has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add corresponding negative tests to Exhaustive test for ExtractThenExpand
>
> test/jdk/com/sun/crypto/provider/KDF/HKDF
> Introduce an API for Key Derivation Functions (KDFs), which are cryptographic
> algorithms for deriving additional keys from a secret key and other data. See
> [JEP 478](https://openjdk.org/jeps/478).
>
> Work was begun in [another PR](https://github.com/openjdk/jdk/pull/18924).
Kevin Driver
This patch remove access to the shared variable to fix scalability issue in the
multithread environment. According to testing by the specjvm2008::crypto.rsa
the one thread performance reduced for less than 1% while the score for the
multithread run increased in ~2x. For the 2 socket system with
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals that trigger the
> unuse
On 10/18/24 20:55, Martin Balao wrote:
> Our understanding is that in such an event the Filter would be
> initialized when the ClassLoader does JAR verification. If this is the
> case, programmatically defining a Filter in the signed JAR should not
> work. @Francisco will create a proof-of-concept
> Java implementation of ML-DSA, the FIPS 204 post-quantum signature scheme
> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf. Depends on
> https://github.com/openjdk/jdk/pull/21167
Ben Perez has updated the pull request incrementally with one additional commit
since the last revision:
On Fri, 18 Oct 2024 19:03:30 GMT, Sean Mullan wrote:
>> This is the implementation of JEP 486: Permanently Disable the Security
>> Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
>> [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the
>> main ch
> Please review a doc update to add `@spec` tags to crypto and security APIs in
> `java.base`.
>
> This was authored and proposed as #13336 by @jonathan-gibbons as part of
> [JDK-8296546] back in 2023, but although it was reviewed and approved it
> never was integrated. Since I can't reopen Jo
> In addition to the goals, scope, motivation, specification and requirement
> notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would
> like to describe the most relevant decisions taken during the implementation
> of this enhancement. These notes are organized by feature,
On Tue, 22 Oct 2024 01:40:11 GMT, David Holmes wrote:
> > and whatever team is responsible for HotSpot debugging.
>
> I don't see anything hotspot related here.
>
> I think you would be better off splitting this up into distinct issues and
> PRs for different areas. I expect the client team in
On Mon, 21 Oct 2024 19:52:36 GMT, Anthony Scarpino
wrote:
>> Hi all,
>>
>> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a
>> format for encoding and decoding cryptographic keys and certificates. It
>> will be integrated into JDK24 as a Preview Feature. Preview featur
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> and whatever team is responsible for HotSpot debugging.
I don't see anything hotspot related here.
I think you would be better off splitting this up into distinct issues and PRs
for different areas. I expect the client team in particular
On Mon, 21 Oct 2024 18:18:12 GMT, Vladimir Ivanov wrote:
> This patch remove access to the shared variable to fix scalability issue in
> the multithread environment. According to testing by the
> specjvm2008::crypto.rsa the one thread performance reduced for less than 1%
> while the score for
> Hi all,
>
> I need a code review of the PEM API. Privacy-Enhanced Mail (PEM) is a format
> for encoding and decoding cryptographic keys and certificates. It will be
> integrated into JDK24 as a Preview Feature. Preview features does not
> permanently define the API and it is subject to cha
On Mon, 21 Oct 2024 15:28:47 GMT, Ben Perez wrote:
>> Java implementation of ML-DSA, the FIPS 204 post-quantum signature scheme
>> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf. Depends on
>> https://github.com/openjdk/jdk/pull/21167
>
> Ben Perez has updated the pull request increme
> Java implementation of ML-DSA, the FIPS 204 post-quantum signature scheme
> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf. Depends on
> https://github.com/openjdk/jdk/pull/21167
Ben Perez has updated the pull request incrementally with one additional commit
since the last revision:
On Mon, 21 Oct 2024 18:21:37 GMT, Kevin Driver wrote:
>> Introduce an API for Key Derivation Functions (KDFs), which are
>> cryptographic algorithms for deriving additional keys from a secret key and
>> other data. See [JEP 478](https://openjdk.org/jeps/478).
>>
>> Work was begun in [another P
> In this PR, I removed hard-coded security providers and replaced them with a
> system property, test.provider.name. If the property is not specified, the
> provider originally used in the test is used:
>
> Cipher c = Cipher.getInstance("AES/GCM/NoPadding",
> System.getProperty("test.provider.
On Tue, 15 Oct 2024 18:41:59 GMT, Ben Perez wrote:
>> Java implementation of ML-DSA, the FIPS 204 post-quantum signature scheme
>> https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf. Depends on
>> https://github.com/openjdk/jdk/pull/21167
>
> Ben Perez has updated the pull request increme
On Mon, 21 Oct 2024 18:18:12 GMT, Vladimir Ivanov wrote:
> This patch remove access to the shared variable to fix scalability issue in
> the multithread environment. According to testing by the
> specjvm2008::crypto.rsa the one thread performance reduced for less than 1%
> while the score for
On Mon, 21 Oct 2024 20:07:10 GMT, Sean Mullan wrote:
>> Ben Perez has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Revert "ML-DSA for jarsigner"
>>
>> This reverts commit cc231109513d0f3a939f0bff92a890ff921d94e0.
>
> src/java.base/sh
On Mon, 21 Oct 2024 13:48:21 GMT, Sean Mullan wrote:
>> Ben Perez has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> pack in-place and unpack with an offset
>
> src/java.base/share/classes/sun/security/provider/SunEntries.java line 204:
>
> Using SharedSecrets, I attempted to expose FileInputStream::path information.
> After implementing the fix, I validated the startup performance tests.
> Observed no consistent pattern of performance drops or gains, can disregard
> the occasional performance drop observed in 1 or 2 runs.
Prasa
53 matches
Mail list logo
