On 4 May 2021, at 03:49, Peter Firmstone <peter.firmst...@zeus.net.au<mailto:peter.firmst...@zeus.net.au>> wrote:
Yes, I'm sure millions of developers don't use the security infrastructure because they only have low value data to protect, or it belongs to someone else and developers that do, can use it incorrectly, it's probably worse to do the latter, but then people synchronize incorrectly too, but we don't remove synchronization because of that. The Security Manager hasn’t been a central part of Java’s server-side security for years. Some of the most critical and best-secured systems in the world are written in Java, and they don’t use the Security Manager, so let’s not equate a particular sandboxing mechanism designed for untrusted code with security. Lets drop the excuses that it's just a theoretical, impractical thing that nobody uses, and say instead that we know that this does something important, it is very powerful, it is a deployed API that is in use, probably the only least privileged protection domain model that really works, but we are no longer supporting it moving forward because it is not well understood by those maintaining it and for this reason it creates a significant maintenance burden. I have to disagree on all counts here. Also, I want to emphasise that if Security Manager were an important security feature for Java these days, then “some people have been able to make it effective” is the very opposite of “works” when it comes to security and a mainstream language. You can believe that the maintainers misunderstand this feature — that is a very bold claim — but even if it were true it doesn’t change the following empirical facts: 1. SM is not used as a central security Java feature, 2. It is used at all by very few projects, and 3. it is a heavy maintenance burden. Maybe the reasons for these is misunderstanding or general incompetence but that doesn’t change the reality. Please provide some examples, migration options suggestions will be appreciated. I’ve jotted down some thoughts in a blog post: https://inside.java/2021/04/23/security-and-sandboxing-post-securitymanager/ With Serialization, we've been given more than ample notice to do something about migrating away from it, but OpenJDK paints over it and wastes resources adding features to putty and paint over it some more, features that no one uses. Removing Serialization has greater appeal :) This step to remove SecurityManager is so sudden with no replacement options, it's a broken promise to developers, who've invested in Java. Removing SecurityManager has a significantly negative effect on security for me, just so you know. I'm not happy about its proposed removal, but I realise there's not much I can do about it, other than request it be done in the least painful manner. I began learning Java over 20 years ago, I understand the need to keep Java relevant, however move quickly and break things is for younger software platforms. Not everyone has to agree on every priority decision, and the process doesn’t require convincing every last Java developer. But it is not sudden, and there will be alternatives for those aspects of Security Manager that many people use. I don’t think it is fair to harm millions of Java developers by diverting resources from features they want to features very few people want, as long as a reasonable removal process is employed, and I think it is here. Once SecurityManager has been removed, we will lose control over who has access to sensitive data, so it's likely we will be stuck on the last version of Java that provides SecurityManager. The best way I can see for those who need the level of security that SecurityManager provides is to maintain a community LTS edition on OpenJDK, it will be much easier to maintain and backport security patches if Serialization in its current form has been removed, as it will likely have been removed from later versions of Java by that time. I disagree. Lets be clear Java will no longer be able to finely control access to sensitive data with the removal of SecurityManager. I'm sure it will be a great bonus for OpenJDK dev's not to have to think about, but it will impact some developers significantly, who would like to do so with the least suffering possible. I wouldn’t say Java (or anything else, for that matter) is “able" to do it now, except in the sense that people (scientists) are able (in a billion- dollar particle accelerator) to transmute lead into gold (a few atoms). We’ve had twenty five years to convince the world this could work, the world isn’t buying, and our job isn’t to sell ideas but to serve millions of developers. It’s time to move on. — Ron
