JEP 411, removal of finalizers, a path forward.

Andrew Dinn adinn at redhat.com
Mon Aug 2 09:17:04 UTC 2021


On 01/08/2021 15:28, Uwe Schindler wrote:
>>> I'm working on the assumption that OpenJDK will close any
>>> external holes currently defended by permission checks.  It would
>>> be good if the JDK was secure by default, with properties
>>> required to be set for allowing such things as agents,
>>> management, parsing xml and serialization.
>> 
>> You need to stop repeating this canard. There is no absolute need
>> for OpenJDK to retain a security mechanism to deal with problems
>> that for almost every use case are better solved by using
>> non-OpenJDK alternatives (such as OS security measures). Indeed,
>> it's the other way round: there is an imperative for the project to
>> spend precious resources on alternative capabilities (not
>> necessarily security related).
> 
> Sorry, as another open source project affected by the stupid JEP 411
> desaster I would like to fully confirm to EVERYTHING that Peter said.
> It is not a canard, it is the reality and I am really disappointed
> what happened.

Sorry, Uwe, but the canard *is* right there in the comment I quoted from 
Peter's email i.e. the bogus implication that without the security 
manager the JDK is not 'secure by default'. Irrespective of how useful 
the security manager is to your project it is utter steer manure to 
claim that without it there is a serious security hole.

That's not to say different measures may need to be taken by some 
applications, yours included. I'm not denying that. However, I'm not 
going to back down when it comes to objecting to the lack of 
proportionality in Peter's claims.

I believe Alan has answered your rather speculative follow-up comments 
so I'll rest on that clarification.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill



More information about the security-dev mailing list