[sldev] Viewer security vulnerability disclosure group

[Gordon Wendt]

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.
>
> Rob
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20081223/84a19af2/attachment.htm