Date: Fri, 5 Jul 2019 17:24:23 -0400 From: grarpamp <grarpamp@gmail.com> To: freebsd-security@freebsd.org Cc: freebsd-questions@freebsd.org Subject: Re: Review of FreeBSD Security Advisory Process: Incl Heads Up, Dates, Etc [cont: 5599 SACK} Message-ID: <CAD2Ti2806NVdod%2B-efsAOrJPRi5W6sCxeC2Hd745suOj1=H4Hw@mail.gmail.com> In-Reply-To: <20190705060652.GA2974@server.rulingia.com> References: <CAD2Ti2-BEx78=pKN%2B7JyxSYWhyCOLYvsOCSu2zB_vXs=BBkUew@mail.gmail.com> <20190705060652.GA2974@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7/5/19, Peter Jeremy <peter@rulingia.com> wrote: > 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.htm= l > What benefits would be gained by Some have been, and more can be by others, outlined in the ongoing threads. > Security Officer is a volunteer position and their time is valuable. > requiring them to do more work to provide information Date_Received adding is not "more work" in any real sense. FreeBSD Project knows when it becomes aware of an issue, readily available in the very same email headers, forum post headers, etc... a minute's cut and paste into an Advisory. That's an easy first step. > that is mostly already available elsewhere? In the Subject example, and many others, no. Discovered and Received dates are often not given. >>Date_Discovered: Date of original discovery by discoverer. > This will be in the linked CVE. It is not present in the current CVE or Netflix or FreeBSD infosheets. If some external discoverer wants to play silly and coy with that Date_Discovered info, fine. However once Date_Received occurs as above, FreeBSD project should be denoting its Date_Received. >>Date_Received: Date project received notification (or >>observed any info), regardless from external or internal source. > > How/why is this relevant? Already explained... it is critical datapoint for user base to review evaluate community allocation of resources to appropriate levels of security response. They might choose months, weeks, days. But without Date_Received, everyone is left in dark, and allocations potentially not wherever they should be to meet general needs. > I agree that the project has been ignored > in some cases but that is generally discussed separately. FreeBSD ignored by external fake security purveyors? If that is the meaning, that would be a good thing, hopefully due to FreeBSD doing things toward real security that counter that. >>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". Utterly False. If you are the owner... user, admin, entity or even customer with data or services running on... a vulnerable system, it is absolutely without question your need to know. Further, if FreeBSD is not posting a heads up upon its Date_Received of what it knows so far, it is putting itself in very questionable position of claiming to knowing best for all when in fact it does not even know for one, instead of rightly setting those decisions off to systems owners as best suits their own needs via heads up post. > Unless someone's expertise is required to rectify the vulnerability, > details regarding the vulnerability should remain private. What external does is up to them. Yet as herein, once it hits FreeBSD's doorstep, FreeBSD's responsibility is to users first and foremost to point of exclusivly. > The discoverers may > choose to publish early information As above, that's upon them and their cred game. Not forgetting that those discoverers that withold often get caught and look silly. > in which case, the Project may choose > to publicly reference that information. If FreeBSD is independant, it can refer and publish whatever it knows, when it knows it. If it is not, then those aspects of FreeBSD need very serious opening up to sunlight and review by the entire community. Same if FreeBSD were subject to "Donation Capture", that would need reviewed extremely closely. > 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. This is a game, a fake news show meant to make the interviewees look good, typically monied vendors of closed proprietary garbage smelly swiss cheese product, everyone knows it, so just stop. > If the Project leaks information > about unannounced vulnerabilities, it will stop receiving advance > information about vulnerabilities - this definitely will adversely impact > the Project. If FreeBSD is or wants to playing the [vendor] game, wants to become a closed system, subject to such others, etc... it will never be known for pushing the much needed opensource HW and SW philosophy envelope any further ahead into the light through its openness action or even activism. There are enough closed models out there already. Don't let those closed actors fool and play you into their dark traps. FreeBSD hopefully is, and must be, better than that. Here's another example of secrecy serving no one other than dark forces (in this case, literally TLA's and nefarious actors around the world against owners users customers)... https://zerodium.com/program.html FreeBSD LPE is only worth $50,000, that's less than Windows. One can of course discuss in a separate thread the LoC vs Funds vs Usercount vs Fruits of Vuln therein. The the question of what great results from if FreeBSD community and or foundation funds just one fulltime dedicated security reviewer at $50k/yr... and how that news and results might generate more donations in turn... >> Does FreeBSD publish its vulnerability response process documentation? >> If not, would FreeBSD be open to such transparency? > You=E2=80=99re asking volunteers, performing a very time-consuming task, = to do even more work. That would be another great first step. And it's easily done and opened to entire community contribution via the Wiki, such that works doesn't have to come down to just N existing volunteers. Part of doing things such as these in the open, a wiki list of oppurtunitie= s, processes, etc is that it allows you to call for participants, new volunteers, people can drop by and see what interests them, can evaluate if they would like to add resources to gain from that investment [in their own system] in turn, etc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAD2Ti2806NVdod%2B-efsAOrJPRi5W6sCxeC2Hd745suOj1=H4Hw>