[sldev] Security Update 2008-10-06 to SL Viewers and source code-CLARIFICATION

[Soft]

We're in the process of roughing out something like that exactly.
These are my meeting notes from a discussion we held about this. This
is draft only, not set policy. Again, feedback is welcome:

* Security release
** How do we want to handle security source releases in the future?
** Ideal process:
*** Stage 1: Internal fix
*** Stage 2: Concurrent with QA, distribute patch to trusted list of people
**** Pre-generated list
**** Agreement in place with us regarding non-disclosure
***** ?? Can known devs fasttrack onto list late?
**** ?? permission to release binary in advance of source
*** Stage 3: Announcement and binary release
**** QA'd LL release
**** Trusted list releases binaries, holds source
**** Short embargo before mainstream source release
*** Stage 4: Source publication
**** We push source, clear trusted list to push source if prev. asked not to

This was only an open source meeting. Decisions about when/where/how
we release details or early prevention advice were outside the scope
of the team present.


On Wed, Oct 8, 2008 at 6:18 AM, Thomas Grimshaw <tom at streamsense.net> wrote:
> Would it not be worth considering some kind of rapid deployment program that
> developers can choose to sign up to, to receive patches early providing
> they've agreed to non disclosure?
>
> This would mean that the serious developers could get the source they need
> as early as possible, without having to request the patches as such.
>
> ~T
>
> Soft wrote:
>>
>> The least "widely used" viewer we shared source with has about 6
>> users. It's honestly not a numbers game, which is why Rob said "widely
>> available," not "widely used." We were reaching out to known viewer
>> maintainers in advance of a full public source disclosure in order to
>> reduce the chance of the information being misused.
>>
>> Working with distributions to prep a fix before full source disclosure
>> is common with open source projects, from the Linux kernel to the most
>> popular ssh, network filesystem and office projects. If you have
>> suggestions for refining the process, please - speak up. But I doubt
>> any of us would advocate dumping a future exploit in the wild before
>> we've even started QA on the fix.
>>
>>
>> On Wed, Oct 8, 2008 at 5:54 AM, Gareth Nelson <gareth at litesim.com> wrote:
>>
>>>
>>> Personally i'd be rather more worried about this attitude of "you must
>>> have a widely-used alternative viewer to get this apparently vital
>>> security update". They aren't telling people it's ok to violate the
>>> GPL as-such, since I doubt they'll allow it after this incident.
>>>
>>> How many users must an alternative viewer have before it becomes
>>> eligible for security updates?
>>>
>>> On Tue, Oct 7, 2008 at 10:14 PM, Jason Giglio <gigstaggart at gmail.com>
>>> wrote:
>>>
>>>>
>>>> Tateru Nino wrote:
>>>>
>>>>>
>>>>> I think the intention was for the binaries to be redistributable, as a
>>>>> special exception - though the source availability would obviously be
>>>>> delayed a day or so. A quick email should sort that out for sure,
>>>>> though.
>>>>>
>>>>
>>>> If Linden Lab is giving people permission to violate the GPL by
>>>> releasing binaries without source, then that is more of a big deal than
>>>> the delay.  Many contributors would be unhappy with that situation.
>>>>
>>
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/SLDev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>