On 01/05/15 at 04:23pm, Jiri Benc 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.
I agree and I would put the emphasize on the communication around the disclosure. Requiring GPG for all reports is pretty much pointless without a previous web of trust between the team and the reporter. We should however sign the messages when we disclose the vulnerability publicly. > > 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. +1 This is pointless in my eyes and doesn't add any real security. > > > 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. I think (3) is actually covered in the embargo process as nicely described by Ben already. I would agree to not change a thing in that regard. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
