*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
