freebsd security - Jul 2019 - Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK}

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.

Date_Discovered: Date of original discovery by discoverer.

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

Issue should also be posted heads up to lists at this Received
time. For apprise those users wishing or needing to performing
necessary local review and action prior to formal fix from
FreeBSD upstream. And for putting out to community the
call to fix.

Date_Advisory: Already present as "Announced:" fix.


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.

Heads Up on receipt, and include targeted fix timeframe guideline
for readers based on expected class of fix difficulty selected from
prior convened and published policy guide table of difficulties and
dependencies.

Heads Up and interim are naturally not expected to be
a polished Advisory.

> This
> particular disclosure was a bit unusual as it wasn't external but
> instead was an internal FreeBSD developer the security team often works
> with.
Seems this SACK Discovery was came from Netflix while in
that external dev role, not from in purely internal to FreeBSD
dev role. And Received was from not Netflix official team role,
but by this liason.

Fine and moot though, as datestream handling above should
apply to all cases.
> As such, our process was a bit out of sync with normal (as much as
> we have a normal with our current processes). All of that said, we got
> notice in early June, about 10 days before public disclosure.
Community can ascertain visit any needs adjustments
therein with by inclusion of dates and passthrough above.
>> Were any FreeBSD derivatives given advanced notice? If so, which ones?
>
> They were not. I would like to get to a point where we feel we could
> give some sort of heads up for downstream, but we aren't there yet.
Whether push, or pull via subscribe, derivative third parties
are a bit secondary to the closer FreeBSD community
processes.

ie: Does Linux Kernel push to all 1000 linux distro teams?
Probably not, a bit out of scope, so they pull (distro being the
derivative depend of kernel there).

Again mooted simplicity with better date and passthrough above.

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>