I'm sorry to have moved the discussion into the package manager tangent. Let's focus on the encryption module that was originally proposed in this thread, and discuss the package manager separately.
On Sun, 19 Mar, 2023, 1:19 am Gus Heck, <gus.h...@gmail.com> wrote: > Downloading executable code is not evil in every scenario. IMHO, What we > should be avoiding is A) allowing this by default, and B) The first, most > simple way of enabling it should involve designating specific locations > that the *user* configuring solr trusts and require establishment of trust > (via certs or whatever) with the source. For example a user's curated > internal artifactory nexus or other similar server could very well be a > safe source (dependent of course on the quality of the curation). C) > Running without establishing trust should be possible, but it should take > multiple steps to enable explicitly, and print warnings with easily matched > unique phrases in the logs (for monitoring) at start up and any time code > is loaded after startup. > > However, recently we stated that certain admin permissions imply full > control including the ability to add code.[1] > > For a while I have been feeling like decisions on this front are pushed > around too much by people thinking about the work involved in making the > changes and also the work involved in absorbing the changes in existing > installations. I suspect we really need to have a working group that > includes some security expertise from outside of Solr and some PMC members > to lay down clear concepts of what industry standards are, what security > features users value, how that could be achieved in solr, and an > incremental roadmap to get there. The primary value of this would be a work > list of things that can be done, and a solid notion of whether or not new > features or fixes are counter productive. > > I think if we don't have a clear overall plan there will continue to be a > slow burn of "security stress" with varying degrees of action, possibly in > contradictory directions > > -Gus > > [1]: > > https://github.com/apache/solr/commit/d6b8f300711a59230531c855809debb745eb72a8#diff-574a8b92f2444ddaf83505218a9f43e394f150cd00ae57b1292374b0c2159f7aR404 > > On Sat, Mar 18, 2023 at 12:41 PM Shawn Heisey <apa...@elyograg.org> wrote: > > > On 3/15/23 13:52, Jan Høydahl wrote: > > > There's a catch-22 here. Enterprises that require encryption at rest > > likely won't tolerate > > > enabling a package manager that lets you download executable code from > > the internet during runtime, > > > especially when that package manager is both home-grown, and largely > > unused and neglected. > > > > Downloading executable code at runtime within Solr itself does seem like > > a VERY bad idea. I don't think we should do that at all, which includes > > doing it in the admin UI. In addition to potential hijacking attack > > vectors, some artifacts might have classloader issues if dynamically > > loaded at runtime. > > > > Make it something a user does manually at the commandline with the solr > > script and require a service restart. Have it give the user a > > cryptographic signature or hash for all downloaded artifacts. We could > > even include those signatures in the Solr distribution so the package > > install can verify them, and printing them out makes it easier for the > > user to do their own independent verification. > > > > Of course a truly paranoid user can copy the downloaded artifacts to > > another sandboxed system and obtain the signature themselves for > > comparison. > > > > Thanks, > > Shawn > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) >
