On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
>
On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
>
On Tue, 4 May 2021 23:26:34 GMT, Valerie Peng wrote:
>> Martin Balao has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Documentation improvements and minor reordering
>
> Here are some comments. Rest looks fine. Thanks. Valerie
> Hi,
>
> Please find in this PR a proposal to fix JDK-8265462 [1].
>
> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
> Module. If the NSS Internal Module has more slots (for example, as a result
> of an initialization sequence such as the one triggered from the
On Tue, 4 May 2021 23:25:16 GMT, Valerie Peng wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make some
> performance-based decisions.
>
> Thanks
>
> Tony
On Tue, 4 May 2021 22:24:36 GMT, Valerie Peng wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
On Tue, 4 May 2021 22:19:18 GMT, Valerie Peng wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
On Tue, 4 May 2021 22:14:00 GMT, Valerie Peng wrote:
>> Hi,
>>
>> Please find in this PR a proposal to fix JDK-8265462 [1].
>>
>> With this fix, OpenJDK will only use the known slot IDs for the NSS Internal
>> Module. If the NSS Internal Module has more slots (for example, as a result
>> of
On 18/05/2021 10:21 am, Ron Pressler wrote:
On 18 May 2021, at 01:11, Peter Firmstone wrote:
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to review
Java's internal implementation code, and
> On 18 May 2021, at 01:11, Peter Firmstone wrote:
>
> Your ideas are great in theory, in practice, the problem with your Agent
> proposal is every JVM release needs to be reviewed, and we have to review
> Java's internal implementation code, and understand it in order to instrument
> it.
We can call any mechanism that might impose restrictions a mitigation, but that
doesn’t mean that any mechanism is worth its cost. I believe that the evidence
gathered over the past few decades shows that attempting to assign different
permissions to code of different origin in the same process
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to
review Java's internal implementation code, and understand it in order
to instrument it. But I do appreciate you took the time to do your
homework to
Hi Ron,
On Mon, 17 May 2021 at 21:38, Ron Pressler wrote:
>
> I would say that trying to mitigate attacks on vulnerabilities in trusted
> code based on specific code paths is
> not recommended. You’re trying to preemptively defend agains something
> complex — a security bug — with
> another
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
>
> On 17 May 2021, at 21:46, Peter Firmstone wrote:
>
>
> Yes, you are talking about those who maintain and develop OpenJDK, but this
> is only a small proportion of the overall Java developer ecosystem.
Not at all. I’m talking about the millions of developers who don’t get what
they
On Mon, 17 May 2021 18:23:41 GMT, Weijun Wang wrote:
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
>
Please review this implementation of [JEP
411](https://openjdk.java.net/jeps/411).
The code change is divided into 3 commits. Please review them one by one.
1.
https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
The essential change for this JEP, including the
Please review the test changes for [JEP 411](https://openjdk.java.net/jeps/411).
With JEP 411 and the default value of `-Djava.security.manager` becoming
`disallow`, tests calling `System.setSecurityManager()` need
`-Djava.security.manager=allow` when launched. This PR covers such changes for
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make some
> performance-based decisions.
>
> Thanks
>
> Tony
On Mon, 17 May 2021 19:28:04 GMT, Valerie Peng wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and make
On Mon, 17 May 2021 20:29:37 GMT, Valerie Peng wrote:
>> src/java.base/share/classes/com/sun/crypto/provider/AESCipher.java line 155:
>>
>>> 153: super(32, new AESCrypt());
>>> 154: }
>>> 155: }
>>
>> These should be removed since SunJCE registers
>>
On 18/05/2021 12:25 am, Ron Pressler wrote:
On 17 May 2021, at 13:47, Peter Firmstone wrote:
It is a foundational feature, it has a significant impact on those who adopted
it.
True. But the problem is that it also has a significant impact on those who
didn’t.
Yes, you are talking
On Mon, 17 May 2021 20:24:51 GMT, Valerie Peng wrote:
>> Hi,
>>
>> I need a review of this rather large change to GCM. GCM will no longer use
>> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
>> also a major code redesign limits the amount of data copies and make
On Mon, 17 May 2021 18:13:46 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make
On Mon, 17 May 2021 18:13:46 GMT, Anthony Scarpino
wrote:
> Hi,
>
> I need a review of this rather large change to GCM. GCM will no longer use
> CipherCore, and AESCrypt to handle it's buffers and other objects. It is
> also a major code redesign limits the amount of data copies and make
Hi,
I need a review of this rather large change to GCM. GCM will no longer use
CipherCore, and AESCrypt to handle it's buffers and other objects. It is also
a major code redesign limits the amount of data copies and make some
performance-based decisions.
Thanks
Tony
-
Commit
> This PR contains the API and implementation changes for JEP-412 [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/412
Maurizio Cimadamore has updated the pull
> This PR contains the API and implementation changes for JEP-412 [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/412
Maurizio Cimadamore has updated the pull
> On 17 May 2021, at 13:47, Peter Firmstone wrote:
>
> It is a foundational feature, it has a significant impact on those who
> adopted it.
True. But the problem is that it also has a significant impact on those who
didn’t.
>
>
> This is an existing system, your arguments are not
(Crosspost from core-libs-dev@:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-May/077483.html)
I'm one of the maintainers of Jazzer (
https://github.com/CodeIntelligenceTesting/jazzer), a new open-source
fuzzer for the JVM platform. Jazzer has recently been integrated into
Google's
On Mon, 17 May 2021 12:33:53 GMT, Fabian Meumertzheim
wrote:
> `sun.security.util.DerIndefLenConverter#convertBytes` does not perform
> sufficient checks after calling `#parseValue`, which can overflow `dataPos`
> or make it exceed `dataSize`. This can lead to an
>
Some quick clarifications, I'll try to reply properly in the next few days.
On 17/05/2021 9:29 pm, Ron Pressler wrote:
On 17 May 2021, at 06:19, Peter Firmstone wrote:
In versions of Java, without a security manager, the third party service
provider will have AllPermission, and the user
`sun.security.util.DerIndefLenConverter#convertBytes` does not perform
sufficient checks after calling `#parseValue`, which can overflow `dataPos` or
make it exceed `dataSize`. This can lead to an `ArrayIndexOutOfBoundsException`.
The fix is to ensure `dataPos` is in the valid range
I would say that trying to mitigate attacks on vulnerabilities in trusted code
based on specific code paths is
not recommended. You’re trying to preemptively defend agains something complex
— a security bug — with
another complex mechanism. Even if you do happen to defend against a particular
> On 17 May 2021, at 06:19, Peter Firmstone wrote:
>
>
> In versions of Java, without a security manager, the third party service
> provider will have AllPermission, and the user will have restricted
> permissions (if we still have some form of user Permission based access
> control).
36 matches
Mail list logo
