On Fri, 8 Apr 2022 06:52:57 GMT, Xue-Lei Andrew Fan wrote:
> The Socket implementation will take care of the file description/native
> memory release, I think.
I've walked through the network code and understand it now. The Socket
creation code calls into sun.nio.ch.NioSocketImpl.create():451
On Fri, 8 Apr 2022 20:07:32 GMT, Sean Mullan wrote:
>> Please review these changes to update the security libraries to use sealed
>> classes. See JEP 409 for more details on sealed classes.
>>
>> No CSR is required as all the changes are to internal classes. A few classes
>> that did not have
> Please review these changes to update the security libraries to use sealed
> classes. See JEP 409 for more details on sealed classes.
>
> No CSR is required as all the changes are to internal classes. A few classes
> that did not have subclasses were simply marked final instead of sealed.
Sea
On Fri, 8 Apr 2022 16:11:27 GMT, Weijun Wang wrote:
>> Sean Mullan has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make some classes package-private instead of sealed.
>
> src/java.base/share/classes/sun/security/rsa/RSASignature.java li
On Fri, 8 Apr 2022 16:17:19 GMT, Weijun Wang wrote:
> It looks `KrbTgsRep.java`, `Krb5ProxyCredential.java`, `Builder.java`,
> `Vertex.java`, `Validator.java`, and `RSAKeyPairGenerator.java` can all be
> made package private.
Good point, although I would prefer to leave `Validator` as public f
On Fri, 8 Apr 2022 13:50:25 GMT, Weijun Wang wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update copyright year
>
> @bchristi-git showed me this test. You might try it on other objects:
>
> import org.iet
On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote:
> Please review these changes to update the security libraries to use sealed
> classes. See JEP 409 for more details on sealed classes.
>
> No CSR is required as all the changes are to internal classes. A few classes
> that did not have subcl
On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote:
> Please review these changes to update the security libraries to use sealed
> classes. See JEP 409 for more details on sealed classes.
>
> No CSR is required as all the changes are to internal classes. A few classes
> that did not have subcl
On Fri, Apr 8, 2022 at 10:14 AM Sean Mullan wrote:
>
> Ok, thanks for some clarification on the proposal.
>
> How many applications currently depend on the SM for this type of usage?
> What other alternate models have you considered?
There are some number of customers and users within our user ba
On Fri, 8 Apr 2022 13:40:37 GMT, Sean Mullan wrote:
> Please review these changes to update the security libraries to use sealed
> classes. See JEP 409 for more details on sealed classes.
>
> No CSR is required as all the changes are to internal classes. A few classes
> that did not have subcl
On Wed, 6 Apr 2022 17:45:13 GMT, Naoto Sato wrote:
> This is a follow-on task after deprecating the Locale constructors
> (https://bugs.openjdk.java.net/browse/JDK-8282819). Most of the changes are
> simple replacements to Locale constructors with `Locale.of()` or Locale
> constants, such as `
Ok, thanks for some clarification on the proposal.
How many applications currently depend on the SM for this type of usage?
What other alternate models have you considered?
In general, I think authorization is best done at a higher layer within
the application and not via low-level SM callout
On Thu, 7 Apr 2022 19:21:31 GMT, Xue-Lei Andrew Fan wrote:
>> Please review the update to remove finalizer method in the
>> java.security.jgss module. It is one of the efforts to clean up the use of
>> finalizer method in JDK.
>
> Xue-Lei Andrew Fan has updated the pull request incrementally wi
Please review these changes to update the security libraries to use sealed
classes. See JEP 409 for more details on sealed classes.
No CSR is required as all the changes are to internal classes. A few classes
that did not have subclasses were simply marked final instead of sealed.
-
Small correction:
On Fri, Apr 8, 2022 at 8:03 AM David Lloyd wrote:
> Instead the API would exist to give containers and applications an
> extra layer of authorization which does not exist today.
Of course I meant "which would not exist after JEP 411".
--
- DML • he/him
Hi Sean, thanks for replying. I'll reply inline.
On Thu, Apr 7, 2022 at 2:20 PM Sean Mullan wrote:
>
> With this proposal, as I understand it, the JDK would still be
> responsible for maintaining and preserving essentially all of the
> existing calls to the Security Manager (SM).
I think we'd ac
Thanks for trying David. :)
Regards,
Peter.
On 8/04/2022 7:15 pm, Andrew Dinn wrote:
I'm 100% in agreement with Sean. This proposal leaves the OpenJDK team
with just as much -- or possibly more -- code to maintain, test and
design around while making the behaviour under the retained API less
I'm 100% in agreement with Sean. This proposal leaves the OpenJDK team
with just as much -- or possibly more -- code to maintain, test and
design around while making the behaviour under the retained API less
determinate, less reliable as a security enforcement mechanism and, in
consequence, eve
18 matches
Mail list logo
