Date: Fri, 5 Jul 2019 16:06:52 +1000 From: Peter Jeremy <peter@rulingia.com> To: grarpamp <grarpamp@gmail.com> Cc: freebsd-security@freebsd.org, freebsd-questions@freebsd.org Subject: Re: Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK} Message-ID: <20190705060652.GA2974@server.rulingia.com> In-Reply-To: <CAD2Ti2-BEx78=pKN%2B7JyxSYWhyCOLYvsOCSu2zB_vXs=BBkUew@mail.gmail.com> References: <CAD2Ti2-BEx78=pKN%2B7JyxSYWhyCOLYvsOCSu2zB_vXs=BBkUew@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-Jul-04 00:06:10 -0400, grarpamp <grarpamp@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. --=20 Peter Jeremy --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAl0e6PRfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzTGIBAAhGVuXkwZBmyot3uql88LVElS8HTNzNFWnSxJZmWTposSVjrer4W2nWlK 5lXb1y82Yccuq57BOrSxFLPzBh58/IuaedxB0tG6NhpDT6T3jYLJYfdi7993uJ/x eRs90GswHybFHSjC5YtFYw5ZP8+mro1LBw1gGZbD71ZNx93BCSWHjIuQLHECmWgo 3g5wCwnoj3dZxojECjzrPChDm/uEWysEQphH8pLNWtqcYgfx3m5LAu3jpsJHDDYn AONh3TAtb/5xVA00SAmiu1GqdCo/94nTuvcyMQgPxycWRRpNEHQ7x6e3pLLJk5lm jmt6bxqWmYzLBR9oeNFlD8lTld9J35SCB/X9pSK6PigQDXe2gpOED3wzSvP4/E8W xFzuqJFUmNn7dCyUT8Z4SuNp8bS7i3m8rvZCJNR98K2uQFuVSWE3L+e1JjtoTVde SitC0I9MZKe/ZbHoTJtcku+FSuL+ivyW185NRHPVTf7gKjJb2f2jVwvzpHPXAwN3 2o1JB8FuPIZ1X4gBUg1LK9mJgnN035wkJypGM/tYpjgqhyHcUm8VcllSYfBUiKZi b67N2IGPtS8Cv79MayQd6rpDTpVXppN85Q2r0PW7kssXhdKC7pgfLzl+f7huSHUz 6CEJE2QP/xa8oBABn2/HR7ZKqMY327fSR7M+fvjwWrGuq5mWORU= =mjnj -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190705060652.GA2974>