On 4/11/2021 12:14 am, Pavel Rappo wrote:
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
This PR follows up one of the recent PRs, where I used a non-canonical modifier
order. Since the problem was noticed [^1], why not to address it en masse?
As far as I remember, the first
Rick if you fear an attacker can modify and install a JAR with a broken
signature which you don’t trust anyway, what should stop the attacker to
provide a valid but untrusted signature or no checksums at all? It might be a
undesirable change for your case but I see no trustmodel where you would
On Fri, 29 Oct 2021 06:07:26 GMT, Lari Hotari wrote:
>> For anyone interested, there's an explanation of the [Bleichenbacher's CCA
>> attack on PKCS#1 v1.5 on
>> Stackexchange](https://crypto.stackexchange.com/questions/12688/can-you-explain-bleichenbachers-cca-attack-on-pkcs1-v1-5).
>> The
I would suggest to fix in a separate bug.
Thanks,
Xuelei
> On Nov 3, 2021, at 2:27 PM, Daniel Jeliński wrote:
>
> On Wed, 3 Nov 2021 09:12:29 GMT, Daniel Jeliński
> wrote:
>
>>> src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java
>>> line 436:
>>>
434:
435:
On Wed, 3 Nov 2021 09:12:29 GMT, Daniel Jeliński wrote:
>> src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java line
>> 436:
>>
>>> 434:
>>> 435: void queueUpCipherDispose() {
>>> 436: RecordMemo lastMemo = handshakeMemos.getLast();
>>
>> Sorry, I
On Mon, 20 Sep 2021 09:35:57 GMT, Lari Hotari wrote:
>> ### Motivation
>>
>> When profiling an application that uses JWT token authentication, it was
>> noticed that a high number of `javax.crypto.BadPaddingException`s were
>> created. When investigating the code in RSAPadding, one can see
On Mon, 20 Sep 2021 09:35:57 GMT, Lari Hotari wrote:
>> ### Motivation
>>
>> When profiling an application that uses JWT token authentication, it was
>> noticed that a high number of `javax.crypto.BadPaddingException`s were
>> created. When investigating the code in RSAPadding, one can see
On Mon, 20 Sep 2021 08:38:18 GMT, Lari Hotari wrote:
> ### Motivation
>
> When profiling an application that uses JWT token authentication, it was
> noticed that a high number of `javax.crypto.BadPaddingException`s were
> created. When investigating the code in RSAPadding, one can see that
>
On Mon, 20 Sep 2021 08:43:24 GMT, Aleksey Shipilev wrote:
> Submitted the bug for it,
> [JDK-8273977](https://bugs.openjdk.java.net/browse/JDK-8273977). Please
> change the PR title to "8273977: Reduce unnecessary BadPaddingExceptions in
> RSAPadding" to get bots hooked properly.
Thanks for
On Mon, 20 Sep 2021 08:38:18 GMT, Lari Hotari wrote:
> ### Motivation
>
> When profiling an application that uses JWT token authentication, it was
> noticed that a high number of `javax.crypto.BadPaddingException`s were
> created. When investigating the code in RSAPadding, one can see that
>
### Motivation
When profiling an application that uses JWT token authentication, it was
noticed that a high number of `javax.crypto.BadPaddingException`s were created.
When investigating the code in RSAPadding, one can see that BadPaddingException
is created in all cases, also on the success
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
> Please review the patch for JDK-8274524
>
> The fix just adds locks around InputStream read and skip operations to
> prevent concurrent read from socket.
> sun/security/ssl jtreg tests passed
> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
Alexey Bakhtin has updated the pull
Thanks for your detailed comments, Sean. We agree wholeheartedly that
being signed and being trusted/valid are two separate concepts. The JDK
wisely punts the issue of trust to the application developer. As I
understand it, we disagree about the following points:
1) Is the signedness of a jar
> Please review the patch for JDK-8274524
>
> The fix just adds locks around InputStream read and skip operations to
> prevent concurrent read from socket.
> sun/security/ssl jtreg tests passed
> api/javax_net/ssl/SSLSocket/setUseClientMode jck test passed
Alexey Bakhtin has updated the pull
On Wed, 3 Nov 2021 16:46:49 GMT, Alexey Bakhtin wrote:
>> Please review the patch for JDK-8274524
>>
>> The fix just adds locks around InputStream read and skip operations to
>> prevent concurrent read from socket.
>> sun/security/ssl jtreg tests passed
>>
On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find here a trivial cleanup change that updates classes in the
> `java.net.http` module to use the "blessed modifier order".
>
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh
>
On Wed, 3 Nov 2021 09:16:47 GMT, Daniel Jeliński wrote:
>> The current code that changes cipher suites disposes the new suite instead
>> of the old one, which usually silently fails. This patch fixes the code to
>> dispose the old instance instead.
>>
>> DTLS appears to be unaffected:
On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find here a trivial cleanup change that updates classes in the
> `java.net.http` module to use the "blessed modifier order".
>
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh
>
> You can create a password-less PKCS12 KeyStore file now by calling
> `ks.store(outStream, null)` no matter what the default cert protection
> algorithm and Mac algorithm are defined in `java.security`.
>
> Note: the system properties set in `ToolsJDK.gmk` to generate `cacerts` must
> be
On Wed, 3 Nov 2021 10:11:31 GMT, Daniel Fuchs wrote:
> Hi,
>
> Please find here a trivial cleanup change that updates classes in the
> `java.net.http` module to use the "blessed modifier order".
>
> The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh
>
On Tue, 2 Nov 2021 15:18:10 GMT, Sean Mullan wrote:
>> Weijun Wang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> clarification on protected attributes
>
> src/java.base/share/classes/java/security/KeyStore.java line 1030:
>
>> 1028:
> Add `KeyStore::getAttributes` so that one can get the attributes of an entry
> without retrieving the entry first. This is especially useful for a private
> key entry which can only be retrieved with a password.
Weijun Wang has updated the pull request incrementally with one additional
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it en
> masse?
>
> As far as I remember, the first mass-canonicalization of modifiers took
On Wed, 3 Nov 2021 13:08:55 GMT, Maurizio Cimadamore
wrote:
>> This PR contains the API and implementation changes for JEP-419 [1]. A more
>> detailed description of such changes, to avoid repetitions during the review
>> process, is included as a separate comment.
>>
>> [1] -
> This change implements a new service provider interface for host name and
> address resolution, so that java.net.InetAddress API can make use of
> resolvers other than the platform's built-in resolver.
>
> The following API classes are added to `java.net.spi` package to facilitate
> this:
>
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
> This PR contains the API and implementation changes for JEP-419 [1]. A more
> detailed description of such changes, to avoid repetitions during the review
> process, is included as a separate comment.
>
> [1] - https://openjdk.java.net/jeps/419
Maurizio Cimadamore has updated the pull
On Tue, 2 Nov 2021 20:34:44 GMT, Martin Buchholz wrote:
>>> Pragmatically, fix the script to ignore those keywords on comment lines.
>>> Learn Perl, its just a regular expression pattern match and replace
>>> expression.
>>
>> I understand in principle how to modify that script to ignore doc
Hi,
Please find here a trivial cleanup change that updates classes in the
`java.net.http` module to use the "blessed modifier order".
The changeset was obtained by running `sh ./bin/blessed-modifier-order.sh
src/java.net.http`.
best regards,
-- daniel
-
Commit messages:
-
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it en
> masse?
>
> As far as I remember, the first mass-canonicalization of modifiers took
> The current code that changes cipher suites disposes the new suite instead of
> the old one, which usually silently fails. This patch fixes the code to
> dispose the old instance instead.
>
> DTLS appears to be unaffected: DTLSOutputRecord keeps 2 ciphers and correctly
> [disposes the old
>
On Tue, 2 Nov 2021 23:43:42 GMT, Xue-Lei Andrew Fan wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> avoid modifying DTLSOutputRecord
>
> src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java
On Tue, 2 Nov 2021 23:35:51 GMT, Xue-Lei Andrew Fan wrote:
> Please hold off on the integration, the regression testing failed.
could you point me to the failing test? I'm running the jdk_security suite;
only sun/security/mscapi/ShortRSAKeyWithinTLS is failing, and it's failing
because of
34 matches
Mail list logo
