[
https://issues.apache.org/jira/browse/SOLR-14593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-14593:
------------------------------
Description:
h2. Why?
Users installing third party plugins from external repos trust the public keys
of that repository owner. Anyone who has a private key to that repo will be
able to push any executable binary into such a cluster using the HTTP upload
endpoints. These executables will remain trusted.
h3. Solution: Disable uploading jars over HTTP (they can be downloaded via CLI
by the user)
* {{/cluster/files/*}} endpoint will stop accepting files. That end-point will
not exist
* All jar files will need to be uploaded using the CLI. The CLI has access to
a physical file system where it copies the jar file to
{{$SOLR_HOME/filestore/*}} and issues the sync command. The sync command asks
other nodes to sync the jar file from this local node. (This is how the keys
are distributed today)
h2. Is this backward compatible?
No. For anyone using the internal APIs only to deploy, their packages will stop
working. Anyone using the CLI will have the same experience and they do not
need to make any changes to their workflow.
was:
h2. Why?
Users installing third party plugins from external repos trust the public keys
of that repository owner. Anyone who has a private key to that repo will be
able to push any executable binary into such a cluster using the HTTP upload
endpoints. These executables will remain trusted.
h3. Solution: Disable uploading jars over HTTP (they can be downloaded via CLI
by the user)
* /cluster/files/* endpoint will stop accepting files. That end-point will not
exist
* All jar files will need to be uploaded using the CLI. The CLI has access to a
physical file system where it copies the jar file to $SOLR_HOME/filestore/*
and issues the sync command. The sync command asks other nodes to sync the jar
file from this local node. (This is how the keys are distributed today)
h2.Is this backward compatible?
No. For anyone using the internal APIs only to deploy, their packages will stop
working. Anyone using the CLI will have the same experience and they do not
need to make any changes to their workflow.
> Package store API to disable file upload over HTTP
> --------------------------------------------------
>
> Key: SOLR-14593
> URL: https://issues.apache.org/jira/browse/SOLR-14593
> Project: Solr
> Issue Type: Task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Priority: Blocker
> Fix For: 8.6
>
>
> h2. Why?
> Users installing third party plugins from external repos trust the public
> keys of that repository owner. Anyone who has a private key to that repo will
> be able to push any executable binary into such a cluster using the HTTP
> upload endpoints. These executables will remain trusted.
> h3. Solution: Disable uploading jars over HTTP (they can be downloaded via
> CLI by the user)
> * {{/cluster/files/*}} endpoint will stop accepting files. That end-point
> will not exist
> * All jar files will need to be uploaded using the CLI. The CLI has access
> to a physical file system where it copies the jar file to
> {{$SOLR_HOME/filestore/*}} and issues the sync command. The sync command asks
> other nodes to sync the jar file from this local node. (This is how the keys
> are distributed today)
> h2. Is this backward compatible?
> No. For anyone using the internal APIs only to deploy, their packages will
> stop working. Anyone using the CLI will have the same experience and they do
> not need to make any changes to their workflow.
--
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
