Ten is the perfect time to rip it out. Let's separate ripping it out from
"whatever else we decide"... Otherwise we'll bike shed it to death!
I know you have under "Rejected Alternatives" the statement "Leaving Solr
unprotected", but honestly, I think that is just too broad of a statement.
Plus, I don't actually see why ideas like "Build a custom Java Agent" are
really needed... I think we look at what the rest of the Java-world is doing
and copy them. And if that is "they never adopted JSM and therefore are not
impacted" then let's do that. Let's NOT build a custom Java Agent ;-). If
there is a great maintained third party project that does great stuff we could
leverage, like any other depenendency, then let's do that instead. And if
there isn't anything, well, maybe we are just following the path of the
Java-world....
On Wednesday, June 4, 2025 at 11:54:21 PM EDT, David Smiley
<dsmi...@apache.org> 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 <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
