On Tue, 29 Oct 2024 18:36:30 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> apparently can't be before a @implNote.. Who know.
>
> test/jdk/java/security/PEM/PEMCerts.java line 1:
>
>> 1: /*
On Thu, 31 Oct 2024 00:09:19 GMT, Anthony Scarpino
wrote:
>> src/java.base/share/classes/javax/crypto/EncryptedPrivateKeyInfo.java line
>> 339:
>>
>>> 337: * @throws IllegalArgumentException when an argument causes an
>>> 338: * initialization error.
>>> 339: * @throws SecurityE
On Wed, 30 Oct 2024 20:14:58 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> apparently can't be before a @implNote.. Who know.
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKey
On Tue, 29 Oct 2024 19:50:46 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
On Wed, 30 Oct 2024 20:11:46 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> apparently can't be before a @implNote.. Who know.
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKey
On Tue, 29 Oct 2024 18:34:45 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> apparently can't be before a @implNote.. Who know.
>
> src/java.base/share/classes/java/security/PEMDecoder.java li
On Wed, 30 Oct 2024 20:14:04 GMT, Weijun Wang wrote:
>> Anthony Scarpino has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> apparently can't be before a @implNote.. Who know.
>
> src/java.base/share/classes/javax/crypto/EncryptedPrivateKey
On Tue, 29 Oct 2024 15:56:50 GMT, Fernando Guallini
wrote:
>> Several tests are identified to use weak/legacy algorithms. As these tests
>> purpose is not to exercise weak algorithms, these are updated in this PR to
>> use stronger algorithms. If the test uses a weak key, it is updated as well
On Tue, 29 Oct 2024 15:56:50 GMT, Fernando Guallini
wrote:
>> Several tests are identified to use weak/legacy algorithms. As these tests
>> purpose is not to exercise weak algorithms, these are updated in this PR to
>> use stronger algorithms. If the test uses a weak key, it is updated as well
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 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 Wed, 16 Oct 2024 12:34:32 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 intend
On Fri, 25 Oct 2024 21:18:41 GMT, Sean Mullan wrote:
> Comments on `java.security` classes.
>
> Also, I'd like to see some clarifications on what "the installed policy" or
> "the current policy" is. The `ProtectionDomain` mentions this when talking
> about dynamic permissions. On the other han
On Wed, 30 Oct 2024 19:13:20 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
On Wed, 30 Oct 2024 19:13:20 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
On Tue, 29 Oct 2024 19:50:46 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
On Fri, 22 Mar 2024 22:25:47 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
On Tue, 29 Oct 2024 19:50:46 GMT, rebarbora-mckvak wrote:
>> This fixes the defect described at
>> https://bugs.openjdk.org/browse/JDK-8313367
>>
>> If the process does not have write permissions, the store is opened as
>> read-only (instead of failing).
>>
>> Please note that permissions to
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 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 Wed, 30 Oct 2024 19:13:20 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
On Fri, 25 Oct 2024 20:44:25 GMT, Roger Riggs wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 150 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Merge
>> - Update
On Tue, 29 Oct 2024 18:35:05 GMT, Brent Christian wrote:
>> Sean Mullan has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 186 commits:
>>
>> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>> - Update copyrigh
On Mon, 28 Oct 2024 20:12:27 GMT, Roger Riggs wrote:
> Reviewed all tests under test/jaxp/javax/xml/jaxp. A few imports moved around
> unnecessarily but otherwise looks fine.
JAXP test comments fixed in
https://github.com/openjdk/jdk/pull/21498/commits/5577e4884710eba498ee5f40fa85d47eaa07364d
On Tue, 29 Oct 2024 14:19:05 GMT, Weijun Wang wrote:
>> test/jdk/javax/xml/crypto/dsig/ErrorHandlerPermissions.java line 1:
>>
>>> 1: /*
>>
>> @wangweij It looks like this test can be deleted as it was specifically
>> trying to check that a `SecurityException` wasn't thrown, or did you think
On Wed, 30 Oct 2024 19:28:32 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 Tue, 29 Oct 2024 17:07:56 GMT, Harshitha Onkar wrote:
>> src/java.desktop/share/classes/java/awt/Font.java line 1613:
>>
>>> 1611: * interpreted as a {@code Font} object according to the
>>> 1612: * specification of {@code Font.decode(String)}
>>> 1613: * If the specified prope
> 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 changes in the JEP and also includes an apidiff of the specif
> 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 Thu, 24 Oct 2024 09:27:21 GMT, Fernando Guallini
wrote:
>> 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
>> wi
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 Wed, 30 Oct 2024 18:12:30 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.getIns
> 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 Thu, 24 Oct 2024 09:27:21 GMT, Fernando Guallini
wrote:
>> 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
>> wi
On Wed, 30 Oct 2024 14:48:46 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.getIns
On Wed, 30 Oct 2024 14:48:46 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.getIns
On Tue, 29 Oct 2024 15:56:50 GMT, Fernando Guallini
wrote:
>> Several tests are identified to use weak/legacy algorithms. As these tests
>> purpose is not to exercise weak algorithms, these are updated in this PR to
>> use stronger algorithms. If the test uses a weak key, it is updated as well
On Thu, 24 Oct 2024 09:32:43 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
On Tue, 22 Oct 2024 10:52:23 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
On Thu, 24 Oct 2024 09:32:43 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
On Wed, 30 Oct 2024 16:52:16 GMT, Claes Redestad wrote:
>> Hello Claes,
>>
>>> if there's an encoding error we'd have thrown earlier when hashing over the
>>> full name.
>>
>> If I understand correctly, then I think you are referring to the
>> `ZipCoder.checkedHash()` which throws that `Exce
On Wed, 30 Oct 2024 16:31:28 GMT, Jaikiran Pai wrote:
>> @eirbjo will know for sure but I think it's intentional since if there's an
>> encoding error we'd have thrown earlier when hashing over the full name.
>
> Hello Claes,
>
>> if there's an encoding error we'd have thrown earlier when hash
On Wed, 30 Oct 2024 16:17:20 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/java/util/zip/ZipFile.java line 1798:
>>
>>> 1796:
>>> metaVersions.computeIfAbsent(hashCode, _ -> new BitSet()).set(version);
>>> 1797: } catch (Ex
On Fri, 18 Oct 2024 13:59:32 GMT, Eirik Bjørsnøs wrote:
>> Please review this PR which speeds up `JarFile::getEntry` lookup
>> significantly for multi-release JAR files.
>>
>> The changes in this PR are motivated by the following insights:
>>
>> * `META-INF/versions/` is sparsely populated.
>>
On Wed, 30 Oct 2024 16:14:48 GMT, Jaikiran Pai wrote:
>> Eirik Bjørsnøs has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Map versions by entry name hashcode instead of by entry name. This avoids
>> String allocation and storage
>> -
> The current syntax of the jdk.tls.disabledAlgorithms makes it difficult to
> disable algorithms that affect both the key exchange and authentication parts
> of a TLS cipher suite. For example, if you add "RSA" to the
> jdk.tls.disabledAlgorithms security property, it disables all cipher suites
> 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 Wed, 30 Oct 2024 13:09:26 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.getIns
> 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, 29 Oct 2024 12:40:59 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
50 matches
Mail list logo
