[llvm-dev] [RFC] LLVM Security Group and Process

JF Bastien via llvm-dev llvm-dev at lists.llvm.org
Wed Dec 4 15:39:33 PST 2019



> On Dec 3, 2019, at 9:03 AM, James Y Knight <jyknight at google.com> wrote:
> 
> 
> 
> On Mon, Nov 25, 2019 at 5:38 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
> 
> 
>> On Nov 25, 2019, at 7:36 AM, James Y Knight <jyknight at google.com <mailto:jyknight at google.com>> wrote:
>> 
>> 
>> 
>> On Tue, Nov 19, 2019 at 10:46 AM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
>>> 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.
>> 
>> Here’s where we disagree: how to get from nothing being security to the right things being security.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
> 
> 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.
> 
> 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 else to the Security Group, as an organization, because it's unnecessary (despite that they would likely be entirely worthy of that trust).
>> What I want is for it to be clear that certain kinds of issues are currently explicitly out-of-scope.
> 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?
> 
> 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.
> 
> 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 must be hashed out in private by the Security Group in response to a concrete private vulnerability report.
> 
> 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.)

A separate discussion as you describe sounds good to me.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191204/a54024b8/attachment.html>


More information about the llvm-dev mailing list