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
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.