[
https://issues.apache.org/jira/browse/SOLR-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved SOLR-17584.
---------------------------------
Fix Version/s: main (10.0)
Resolution: Fixed
Resolving. Thanks again for this Abhishek!
> Remove code and documentation for "trusted"configsets
> -----------------------------------------------------
>
> Key: SOLR-17584
> URL: https://issues.apache.org/jira/browse/SOLR-17584
> Project: Solr
> Issue Type: Improvement
> Components: configset-api, security
> Reporter: Jason Gerlowski
> Priority: Minor
> Labels: newdev, pull-request-available
> Fix For: main (10.0)
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> SOLR-16781 removed the ability for configsets to load code and resources
> using "<lib>" directives.
> These (now removed) "<lib>" directives were the primary motivation for the
> trusted/untrusted configset distinction that was evolved over time to
> restrict which configs/collections could load external libraries. Now that
> they're gone, we should remove code and documentation related to the
> trusted/untrusted distinction.
> Technically, several components (XSLTUpdateRequestHandler,
> ScriptUpdateRequestProcessor) still check configset "trustedness" when being
> loaded. But both of these components require enabling a module at startup
> time (e.g. {{SOLR_MODULES=scripting}}. And if an administrator has already
> put these things on the classpath, layering "trustedness" on top of that
> doesn't seem to add any value or security. (Especially given that the
> "trustedness" determination itself probably shouldn't be relied on, due to
> the number of gaps found in it over the years. In fact this is the main
> motivation for the recent removal of <lib> in the first place.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
