On Wed, Jul 10, 2019 at 3:17 PM Nadim Kobeissi <nadim@symbolic.software> wrote:
> Many times in this discussion, we have all been offered a choice between > two paths. The first path would be to examine difficult problems and > shortcomings together and attempting to present incremental--often > onerous--improvements. The second path would be to just say that someone > should trust us based on years of subjective experience. In many, many > cases, the latter really is a wise thing to say and a correct thing to say > (and I truly mean this); it offers a path through which judicious decisions > are often made. Furthermore, it is often a necessary path to take when time > is of the essence. But it is seldom the rigorous path to take, seldom the > path that serves future engineers and practitioners in the field, and > seldom the path that gives institutions the foundation and the standing > that they will need in the decades to come. > Hi Nadim, There's a phrase to capture the essence of what you propose doing. It is that the perfect is the enemy of the good. Wikipedia even helpfully contains a useful quote in the context of Robert Watson-Watt. It is important that, while these flaws are recognized and being worked on, there is still a duty of care and community responsibility. There's clearly a school of thinking, which you appear to be advocating, that the best solution when something is less than perfect is to not do it at all, since doing nothing is the only 'fair' choice. Perhaps that's not your intent, but I want to highlight, you've repeatedly admonished the folks who have spent years into understanding and improving the ecosystem that they're not doing enough, or that it isn't rigorous enough. By way of analogy, which is admittedly a poor way to argue, it would be akin to someone arguing that out-of-band writes should not be fixed, because fixing OOB writes is not rigorous, and instead it should be rewritten in Rust. While it's certainly true that rewritting in Rust is likely to improve things, that's a bit of what we in the industry term a "long term" effort. In the mean time, as pragmatic professionals who care about security, long-term participants on this list are approaching both pragmatic and long-term solutions. There's not much I can say about the claimed lack of rigor. It appears that you were not familiar with long-standing policies or discussions, the means of approaching both the short-term risks and the long-term, the efforts to ensure consistency and reliability, and the acknowledged near-term gaps that necessitate a pragmatic approach. It's a bit like arguing that, since you have an OOB Write, the best path to take is to either do nothing to fix it, and in fact continue writing more code in unsafe languages, or do nothing until you replace it all. Neither, of course, are paths of rigor, and neither are paths that serve future engineers and practitioners in the field, nor do they give foundation and standing to the trust and safety of users. A different parallel to take would be that ignoring these well-known, well-documented limits to understanding would be a bit like ignoring the well-known, well-documented limits of JavaScript cryptography, and attempting to write a chat application in Javascript and promoting it for human rights or dissident safety. While it's certainly a path one could take, it's hardly a responsible one, just like it would be irresponsible to ignore both the limits of audits and the fundamental role in subjective, but thoughtful, evaluation of the risks comparative to the benefits. [1] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
