<div dir="ltr"><div dir="ltr"><br></div><br><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">jfbastien@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div>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></div></div></div>
</div></blockquote><br></div><div>Here’s where we disagree: how to get from nothing being security to the right things being security.</div><div><br></div><div>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><br></div><div>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><br></div><div>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><br></div><div>What I want is for it to be clear that certain kinds of issues are currently explicitly out-of-scope. 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>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><br></div><div>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><br></div><div>It feels like you want the security team to be two different things:</div><div>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>2. A group of people working generally on defining or improving security properties of LLVM.</div><div><br></div><div>I don't think these two need or should be linked, though some of the same people might be involved in both.</div><div><br></div><div><br></div></div></div>