[
https://issues.apache.org/jira/browse/SOLR-17584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17937973#comment-17937973
]
David Smiley commented on SOLR-17584:
-------------------------------------
Issues (tickets) can only be assigned to committers. It's not important; we
don't really use this aspect of jira except to signal that something is being
worked on (but we can obviously see here that it is the case).
> 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
> Time Spent: 1h 50m
> 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: [email protected]
For additional commands, e-mail: [email protected]
