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? > 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
