[docs] Describe reporting security issues on the chromium tracker.

[ab]

Summary

Hey folks! While checking today's agenda I noticed this task slipped through the cracks from our discussion at the last sync, my bad!

To track security issues, we're starting with the chromium bug tracker
(using the llvm project there). We would prefer to use Github to match
its increasing usage for llvm. However, Github Security Advisories are
currently intended as a way for project owners to publicize their
security advisories, and isn't well-suited to reporting issues.
We may still want to have a more complicated process where we track
issues on the chromium tracker, and publicize them to the community
on Github.
Or, alternatively, tell people to reach out to us (without getting into
details) to file a security issue for them on Github directly, and give
them access to actually discuss the issue there.

This also moves the issue-reporting paragraph to the beginning of the
document, in part to make it more discoverable, in part to allow the
anchor-linking to actually display the paragraph at the top of the page.

Note that this doesn't update the concrete list of security-sensitive
areas, which is still an open item we may want to address before
actually landing this issue-reporting doc change.

We may want to move the list of security-sensitive areas next to the
issue-reporting paragraph as well, as it seems like relevant information
needed in the reporting process.

Finally, when describing the discission medium, this splits the topics
discussed into two: the concrete security issues, discussed in the
issue tracker, and the internal logistics, in our mailing list.
We may want to relax the nomination process to match our current usage
of patches vs the mailing list.

While there, add a SECURITY.md page linking to the relevant paragraph.

[kristof.beyls]

Thanks for this Ahmed!
This mostly looks good to me, I just have a few nit-comments inline.

llvm/docs/Security.rst

165

Is my understanding correct that github's security workflow work:

• Does not easily enable reporting security issues? (That seems to be what https://opensource.stackexchange.com/questions/1958/report-a-security-issue-to-a-project-hosted-at-github confirms)
• Does enable publicly disclosing resolved security issues and automatically notifying other projects on github that have a dependency?

If so, maybe this sentence of paragraph could be made a bit more clear, stating that currently github doesn't support easily reporting a security issue non-publicly, and therefore we're using an alternative that does enable that, i.e. the chromium issue tracker?
The note about considering public disclosure using Github Security Advisories as a future improvement still makes sense to me.

168–172

I think that the LLVM security group discuss a lot of this publicly, as patch proposals to this document, or on the monthly public sync-up call.

Maybe it'd be a slightly more accurate reflection of reality to tweak the wording to:
"The LLVM security gorup also uses a private mailing list to discuss *confidential aspects* of LLVM security group logistics"?

[peter.smith]

Thanks for making the changes. I don't have anything to add over Kristof's comments.

[george.burgess.iv]

Thanks for this!

llvm/docs/Security.rst

168–172

+1. Would it also be worth it to briefly reference the public sync-up call with a link to more info? (I wasn't aware of it, at least :) )

In addition to our `monthly public sync-up call`_ and discussions on public LLVM mailing lists, we use a private mailing list to discuss [...]

[ab]

• mention public discussions on lists/in sync-up, link to sync-up page
• describe Github workflow as potentially useful for publicly disclosing resolved issues

[ab]

Thanks for the comments! Tweaks inline

llvm/docs/Security.rst

165

Yep, makes sense! I tried rewriting the paragraph from that angle

168–172

Yep, both suggestions make sense to me: I mentioned these, emphasized that most of it is public, and linked to the sync-up table.

Per email thread I will add the mailing-list URL, but as I was doing it here I realized it probably deserves prominence at the top of the page, so I need to rewrite one of the "reporting" paragraphs up there

[kristof.beyls]

LGTM, thank you Ahmed!

[mattdr]

This puts the "how to report" instructions front and center, which is by far the most important thing in the doc. Thank you!

[ab]

Thanks all, now landed! I still need to find some time to rewrite the bits about the mailing lists and mention ours.

SECURITY.md

+# Reporting LLVM Security Issues
+
+To report security issues in LLVM, please follow the steps outlined on the
+[LLVM Security Group](https://llvm.org/docs/Security.html#how-to-report-a-security-issue)
+page.

llvm/docs/GettingInvolved.rst

`Test Results Archive (llvm-testresults)`__
   .. __: http://lists.llvm.org/pipermail/llvm-testresults/
 
 `LLVM Announcements List (llvm-announce)`__
   This is a low volume list that provides important announcements regarding
   LLVM.  It gets email about once a month.
 
   .. __: http://lists.llvm.org/mailman/listinfo/llvm-announce
 
+.. _online-sync-ups:
+
 Online Sync-Ups
 ---------------
 
 A number of regular calls are organized on specific topics. It should be
 expected that the range of topics will change over time. At the time of
 writing, the following sync-ups are organized:
 
 .. list-table:: LLVM regular sync-up calls

llvm/docs/Security.rst

 4. Ensure timely notification and release to vendors who package and distribute LLVM-based toolchains and projects.
 5. Ensure timely notification to users of LLVM-based toolchains whose compiled code is security-sensitive, through the `CVE process`_.
 6. Strive to improve security over time, for example by adding additional testing, fuzzing, and hardening after fixing issues.
 
 *Note*: these goals ensure timely action, provide disclosure timing when issues are reported, and respect vendors' / packagers' / users' constraints.
 
 The LLVM Security Group is private. It is composed of trusted LLVM contributors. Its discussions remain within the Security 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.
 
+.. _report-security-issue:
+
+How to report a security issue?
+===============================
+
+To report a security issue in the LLVM Project, please `open a new issue`_ in the LLVM project page, on the chromium issue tracker.  Be sure to use the "Security bug report" template.
+
+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 sending a message to the `llvm-dev mailing list`_ asking to get in touch with someone from the LLVM Security Group. **The escalation mailing list is public**: avoid discussing or mentioning the specific issue when posting on it.
+
 
 Group Composition
 =================
 
 Security Group Members
 ----------------------
 
 The members of the group represent a wide cross-section of the community, and meet the criteria for inclusion below.

 * Help evaluate the severity of incoming issues.
 * Help write and review patches to address security issues.
 * Participate in the member nomination and removal processes.
 
 
 Discussion Medium
 =================
 
-*FUTURE*: this section needs more work! Where discussions occur is influenced by other factors that are still open in this document. We can figure it out later.
-See other existing systems: `chromium issue tracker`_, tentative `GitHub security`_. It seems like bugzilla and email don’t meet security requirements.
+*FUTURE*: this section needs more work! Where discussions occur is influenced by other factors that are still open in this document. We can finalize it later.
+It seems like bugzilla and email don't meet security requirements.
 
 The medium used to host LLVM Security Group discussions is security-sensitive. It should therefore run on infrastructure which can meet our security expectations.
 
-This is where all security discussions occur:
+We are currently using the `chromium issue tracker`_ (as the `llvm` project) to have security discussions:
 
 * File security issues.
-* Nominate new members.
-* Propose member removal.
-* Suggest policy changes.
 * Discuss security improvements to LLVM.
 
-
 When a new issue is filed, a template is provided to help issue reporters provide all relevant information.
 
+*FUTURE*: The `Github security`_ workflow allows publicly disclosing resolved security issues on the github project page, and we would be interested in adopting it for that purpose.  However, it does not easily allow confidential reporting of security issues, as creating Github Security Advisories is currently restricted to Github project admins.  That is why we have started with the `chromium issue tracker`_ instead.
+
+
+We also occasionally need to discuss logistics of the LLVM Security Group itself:
+
+* Nominate new members.
+* Propose member removal.
+* Suggest policy changes.
+
+We often have these discussions publicly, in our :ref:`monthly public sync-up call <online-sync-ups>` and on public LLVM mailing lists.  For internal or confidential discussions, we also use a private mailing list.
 
 Process
 =======
 
 The following process occurs on the discussion medium for each reported issue:
 
 * A security issue reporter (not necessarily an LLVM contributor) reports an issue.
 * 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.

 * None (this process is new, the list hasn't been populated yet)
 * *FUTURE*: this section will be expanded.
 
 The parts of the LLVM Project which are currently treated as non-security sensitive are:
 
 * Language front-ends, such as clang, for which a malicious input file can cause undesirable behavior. For example, a maliciously-crafter C or Rust source file can cause arbitrary code to execute in LLVM. These parts of LLVM haven't been hardened, and compiling untrusted code usually also includes running utilities such as `make` which can more readily perform malicious things.
 * *FUTURE*: this section will be expanded.
 
-.. _report-security-issue:
-
-How to report a security issue?
-===============================
-
-*FUTURE*: this section will be expanded once we’ve figured out other details above. In the meantime, if you found a security issue please follow directly the escalation instructions below.
-
-Not everyone who wants to report a security issue will be familiar with LLVM, its community, and processes. Therefore, this needs to be easy to find on the LLVM website, and set clear expectations to issue reporters.
-
-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 sending a message to the `llvm-dev mailing list`_ asking to get in touch with someone from the LLVM Security Group. **The escalation mailing list is public**: avoid discussing or mentioning the specific issue when posting on it.
 
 .. _CVE process: https://cve.mitre.org
+.. _open a new issue: https://bugs.chromium.org/p/llvm/issues/entry
 .. _chromium issue tracker: https://crbug.com
 .. _GitHub security: https://help.github.com/en/articles/about-maintainer-security-advisories
 .. _llvm-dev mailing list: https://lists.llvm.org/mailman/listinfo/llvm-dev
 .. _MITRE: https://cve.mitre.org