<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 Dec 3, 2019, at 9:03 AM, James Y Knight <<a href="mailto:jyknight@google.com" class="">jyknight@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><br class="Apple-interchange-newline"><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div dir="ltr" class="gmail_attr">On Mon, Nov 25, 2019 at 5:38 PM JF Bastien <<a href="mailto:jfbastien@apple.com" class="">jfbastien@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><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" target="_blank" class="">jyknight@google.com</a>> wrote:</div><br class=""><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-width: 1px; border-left-style: solid; border-left-color: 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 class=""><br class=""></div><div class="">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></div></blockquote><div class=""><br class=""></div><div class="">Again, I find it entirely reasonable to place trust in a small subset of the members of the LLVM community to do the right thing in response to security issues which must remain temporarily secret. It's infeasible to allow the entire community to participate. I just don't want to entrust anything<span class="Apple-converted-space"> </span><i class="">else</i><span class="Apple-converted-space"> </span>to the Security Group, as an organization, because it's unnecessary (despite that they would likely be entirely worthy of that trust).</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="overflow-wrap: break-word;" class=""><div 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 class="">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></div></blockquote><div class=""><br class=""></div><div class="">We know now, even before any issues have been reported through this process, what some of the areas of concern are going to be. Some have been mentioned before on this thread, and others likely have not. I would like to see it explicitly called out, up front, how we expect to treat certain issues without waiting for them to be reported.</div><div class=""><br class=""></div><div class="">Why do I want that? Because I want the security group's mission statement and mandate from the community to be clear. If there's disagreement about which sorts of things should or should not be treated as security issues (which I suspect there may well be), I'd like that to be hashed out in the open now, rather than delaying any such debate until such a time as it<span class="Apple-converted-space"> </span><i class="">must</i><span class="Apple-converted-space"> </span>be hashed out in private by the Security Group in response to a concrete private vulnerability report.</div><div class=""><br class=""></div><div class="">However, I agree it's not necessary for you to define this immediately. If you'd like to attempt to find other volunteers to author those policies, rather than doing it yourself, I see absolutely no problem with that. But I would still like to see such a document get proposed and reviewed via the project's usual open discussion forum (mailing lists, code reviews on new policy docs, etc), as soon as possible, in order to reduce surprises as much as possible. (Recognizing that it cannot and should not attempt to cover every eventuality.)</div></div></div></blockquote></div><br class=""><div class="">A separate discussion as you describe sounds good to me.</div><div class=""><br class=""></div></body></html>