Thanks for raising this topic and putting time into it. IMO the most useful thing to add is a test taming protection mechanism that ensures that tests don't write to places in the project that should be read-only. Basically, if "git" would flag a change, then the test is at-fault. This was a fantastic benefit of the security manager. I've made this mistake before and surely it happened before the SM was used in this way: you write a test that uses one of the Solr home templates, but not intending to actually write data there but it happens. The insidious part is then another test comes along and reads data that shouldn't be there. I started chatting with Gemini on a solution involving a Gradle plugin that would run "git status" before & after. I may explore that further. If I don't... ah well; whatever. Move on.
I don't put much stock in the original / standard use of the SecurityManager. The burden of maintaining its configuration and trade-offs has been annoying. The very vast majority of the Java developer world has ignored it, yet we embraced it. Shrug. If you haven't noticed, there aren't a lot of developer/maintenance hours being put into Solr lately, so let's not overthink a replacement or if there needs to be one in any way. 13 days later, you get the only reply (mine) -- case in point. Sorry for the sad dose of reality. ~ David On Thu, May 22, 2025 at 6:01 AM Jan Høydahl <jan....@cominvent.com> wrote: > Hi, > > Let's kick off a discussion on what protections we'd want to put in place > when Java Security Manager is gone in Java 24. > > Since this is a major topic likely spanning many parts of Solr, I made a > SIP-24 for it: > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-24%3A+Java+Security+Manager+replacemen > > I do not intend to "lead" this effort, but hoping that kick-starting this > discussion will lead to at least a set of JIRA issues being created for > concrete actions for the most important actions. > > Jan
