| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
When we recently ran a genuine vulnerability through this process, we
discovered that 3-5 days was far too short. The business processes behind
releasing fixed versions of software at companies that use Open vSwitch
cannot cope with such rapid turnaround, due e.g. to QA and other processes.
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Acked-by: Flavio Leitner <fbl@redhat.com>
|
| |
|
|
|
|
| |
Signed-off-by: Ben Pfaff <blp@ovn.org>
Acked-by: Ryan Moats <rmoats@us.ibm.com>
Acked-by: Justin Pettit <jpettit@ovn.org>
|
| |
|
|
|
|
|
|
|
| |
Add bit about reporting vulns with GPG.
Add generalised rules for vulnerabilties.
Signed-off-by: Andrew Kampjes <a.kampjes@gmail.com>
[blp@nicira.com edited and removed text about not using public lists]
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
The release cycle is in order of months currently, so when a
security fix is applied to LTS (long-term support) branches,
it is recommended to release a new version.
The idea is to keep the latest LTS tarball less vulnerable.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
|
| |
Stakeholders might need extra time to provide the update,
so let's leave it open to negotiate case by case with the
final word on the Open vSwitch security team's hands. A
default policy is provided as a reference.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
| |
|
|
|
|
|
|
|
| |
There is no point in having the special process if a
contributor refuses or doesn't agree with the
confidentiality terms.
Signed-off-by: Flavio Leitner <fbl@redhat.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
|
|
|
Open vSwitch needs some kind of process for handling vulnerabilities. So
far, we've been pretty lucky that way, but it can't last forever, and I
think we'll be better off if we have at least the outline of an established
process whenever a significant vulnerability comes along. Here's my draft
of a process based on the documentation of the OpenStack process at
https://wiki.openstack.org/wiki/Vulnerability_Management.
I don't have a lot of experience with this kind of thing myself, so I'd
appreciate critical review from anyone who does.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Reviewed-by: Flavio Leitner <fbl@redhat.com>
Acked-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Thomas Graf <tgraf@noironetworks.com>
|
