[sldev] Viewer security vulnerability disclosure group

[Soft]

What we're talking about here is a couple days' lead time for viewer
distributors and other key source consumers. This is very similar to
how vulnerabilities in many services - and even the kernel - are
handled with various *nix distros. This is different than "security
through obscurity," which is generally used in reference to projects
that try (and always fail) to rely on secrets in perpetuity.

In evaluating the other points below - it's not clear what you mean
about blackholing issues. Most security issues never exist in the
public JIRA, either being discovered internally, or being reported to
the security@ list. The minority of issues that do appear in pJIRA
more often appear as SEC- issues. For the tiny remainder appearing in
VWR- and SEC-, in the past we haven't really tried to mask the issues
that should have gone to SEC- but didn't. I can only think of one
issue that got moved into SEC- and it was less a security issue than a
griefing issue. Do you have a specific issue or set of issues in mind?

On Tue, Dec 23, 2008 at 9:34 PM, Gordon Wendt <GordonWendt at gmail.com> wrote:
> Rob to channel a little you know who here I think this idea stinks.  If you
> have something to say you should be able to say it to all people on Sldev
> and not just to a select group of specially selected people so my suggestion
> on criteria is to have no criteria.  Security isn't about being secretive
> about the problems with your software, security through obscurity DOES NOT
> WORK and just hurts trust in your software.
>
> The smart way to work is to allow people to report privately if they really
> want to but in general just be quick about dealing with fixing issues to
> minimize the window of opportunity.  I'd also suggest that unless the person
> posts a JIRA issue in SEC or requests that it be moved there to stop
> blackholing issues.  Blackholing issues is generally ineffective for several
> reasons
>
> 1) the main issue description usually has more than enough information to
> reproduce and for issues that weren't posted originally to SEC thanks to the
> email list of JIRA updates that is essentially public knowledge that you
> can't recall as soon as the issue is posted.
>
> 2)  Even if one isn't true, any changes or comments giving more information
> or repro instructions become public knowledge per number one up to the point
> the issue is blackholed.
>
> 3) All that blackholing issues does is prevent resident input and residents
> from helping to repro, debug, and fix an issue and while that isn't always
> necessary I am sure that in many cases bugs could be fixed much better with
> user input.
>
> The above list may seem off topic since it mainly applys to your JIRA policy
> but it really applies to LL's whole view of security (and the opinion of
> most software makers) that residents can't help with security issues and
> that any resident input except from a very select group of contributors or
> distributors, made up in this case by patch/code submitters and third party
> viewer creators respectively, should be shunned.
>
> The take home summary of this is really that in my opinion it would be a
> huge mistake to create any sort of limited "first access" system for
> notification of security bugs.
>
> On Tue, Dec 23, 2008 at 7:37 PM, Rob Lanphier <robla at lindenlab.com> wrote:
>>
>> Hi folks,
>>
>> When we had the vulnerability in the Second Life viewer back in October,
>> we didn't have a great setup for communicating discreetly with people
>> who are working on derived works to give them a warning that they'll
>> need to publish an update to keep their users safe.
>>
>> Since the viewer is totally secure now, I suppose this isn't a problem,
>> no?  Hrmph, ok, I guess we should be a little more prepared next time.
>>
>> I did some fishing around for how other folks handle this.  Here's info
>> on Mozilla's Security Group, which seems most analogous.
>> http://www.mozilla.org/projects/security/membership-policy.html
>>
>> And here's the  "Announcing Security Vulnerabilities" section from Karl
>> Fogel's book "Producing Open Source Software":
>> http://producingoss.com/en/publicity.html#security
>>
>> Here's what I'd like from you all:
>> 1.  A discussion about what group of people it's going to be acceptable
>> to provide early access to vulnerability information.  For example, is
>> it reasonable for us to require non-disclosure agreements of everyone in
>> the group?  I suspect that we'll need to take this step, but if there's
>> a really good reason that I'm not thinking of why we shouldn't do this,
>> I'd like to hear it.
>> 2.  If you're interested in being in this group, send me an email
>> indicating your interest, and why you feel you should be in this group.
>>
>> With any luck, we'll have a group in place before we need have a
>> vulnerability to disclose.