Date: Thu, 4 Jul 2019 00:06:10 -0400 From: grarpamp <grarpamp@gmail.com> To: freebsd-security@freebsd.org Cc: freebsd-questions@freebsd.org Subject: Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK} Message-ID: <CAD2Ti2-BEx78=pKN%2B7JyxSYWhyCOLYvsOCSu2zB_vXs=BBkUew@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti2-BEx78=pKN%2B7JyxSYWhyCOLYvsOCSu2zB_vXs=BBkUew>