Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK}

[Peter Jeremy]

On 2019-Jul-04 00:06:10 -0400, grarpamp <grarpamp at gmail.com> wrote:
>Continued from beginnings in:
>https://lists.freebsd.org/pipermail/freebsd-security/2019-June/009996.html
>
>> I don't generally document a timeline of events from our side.
>
>There would be benefit to further transparency with
>some new data fields in FreeBSD advisories,
>leading to metrics analysis by userbase and project,
>appropriate resource allocation efficacies, etc.

Security Officer is a volunteer position and their time is valuable.
What benefits would be gained by requiring them to do more work to
provide information that is mostly already available elsewhere?

>Date_Discovered: Date of original discovery by discoverer.

This will be in the linked CVE.

>Date_Received: Date project received notification (or
>observed any info), regardless from external or internal source.

How/why is this relevant?  I agree that the project has been ignored
in some cases but that is generally discussed separately.

>Issue should also be posted heads up to lists at this Received
>time.

Definitely not.  Early advice of vulnerabilities is very much "need to know".
Unless someone's expertise is required to rectify the vulnerability, details
regarding the vulnerability should remain private.  The discoverers may
choose to publish early information, in which case, the Project may choose
to publicly reference that information.

>Also ends up being a bit more efficient as fewer cycles need spent
>on deciding and managing what to witholding timing sched contracts,
>under whatever questionable premises readily found searching
>net from thread above. To the extent any of this have possibly
>applied in the past.

Public announcement dates are generally not under Project control - where a
vulnerability affects multiple vendors, there is almost always general
agreement on a common announcement date.  If the Project leaks information
about unannounced vulnerabilities, it will stop receiving advance
information about vulnerabilities - this definitely will adversely impact
the Project.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-security/attachments/20190705/86c51922/attachment.sig>