[PATCH] D70326: [docs] LLVM Security Group and Process

Fri Jul 10 11:24:34 PDT 2020

jfb added inline comments.

================
Comment at: llvm/docs/Security.rst:25
+
+The initial security group will start small and grow following the process established below. The LLVM Board will pick 10 community members. These members shall represent a wide cross-section of the community, and meet the criteria for inclusion below.
+
----------------
rengolin wrote:
> aadg wrote:
> > I understand we have to solve a chicken & egg problem here to get the group started ; I think we should rather say that a call for application to the initial security group should be made, and the board will pick 10 candidates amongst the applications. The board can not possibly know everyone in the community, and to be effective, this group needs volunteers, not people who have been volunteered.
> > 
> > 10 seems like a big number of people for an initial group --- given the number of people who expressed interest in the forming of this group, so what should we do if there are less than 10 volunteers ?
> > 
> > The initial task for this group will probably be to finish fleshing up this proposal.
> I agree on both points. We shouldn't burden the foundation with it nor we should restrict the number of members to a fixed size.
The board's expressed preferred direction is to start with those who have self-identified in the RFC discussion. I'll go with that.

================
Comment at: llvm/docs/Security.rst:46
+
+  - Vendor contacts:
+
----------------
theraven wrote:
> psmith wrote:
> > There are many vendors that build products from LLVM, and would like to be informed about vulnerabilities, but they may not be able to provide a security expert for the group. We may be at risk of putting off smaller vendors from putting names forward that largely want to be informed but may not be able to contribute fixes.
> > 
> > I don't think this needs changing in the text though. We'll have to see how it goes.
> I think that's a great point.  We may want to have a two-ring approach, with a group that will coordinate the response and patch, and a wider distribution group that has access to the embargoed patch so that they can do package builds and coordinated releases.  My concern over this approach is that it's much lower overhead to be in the second group and so the incentive is to only be in the second group, where you benefit from the process but don't contribute.  
> 
> This also needs to be balanced with the fact that a leak of an embargoed patch is more likely the more people are exposed to it (for example, OpenBSD leaked the fix for the KRACK WPA2 attack before the embargo, which put everyone else at risk and got the project banned from access to embargoed fixes for a few things).  
> 
> From the project's perspective, what is the benefit of having these small vendors participating?  For the vendor to benefit, they must have a process for handling embargoed fixes and doing coordinated releases.  It seems quite unlikely that such a vendor would not have someone who can help our at least in coordinating the response, if not in assessing the security. 
Agreed that this is a valid concern. I would like to figure it out as we move forward, not in the first steps of setting up our process.

================
Comment at: llvm/docs/Security.rst:52
+
+  - If already in the LLVM Security Group, has actively participated in one (if any) security issue in the last year.
+  - If already in the LLVM Security Group, has actively participated in most membership discussions in the last year.
----------------
rengolin wrote:
> Redundant wording. Perhaps sub-bullet points?
Using sub-bullets makes it unclear what is "and" and what isn't.

================
Comment at: llvm/docs/Security.rst:112
+
+Following the process below, the LLVM Security Group decides on embargo date for public disclosure for each Security issue. An embargo may be lifted before the agreed-upon date if all vendors planning to ship a fix have already done so, and if the reporter does not object.
+
----------------
rengolin wrote:
> What if the group doesn't have a member from an affected vendor? How do we handle external vendor/country embargo?
It won't be perfect at the start, but it's already way more imperfect right now. We should do outreach (such as on this review and the RFC), and over the first few months I think we'll be in a position where what you ask isn't an issue anymore.

================
Comment at: llvm/docs/Security.rst:153
+* Within two business days, a member of the Security Group is put in charge of driving the issue to an acceptable resolution. This champion doesn’t need to be the same person for each issue. This person can self-nominate.
+* Members of the Security Group discuss in which circumstances (if any) an issue is relevant to security, and determine if it is a security issue.
+* Negotiate an embargo date for public disclosure, with a default minimum time limit of ninety days.
----------------
psmith wrote:
> Is it worth documenting what happens when the decision that the issue is not security-related? For example update "What is a security issue?" if necessary.
> 
> We have time limits and a place for communicating fixes. How and where do we communicate a non-security issue? For example is there a LLVM-DEV post?
> 
> I'm sure that there will be some decisions that will need revisiting due to community feedback or further information. I don't think that there needs to be a formal appeals procedure, I think that if the arguments are persuasive the committee can change their mind.
An issue that isn't deemed part of the security surface area is opened to the public as part of the embargo. In most cases, we'd decide that there's no embargo.

That being said, we can keep an embargo if, for example, it's not part of LLVM's security surface area but is for some non-LLVM project. Say: we use a 3rd party library in a non-secure manner, we're told of an issue, we say "not in out threat model", but other open-source projects have it in their thread model. In such a case we don't want to lift embargo, because it would affect the non-LLVM project.

Ultimately, we'll also do a periodic report where those issues show up.

================
Comment at: llvm/docs/Security.rst:180
+.. _CVE process: https://cve.mitre.org
+.. _chromium issue tracker: https://crbug.com
+.. _GitHub security: https://help.github.com/en/articles/about-maintainer-security-advisories
----------------
kcc wrote:
> crbug.org has been working well for us e.g. for oss-fuzz or for one-off cases like 
> https://bugs.chromium.org/p/chromium/issues/detail?id=994957
> https://bugs.chromium.org/p/chromium/issues/detail?id=606626
> 
> GitHub's security advisories are very recent and unclear if the workflow is polished. 
> E.g. I can't seem to add comments to the advisory once it's public. 
> I didn't check if these advisories have an API (they should). 
> 
> Yet, I think we should consider GitHub as the primary candidate because this is where LLVM is and where the majority of OSS people are. 
> We may need to ask GitHub to implement missing features, if any. 
That's been my thinking as well, and one of the first follow-ups I'd like to come after this initial commit.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D70326/new/

https://reviews.llvm.org/D70326