
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 25, 2019, at 7:36 AM, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 19, 2019 at 10:46 AM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank" class="">jfbastien@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">And I do agree that if someone were to come in and put in the significant amounts of work to make LLVM directly usable in security-sensitive places, then we could support that. But none of that should have anything to do with the security group or its membership. All of that work and discussion, and the decision to support it in the end, should be done as a project-wide discussion and decision, just like anything else that's worked on.</div><div class=""></div></div></div>

</div></blockquote><br class=""></div><div class="">Here’s where we disagree: how to get from nothing being security to the right things being security.</div><div class=""><br class=""></div><div class="">I want to put that power in the hands of the security group, because they’d be the ones with experience handling security issues, defining security boundaries, fixing issues in those boundaries, etc. I’m worried that the community as a whole would legislate things as needing to be secure, without anyone in the security group able or willing to make it so. That’s an undesirable outcome because it sets them up for failure.</div><div class=""><br class=""></div><div class="">Of course neither of us is saying that the community should dictate to the security group, nor that the security group should dictate to the community. It should be a discussion. I agree with you that, in that transition period from no security to right security there might be cases where the security group disappoints the community, behind temporarily closed doors. There might be mistakes, an issue which should have been treated as security related won’t be. I would rather trust the security group, expect that it’ll do outreach when it feels unqualified to handle an issue, and fix any mistakes it makes if it happens. Doing so is better than where we are today.</div></div></blockquote><div class=""><br class=""></div><div class="">My worry is actually the inverse -- that there may be a tendency to treat more issues as "security" than should be. When some bug is reported via the security process, I suspect there will be a default-presumption towards using the security process to resolve it, with all the downsides that go along with that.</div></div></div></div></blockquote><div><br class=""></div><div>Agreed, that polarity is also a risk. I don’t see how to fix this issue either, except to trust the security group. Its members will be more competent at doing the right thing than the general LLVM community because they’ve dealt with this stuff before.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">What I want is for it to be clear that certain kinds of issues are currently explicitly out-of-scope.</div></div></div></div></blockquote><div><br class=""></div><div>Yes I want this list, but I don’t think we need it now. Once we’ve got a group of experts looking at security issues they can incrementally figure out that list. Do you think that’s acceptable?</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class="">E.g. crashes/code-execution/etc resulting from parsing or compiling untrusted C source-code with Clang, or parsing/compiling untrusted bitcode with LLVM, or linking untrusted files with LLD. These sorts of things should not, currently, be treated with a "security" mindset. They're <i class="">bugs</i>, which should be fixed, but if something's security depends on llvm being able to securely process untrusted inputs, sorry, that's not reasonable. (And yes, that's maybe sad, but is the reality right now). Until someone is willing to put in the significant effort to make those processes generally secure for use on untrusted inputs, handling individual bug-reports of this kind via a special process is not going to realistically improve security.</div><div class=""><br class=""></div><div class="">Furthermore, if people disagree with the above paragraph, I'd like that discussion to be had in the open ahead of time, rather than in private after the first time such an issue is reported via a defined security process.</div><div class=""><br class=""></div><div class="">It feels like you want the security team to be two different things:</div><div class="">1. A way to privately report security issues to LLVM, and a group of people to privately work on fixing such issues, for a coordinated release.</div><div class="">2. A group of people working generally on defining or improving security properties of LLVM.</div><div class=""><br class=""></div><div class="">I don't think these two need or should be linked, though some of the same people might be involved in both.</div></div></div></div></blockquote><br class=""></div><div>I don’t want 1 and 2 linked, though as you say it can be the same group. I’m saying that 2 should inform 1, they don’t exist in a vacuum.</div><div><br class=""></div></body></html>