On Mon, Apr 25, 2022 at 2:55 PM David Lloyd <david.ll...@redhat.com> wrote:
> Nothing in the proposal causes splitting or delegation of > responsibilities. It is _only_ about preserving security checkpoints > in the JDK, which *add* a layer of checks to what the container might > already provide. Nothing is being subtracted, and thus I find it hard > to accept that preserving these checks somehow reduces security > overall. In absolute terms, using a security manager (even with all of > its problems) is *more* secure than not using it on the same code base > and deployment. I'm not sure how this can be rationally refuted. The > proposal is about retaining this incremental increase in security, > while both adjusting the user's expectations via documentation *and* > significantly reducing the burden of CVEs and maintenance on the JDK > itself (and putting it on to the third party authorization framework), > which in my estimation is the *real* stakes here. I think there's a difference between "perceived" security and "actual" one. The SM in today's post Spectre, Meltdown and the likes world is "perceived" security, which may lead to a relaxation on the security of other layers because at least "we have additional security checkpoints in the JDK". Cheers, Mario -- Mario Torre Manager, Software Engineering, core OpenJDK Red Hat GmbH <https://www.redhat.com> 9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
