RE ensuring tests don't write to the file system where they shouldn't -- I filed this build improvement: https://github.com/apache/solr/pull/4417
On Wed, Jun 4, 2025 at 11:53 PM David Smiley <[email protected]> wrote: > 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 <[email protected]> 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 > >
