[License-discuss] Coordinated release of security vulnerability information.

[VanL]

Hi Bruce,

Thanks for sharing your perspective, and I can sympathize with your desire
to get security-related information as quickly as possible. But I don't
really understand your comments about the "Insurgent test" or the other
items you mentioned. I didn't use that term, so I am not sure what you mean.

I *think* you are saying that you would argue against allowing a delayed
disclosure on a policy basis, because you would prefer that there be no
opening for a vendor to delay disclosure to you. Is that right? I would
like to hear you explain more.

Thanks,
Van


On Thu, Aug 22, 2019 at 12:36 PM Bruce Perens via License-discuss <
license-discuss at lists.opensource.org> wrote:

> As a software author, and in order to best support my community, I should
> see security information about my own software as soon as possible. Thus,
> it has always been disquieting that Red Hat has an Enterprise product, the
> main differentiating feature of which is that they have a customer-only
> walled garden around security and bug fix information. We rely on their
> good will for these fixes to eventually reach the actual Open Source
> project. I have also commented on the GRSecurity product and its license
> strategy at
> https://perens.com/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/ ,
> their lawsuit against me for these comments is still ongoing and I have
> this superscedas bond:
> http://perens.com/static/OSS_Spenger_v_Perens/3_17-cv-04002-LB/doc1/pdf/100-1.pdf
>
> So, I am not so inclined to value the Insurgent test, or whatever it's
> called. It's fantastical in nature since such insurgents would not be
> restrained by copyright considerations, but by much more severe national
> law including consequences such as execution or imprisonment in the gulag.
>
>     Thanks
>
>     Bruce
>
>
> On Thu, Aug 22, 2019 at 10:19 AM VanL <van.lindberg at gmail.com> wrote:
>
>>
>>
>> On Thu, Aug 22, 2019 at 11:35 AM Thorsten Glaser <tg at mirbsd.de> wrote:
>>
>>>
>>> It might address the topic, but I have a really hard time wrapping
>>> my head around all the restrictions and terms used.
>>>
>>
>> You mention that it must be necessary for people to get the patch. That
>> is this part:
>>
>> > You may delay providing the Source Code corresponding to a particular
>> modification to the Work for up to ninety (90) days (the “Embargo Period”)
>> if...
>>
>> This is permissive. It does not *prevent* people from sharing the patch,
>> it just adjusts the timing. So there would be no problem with providing the
>> patch to a user, nor that user putting the patch into production during the
>> embargo period.
>>
>> Now, most of the language is about avoiding gaming of the provision:
>>
>> > a) the modification is intended to address a newly-identified
>> vulnerability or a security flaw in the Work,
>>
>> This must be a *new* security issue. You can't withhold non-sensitive
>> patches, and you can't withhold patches for old issues.
>>
>> > b) disclosure of the vulnerability or security flaw before the end of
>> the Embargo Period would put the data, identity, or autonomy of one or more
>> Recipients of the Work at significant risk,
>>
>> The security issue must be significant enough to put people at risk. Not
>> every patch, nor even every vulnerability, would suffice.
>>
>> > c) You are participating in a coordinated disclosure of the
>> vulnerability or security flaw with one or more additional Licensees, and
>>
>> The focus of this is allowing coordination of operator-users. It doesn't
>> allow unilateral withholding of the source by a single operator-user. If
>> there is only one operator user, they can just roll out the fix! No need to
>> coordinate.
>>
>> > d) the Source Code pertaining to the modification is provided to all
>> Recipients at the end of the Embargo Period.
>>
>> This doesn't change the requirement to provide source code, it just
>> temporarily modifies the timing.
>>
>> Thanks,
>> Van
>>
>>
>>
>> _______________________________________________
>> License-discuss mailing list
>> License-discuss at lists.opensource.org
>>
>> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>>
>
>
> --
> Bruce Perens - Partner, OSS.Capital.
> _______________________________________________
> License-discuss mailing list
> License-discuss at lists.opensource.org
>
> http://lists.opensource.org/mailman/listinfo/license-discuss_lists.opensource.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20190822/b7ae1b91/attachment.html>