Apologies for multiple earlier emails, please ignore and read this instead.
This proposal is about stripping out and simplifying as much of the
dilapidated and complex SecurityManager infrastructure as possible,
while retaining the ability for developers to implement a better high
scaling and
Inline.
On 26/06/2021 1:46 pm, Peter Firmstone wrote:
Inline below.
On 26/06/2021 1:11 pm, Peter Firmstone wrote:
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks for
autho
On 26/06/2021 1:48 pm, Peter Firmstone wrote:
The innocuous AccessControlContext, is intended to have no permission,
hence it is constructed using the two argument ProtectionDomain
constructor, which causes ProtectionDomain to not consult the Policy.
However, if a user obtains this Protectio
The innocuous AccessControlContext, is intended to have no permission,
hence it is constructed using the two argument ProtectionDomain
constructor, which causes ProtectionDomain to not consult the Policy.
However, if a user obtains this ProtectionDomain and asks the Policy for
the ProtectionDo
Inline below.
On 26/06/2021 1:11 pm, Peter Firmstone wrote:
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note
One more proposed change inline:
On 26/06/2021 12:58 pm, Peter Firmstone wrote:
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note GuardFactory
should never return null and instead return a
Summary of Proposed Changes:
1. GuardFactory & GuardFactorySpi to provide hooks for authorization
checks without SecurityManager or Policy. (Note GuardFactory should
never return null and instead return a no-op Guard that hotspot can
optimize out.
2. Existing Permission implementations t
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
Weijun Wang has updated the pull request incrementally with one additional
commit since the last revision:
one more
--
On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey wrote:
>> Sufficient permissions missing if this code was ever to run with
>> SecurityManager.
>>
>> Cleanest approach appears to be use of InnocuousThread to create the
>> cleaner/poller threads.
>> Test case coverage extended to cover the Securi
On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang wrote:
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
LGTM.
-
Marked as reviewed by naoto (Reviewer).
PR: h
On Fri, 25 Jun 2021 19:39:22 GMT, Valerie Peng wrote:
>> Sean Coffey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Move TokenPoller to Runnable
>
> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java line
> 952:
>
On Tue, 22 Jun 2021 20:08:03 GMT, Sean Coffey wrote:
>> Sufficient permissions missing if this code was ever to run with
>> SecurityManager.
>>
>> Cleanest approach appears to be use of InnocuousThread to create the
>> cleaner/poller threads.
>> Test case coverage extended to cover the Securi
On Fri, 25 Jun 2021 20:04:37 GMT, Weijun Wang wrote:
> More refactoring to limit the scope of `@SuppressWarnings` annotations.
>
> Sometimes I introduce new methods. Please feel free to suggest method names
> you like to use.
Changes look good Max
-
Marked as reviewed by lancea (
More refactoring to limit the scope of `@SuppressWarnings` annotations.
Sometimes I introduce new methods. Please feel free to suggest method names you
like to use.
-
Commit messages:
- 8269409: Post JEP 411 refactoring: core-libs with maximum covering > 10K
Changes: https://git.o
On 6/21/2021 2:02 PM, Paul Sandoz wrote:
On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang wrote:
After JDK-8265518(#3615), it's possible to replace all variants of checkIndex
by Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in
the whole JDK codebase.
Yi Yang has updated th
On Tue, 22 Jun 2021 10:56:00 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my code for updating the code in the
> `java.security` packages to make use of the switch expressions?
>
> Kind regards,
> Patrick
This pull request has now been integrated.
Changeset: 35c47020
> Hi,
>
> Could someone please review my code for updating the code in the
> `java.security` packages to make use of the switch expressions?
>
> Kind regards,
> Patrick
Patrick Concannon has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excl
The more I think about it, allowing Thread to use a singleton immutable
unprivileged AccessControlContext instead of the inherited context is
the right thing to do, it achieves the original goal of avoiding
privilege escalation, limits the the size of the context that needs to
be checked and al
18 matches
Mail list logo
