Commit 2398c242 authored by Emmanuele Bassi's avatar Emmanuele Bassi 👣
Browse files

Update README.md

A couple more tweaks to the text and the TODO items.
parent fcf26295
# Security
Historically, we have operated a security@gnome.org email alias. However, it
receives tons of spam, and spam wastes everybody's time. Additionally, it is
easy to lose track of outstanding issues with email-based workflows.
......@@ -8,17 +7,20 @@ easy to lose track of outstanding issues with email-based workflows.
To solve this, let's track issues in GitLab instead. There are two ways to bring
security issues to our attention:
* Use the [web form](https://security.gnome.org/) **Recommended**
* Directly create an report here, if you have a GNOME GitLab account
* Use the [web form](https://blogs.gnome.org/security)
If creating an issue report via the web interface, consider marking your report
as confidential.
When creating an issue report via GitLab, consider marking your report as
confidential. Issues reported via the web form are automatically marked as
confidential.
TODO: Once we determine that this workflow is suitable, we'll set up an
autoreply so that anyone mailing security@gnome.org is directed to use Service
Desk.
*TODO*: Once we determine that this workflow is suitable, we'll set up an
autoreply so that anyone mailing security@gnome.org is directed to use the web
form.
## GPG
TODO: Do we want to accept vulnerability reports over GPG? If so, Tobi should
write instructions because he knows how to use GPG.
\ No newline at end of file
*TODO*: Do we want to accept vulnerability reports over GPG? If so, Tobi should
write instructions because he knows how to use GPG. We can add an optional field
in the web form to include the PGP key for direct communications with the reporter,
but the issues will always be in clear text.
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment