Lines Matching full:group

2 LLVM Security Response Group
5 The LLVM Security Response Group has the following goals:
15 The LLVM Security Response Group is private. It is composed of trusted LLVM contributors. Its discussions remain within the LLVM Security Response Group (plus issue reporter and key experts) while an issue is being investigated. After an issue becomes public, the entirety of the group’s discussions pertaining to that issue also become public.
24 We aim to acknowledge your report within two business days since you first reach out. If you do not receive any response by then, you can escalate by posting on the `Discourse forums`_ asking to get in touch with someone from the LLVM Security Response Group. **The escalation mailing list is public**: avoid discussing or mentioning the specific issue when posting on it.
27 Group Composition
30 Security Response Group Members
33 The members of the group represent a wide cross-section of the community, and
64 * Nominees for LLVM Security Response Group membership should fall in one of these groups:
82 * Additionally, the following are necessary but not sufficient criteria for membership in the LLVM Security Response Group:
84   - If already in the LLVM Security Response Group, has actively participated in one (if any) security issue in the last year.
85   - If already in the LLVM Security Response Group, has actively participated in most membership discussions in the last year.
86   - If already in the LLVM Security Response Group, has actively participated in writing or reviewing a transparency report in the last year.
87   - When employed by a company or other entity, the parent entity has no more than three members already in the LLVM Security Response Group.
89   - Nominees are trusted by existing LLVM Security Response Group members to keep communications embargoed while still active.
94 Anyone who feels they meet these criteria can nominate themselves, or may be nominated by a third party such as an existing LLVM Security Response Group member. The nomination should state whether the nominee is nominated as an individual, researcher, or as a vendor contact. It should clearly describe the grounds for nomination.
96 For the moment, nominations are generally proposed, discussed, and voted on using a github pull request. An `example nomination is available here`_. The use of pull requests helps keep membership discussions open, transparent, and easily accessible to LLVM developers in many ways. If, for any reason, a fully-world-readable nomination seems inappropriate, you may reach out to the LLVM Security Response Group via the `report a vulnerability`_ route, and a discussion can be had about the best way to approach nomination, given the constraints that individuals are under.
101 If a nomination for LLVM Security Response Group membership is supported by a majority of existing LLVM Security Response Group members, then it carries within five business days unless an existing member of the Security Response Group objects. If an objection is raised, the LLVM Security Response Group members should discuss the matter and try to come to consensus; failing this, the nomination will succeed only by a two-thirds supermajority vote of the LLVM Security Response Group.
106 Before new LLVM Security Response Group membership is finalized, the successful nominee should accept membership and agree to abide by this security policy, particularly `Privileges and Responsibilities of LLVM Security Response Group Members`_ below.
111 * At least every six months, the LLVM Security Response Group applies the above criteria. The membership list is pruned accordingly.
112 * Any LLVM Security Response Group member can ask that the criteria be applied within the next five business days.
113 * If a member of the LLVM Security Response Group does not act in accordance with the letter and spirit of this policy, then their LLVM Security Response Group membership can be revoked by a majority vote of the members, not including the person under consideration for revocation. After a member calls for a revocation vote, voting will be open for five business days.
114 * Emergency suspension: an LLVM Security Response Group member who blatantly disregards the LLVM Security Policy may have their membership temporarily suspended on the request of any two members. In such a case, the requesting members should notify the LLVM Security Response Group with a description of the offense. At this point, membership will be temporarily suspended for five business days, pending outcome of the vote for permanent revocation.
115 * The LLVM Board may remove any member from the LLVM Security Response Group.
120 Every year, the LLVM Security Response Group must publish a transparency report. The intent of this report is to keep the community informed by summarizing the disclosures that have been made public in the last year. It shall contain a list of all public disclosures, as well as statistics on time to fix issues, length of embargo periods, and so on.
125 Privileges and Responsibilities of LLVM Security Response Group Members
131 LLVM Security Response Group members will be subscribed to a private `Discussion Medium`_. It will be used for technical discussions of security issues, as well as process discussions about matters such as disclosure timelines and group membership. Members have access to all security issues.
136 Members of the LLVM Security Response Group will be expected to treat LLVM security issue information shared with the group as confidential until publicly disclosed:
139 * If the LLVM Security Response Group agrees, designated members may share issues with vendors of non-LLVM based products if their product suffers from the same issue. The non-LLVM vendor should be asked to respect the issue’s embargo date, and to not share the information beyond the need-to-know people within their organization.
140 * If the LLVM Security Response Group agrees, key experts can be brought in to help address particular issues. The key expert should be asked to respect the issue’s embargo date, and to not share the information.
145 Following the process below, the LLVM Security Response 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.
150 Members of the LLVM Security Response Group are expected to:
162 The medium used to host LLVM Security Response Group discussions is security-sensitive. It should therefore run on infrastructure which can meet our security expectations.
169 We also occasionally need to discuss logistics of the LLVM Security Response Group itself:
183 * Within two business days, a member of the LLVM Security Response 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.
184 * Members of the LLVM Security Response Group discuss in which circumstances (if any) an issue is relevant to security, and determine if it is a security issue.
186 * LLVM Security Response Group members can recommend that key experts be pulled in to specific issue discussions. The key expert can be pulled in unless there are objections from other LLVM Security Response Group members.
188 * Backporting security patches from recent versions to old versions cannot always work. It is up to the LLVM Security Response Group to decide if such backporting should be done, and how far back.
189 * The LLVM Security Response Group figures out how the LLVM project’s own releases, as well as individual vendors’ releases, can be timed to patch the issue simultaneously.
190 * Embargo date can be delayed or pulled forward at the LLVM Security Response Group’s discretion.
199 The LLVM Security Policy may be changed by majority vote of the LLVM Security Response Group. Such changes also need to be approved by the LLVM Board.
219 properties over time. In all cases the LLVM Security Response Group should be consulted,
224 not, err towards assuming that it is. The Security Response Group might agree or disagree
232   issues to the LLVM Security Response Group that you believe are security-sensitive.