Thanks David. It would be great to have you if you can find time for it. As far as time commitment goes, I think it should become minimal after a while unless we have a flood of security reports to respond to. For a little while after initial organization, I think the members will want to put a bit of effort into hitting some of the goals I mentioned.
On Tue, Apr 25, 2023 at 12:28 AM David Smiley <dsmi...@apache.org> wrote: > 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 > > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
