This is a thoughtful organization attempt and needed, I think. Thanks Gus!
I want to see if I could get a security specialist/engineer where I work to help us with this. I'm tempted to say I'm joining this thing but I'm weary of dedicating time per week. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Apr 24, 2023 at 1:33 PM Gus Heck <gus.h...@gmail.com> wrote: > *Rationale* > > Over the course of the last decade the way software security is viewed has > changed. Solr has changed significantly over this time too and we have > gained some important security features and fixed a variety of > vulnerabilities. However, I think as a project we have not really developed > a clear vision of what our security goals and use cases are. I have > witnessed a fair bit of variability in the responses to security related > queries, and I think much of the variability comes from conflation among > "good practical advice", "somewhat dated advice" and "varying notions of > supported use cases". We also regularly receive reports to the > secur...@solr.apache.org address that involve investigations into systems > that are not properly secured to begin with or configured to explicitly > allow the dangerous behavior and it's a shame to see security researchers > waste their time on that. Finally, the PMC and set of people subscribed to > secur...@solr.apache.org is a large enough group that incoming mails often > seem to languish in a classic example of nobody having actual specific > responsibility for responding. > > *Proposal* > The Solr PMC should appoint from among its members either 3 to 5 > individuals to serve as a "security working group" Membership in the > "Security Working Group" requires subscribing to secur...@solr.apache.org, > and a 30 minute conference call once or twice a month. This working group > would have the following goals. > > 1. Establish a relationship with someone who's core job function is > computer security, rather than providing search (I'm hoping the ASF has > some people who secure their systems that could be a resource). This > person > should be willing to offer a systems security perspective on our goals > and > the security functionality we provide. > 2. Develop a clear statement of the security use cases we would like to > support, and exposition of some scenarios that are clearly out of scope. > This results in a proposal to be discussed on the dev list and users > list > and eventually voted on. > 3. Identification of use cases we would like to support that are not yet > supported, and publicize them to encourage these contributions. > 4. Review of documentation to ensure consistency with our current state > (security only, perhaps annually?). > 5. Creation of a "security report checklist" that security researchers > can self apply before they submit reports. > 6. Form letters for consistent response to reports that haven't passed > the checklist. > 7. Provide consistent and prompt responses to possible > vulnerabilities reported to secur...@apache.org. Those subscribed to > secur...@solr.apache.org who are not in the working group should allow > the working group time to respond before responding themselves. > 8. When asked, offer opinions on proposed new security features > regarding consistency with the goals (working group to discuss, return > with > an opinion, always publically and just as a voice in the conversation, > not > as any sort of veto/control, decisions are still up to the list of > course). > > NON-GOAL: The group is not responsible for fixing security bugs or adding > security features. (nothing stopping them of course, just not the point of > the group, which is a goal setting and consistency oriented group) > > *Volunteer* > > And to lower the barrier to things started, I volunteer to participate in > this WG for at least a year, and spend up to 2h/week on it. I don't think > any members should be expected to dedicate more than that to it, and > probably many weeks the time required should be less. > > *Feedback* > > Of course if you think this idea can be tweaked or improved, speak up! The > whole reason this is mailed to the dev list is to get broad feedback so > that we can implement the best improvements possible. > > -Gus >
