rmuir commented on pull request #579: URL: https://github.com/apache/lucene/pull/579#issuecomment-1005729803
> I've been wondering what to do with the security manager. If we're on Java 17, where it's officially deprecated, perhaps we should just get rid of it? I know it sounds terrible but it's inevitable in the long run anyway - if main is the future version then perhaps it's the time to commit to such a decision? I don't think we should "just get rid of it". I have two concerns: 1. `AccessController` calls in order to support apps that are still using SecurityManager. We are a library, and the feature is deprecated, but those apps should be able to do their own migration, we should try to play with it well. 2. Tests. I remember the days before SecurityManager enforced tests to stay within their own tmpdir sandboxes. It was a nightmare. You'd have tests writing on the filesystem to various locations (possibly predictably-named tempdirs), stampeding on each other, causing hard-to-debug failures. So I'd rather not go back to that chaotic debugging :) Our tests are rather contained, we already ban (most of?) `java.io.*` with Forbidden APIs. So I think a NIO.2 filesystem wrapper (like the other ones we have) that enforces tests don't write out of their sandbox would really help prevent tests from doing bad things. And maybe we have to crank up the forbidden APIs on the tests to detect stuff typical stuff like `Paths.of`, `Paths.get` which would bypass the check. So I'd propose a separate issue for this -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
