Hi Gus,

I think this is a great idea.

I don't have much security background that'd make me a particularly
good fit, but absent someone with that background stepping up, I'm
willing to volunteer for one of the spots.  (I'd be more than happy to
bow out if better qualified folks come along.)

Best,

Jason

On Sun, Apr 30, 2023 at 7:14 PM David Smiley <dsmi...@apache.org> wrote:
>
> Pretty sleepy thread so far; apparently nobody else is interested in
> talking about Solr security -- LOL ;-)
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Apr 26, 2023 at 8:25 AM Gus Heck <gus.h...@gmail.com> wrote:
>
> > 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)
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org

Reply via email to