I don't know what to say for response time. In general I expect it to be pretty fast for anything that is clearly urgent.
On Fri, Jan 09, 2015 at 09:48:11AM +1300, Andrew Kampjes wrote: > Both good points, thanks Flavio. > Ben, can you confirm what the expectation for response should be? > > Will swap those paragraphs too. > > On 9 January 2015 at 05:11, Flavio Leitner <f...@redhat.com> wrote: > > > On Thursday, January 08, 2015 11:14:40 AM Andrew Kampjes wrote: > > > Include more specific GPG recomendation usage. > > > Add generalised rules for vulnerabilties. > > > > > > Signed-off-by: Andrew Kampjes <a.kamp...@gmail.com> > > > --- > > > SECURITY.md | 41 +++++++++++++++++++++++++++++------------ > > > 1 file changed, 29 insertions(+), 12 deletions(-) > > > > > > diff --git a/SECURITY.md b/SECURITY.md > > > index d558d44..c85e594 100644 > > > --- a/SECURITY.md > > > +++ b/SECURITY.md > > > @@ -23,25 +23,33 @@ What is a vulnerability? > > > ------------------------ > > > > > > All vulnerabilities are bugs, but not every bug is a vulnerability. > > > +Vulnerabilites compromise one or more of: > > > + > > > + * Confidentiality (Personal and company data/secrets). > > > + * Integrity (trustworthyness and correctness). > > > + * Availability (Uptime and service). > > > + > > > Here are some examples of vulnerabilities to which one would expect to > > > apply this process: > > > > > > - * A crafted packet that causes a kernel or userspace crash. > > > + * A crafted packet that causes a kernel or userspace crash > > > + (Availability). > > > > > > * A flow translation bug that misforwards traffic in a way likely > > > - to hop over security boundaries. > > > + to hop over security boundaries (Integrity). > > > > > > * An OpenFlow protocol bug that allows a controller to read > > > - arbitrary files from the file system. > > > + arbitrary files from the file system (Confidentiality). > > > > > > * Misuse of the OpenSSL library that allows bypassing certificate > > > - checks. > > > + checks (Integrity). > > > > > > * A bug (memory corruption, overflow, ...) that allows one to > > > modify the behaviour of OVS through external configuration > > > - interfaces such as OVSDB. > > > + interfaces such as OVSDB (Integrity). > > > > > > - * Privileged information is exposed to unprivileged users. > > > + * Privileged information is exposed to unprivileged users > > > + (Confidentiality). > > > > > > If in doubt, please do use the vulnerability management process. At > > > worst, the response will be to report the bug through the usual > > > @@ -53,8 +61,17 @@ Step 1: Reception > > > > > > To report an Open vSwitch vulnerability, send an email to the > > > ovs-security mailing list (see "Contact" at the end of this document). > > > -A security team member should reply to the reporter acknowledging that > > > -the report has been received. > > > +A security team member should reply to the reporter within 24 hours > > > +acknowledging that the report has been received. > > > > There is no on-call team as far as know. Perhaps Ben can confirm that. > > So issues reported during holidays or weekends may take more than > > 24 hours to get a reply. My concern here is that it will create a non > > practical expectation. > > > > Perhaps something like this: > > A security team member should reply to the reporter within 24 hours > > on business days acknowledging that the report has been received. > > > > > +Reporters may ask for a GPG key while initiating contact with the > > > +security team to deliver more sensitive reports. > > > +If the reporter has used GPG while disclosing, further vulnerability > > > +details should also be discussed using GPG. > > > + > > > +Please don't report security vulnerabilities to the ovs-dev list, > > > +ovs-bug list or github issues to allow the team ovs security team > > > +to responsibly fix the vulnerability. > > > > It looks more clear/effective to me if we swap the two > > paragraphs. I mean, first tell to not report on ovs-dev and > > then talk about GPG details... > > > > fbl > > > > > Please consider reporting the information mentioned in > > > REPORTING-BUGS.md, where relevant. > > > @@ -132,11 +149,11 @@ vSwitch user who is interested and can be > > considered trustworthy > > > enough could be included. To become a downstream stakeholder, email > > > the ovs-security mailing list. > > > > > > -If the vulnerability is public, skip this step. > > > +If the vulnerability is already public, skip this step. > > > > > > > > > -Step 5: Full Disclosure > > > ------------------------ > > > +Step 5: Public Disclosure > > > +------------------------- > > > > > > When the embargo expires, push the (reviewed) patches to appropriate > > > branches, post the patches to the ovs-dev mailing list (noting that > > > @@ -151,7 +168,7 @@ The security advisory should be GPG-signed by a > > security team member > > > with a key that is in a public web of trust. > > > > > > > > > -Contact > > > +Contact > > > ======= > > > > > > Report security vulnerabilities to the ovs-security mailing list: > > > > > > > > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
