On Mon, Jan 5, 2015 at 9:23 AM, Jiri Benc <jb...@redhat.com> wrote: > On Fri, 2 Jan 2015 17:57:14 -0800, Ben Pfaff wrote: > > 1) Consider provisions for ensuring privacy and integrity of > > communications around disclosure (eg, use PGP for all comms). > > That never hurts. I'd argue that's not strictly required though, as the > code speaks for itself and anybody can verify the patch does what it > does and the reasoning is correct. > > > 2) Consider provisions for handling the vuln info to prevent it from > > being leaked / stolen from developers (this info can often be worth a > > lot of money to certain parties with a lot of interest and > motivation to > > get hold of them). This means keeping info in some sort of secured > > enclaves, and perhaps mixing patch code with other commits to > obfuscate > > the presence of the flaw. > > I strongly disagree with that. Distributions need to be able to cherry > pick the security fixes, any kind of obfuscation and mixing commits for > different things makes the life of distro maintainers harder, leading > to more mistakes, thus less security for those who use ovs via a > distro. Such thing would not improve security of the ovs project anyway > --the yet undiscovered bugs do not have a patch to obfuscate, and > discovered and patched bugs are, well, patched. Anybody running on the > latest code base has the fix applied; for backports, a clear patch to > backport is needed. > > > Parts of OVS are in kernel space, making it a > > quite an “interesting” target, so I wouldn’t take this one lightly. > > The kernel patches will need to go through the kernel security > reporting process: > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs > > Which is maybe a good idea to include in the documentation? > > ++
I think including a link to the kernel security reporting process is necessary here. > > 3) Consider revising patch release process to ensure patched code > > reaches deployments without disclosing the vulnerability; and release > > the vuln info after allowing sufficient time for fixed code to > percolate > > into running environments. Currently proposed process does not > appear to > > allow for this. > > It does, through the embargoed disclosure. Committing the patch without > sending it to ovs-dev list and releasing the disclosure only later does > not make sense. It would draw the attention to the fix anyway. And > sending it for review to ovs-dev without telling what the patch fixes > won't work, either. > > Overall, these suggestions seem to be from somebody who's not familiar > with how open source development works. > > Jiri > > -- > Jiri Benc > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
