[
https://issues.apache.org/jira/browse/SOLR-13978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16992617#comment-16992617
]
David Smiley commented on SOLR-13978:
-------------------------------------
I think most importantly in this issue we should ensure the default configSet
does not use contrib modules. Contribs should be opt-in. So just remove all
lib directives and just leave the comment explaining/documenting the mechanism
without actually referencing any contribs, not even in an example (to reduce
maintenance). I know only some of our contribs have been receiving scrutiny
from a security/DOS perspective but I think we should be consistent in not
referencing any.
{quote}Can we disable this Config API by default here too?
{quote}
I'm sympathetic to this. There are multiple ways to configure Solr. The way
~90% of projects (wild guess, in my experience) configure Solr is direct
configSet manipulation in standalone or similarly via uploading configSets to
ZooKeeper for SolrCloud. The "Config API" is the alternative using web-service
APIs, and what is disabled via disable.configEdit. If the Config API had
realized it's full potential then perhaps it would be THE way to configure
Solr, but it's just not there after so many years :( Sure you can use it
provided that you don't need to configure something it doesn't support; plus
there is some awkwardness in it's coupling to cores/collections instead of
being independent. And then there's all the docs / tutorial etc. that presume
the classic approach. Perhaps my statements as to _why_ it's not used much is
irrelevant, but I'm confident it's not used much. So if we can agree that most
users don't use it and accept this reality, then disabling it would strengthen
Solr's security posture. On the other hand, this erects yet another road block
to the Config API realizing its potential, which is sad. Should we disable by
default, we should not construe this as "you shouldn't use it" nor as "it's
insecure".
I anticipate [~ichattopadhyaya] might mention that the new plugin architecture
includes a contentious feature of including config API commands so that a
plugin can self-install. Then using those features would then require
disable.configEdit=false if we change the default. But I think that mechanism
could be enhanced to not require config API. This is perhaps off topic; sorry.
> Remove bloat from default configset
> -----------------------------------
>
> Key: SOLR-13978
> URL: https://issues.apache.org/jira/browse/SOLR-13978
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Ishan Chattopadhyaya
> Priority: Blocker
> Fix For: 8.4
>
>
> We need to review and remove all components that are not essential for
> search, indexing and other core functionality. Velocity, DIH, etc. should be
> reviewed.
> (Marking this as a 8.4 release blocker).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
