luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-12-26 07:26:15 +01:00
Code Issues Packages Projects Releases Wiki Activity

docs: Add a policy for handling security issues

Browse Source 
This also gives details of how to report a security issue, including the
key point that merge requests are (unfortunately) not confidential.

Heavily based on the flatpak security policy which just landed:
https://github.com/flatpak/flatpak/blob/master/SECURITY.md

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This commit is contained in:
Philip Withnall 2021-03-11 17:38:51 +00:00
parent b3384e5797
commit dec66d325f
1 changed files with 67 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
SECURITY.md Normal file
View File

@ -0,0 +1,67 @@
# Security policy for GLib
* [Supported Versions](#Supported-Versions)
* [Reporting a Vulnerability](#Reporting-a-Vulnerability)
* [Security Announcements](#Security-Announcements)
* [Acknowledgements](#Acknowledgements)
## Supported Versions
Upstream GLib only supports the most recent stable release series, and the
current development release series. Any older stable release series are no
longer supported, although they may still receive backported security updates
in long-term support distributions. Such support is up to the distributions,
though.
Under GLib’s versioning scheme, stable release series have an *even* minor
component (for example, 2.66.0, 2.66.1, 2.68.3), and development release series
have an *odd* minor component (2.67.1, 2.69.0).
## Reporting a Vulnerability
If you think you've identified a security issue in GLib, GObject or GIO, please
**do not** report the issue publicly via a mailing list, IRC, a public issue on
the GitLab issue tracker, a merge request, or any other public venue.
Instead, report a
[*confidential* issue in the GitLab issue tracker](https://gitlab.gnome.org/GNOME/glib/-/issues/new?issue[confidential]=1),
with the “This issue is confidential” box checked. Please include as many
details as possible, including a minimal reproducible example of the issue, and
an idea of how exploitable/severe you think it is.
**Do not** provide a merge request to fix the issue, as there is currently no
way to make confidential merge requests on gitlab.gnome.org. If you have patches
which fix the security issue, please attach them to your confidential issue as
patch files.
Confidential issues are only visible to the reporter and the GLib maintainers.
As per the [GNOME security policy](https://security.gnome.org/), the next steps
are then:
* The report is triaged.
* Code is audited to find any potential similar problems.
* If it is determined, in consultation with the submitter, that a CVE is
required, the submitter obtains one via [cveform.mitre.org](https://cveform.mitre.org/).
* The fix is prepared for the development branch, and for the most recent
stable branch.
* The fix is submitted to the public repository.
* On the day the issue and fix are made public, an announcement is made on the
[public channels listed below](#Security-Announcements).
* A new release containing the fix is issued.
## Security Announcements
Security announcements are made publicly via the
[`distributor` tag on discourse.gnome.org](https://discourse.gnome.org/tag/distributor)
and cross-posted to the
[distributor-list](https://mail.gnome.org/mailman/listinfo/distributor-list).
Announcements for security issues with wide applicability or high impact may
additionally be made via
[oss-security@lists.openwall.com](https://www.openwall.com/lists/oss-security/).
## Acknowledgements
This text was partially based on the
[github.com/containers security policy](https://github.com/containers/common/blob/master/SECURITY.md),
and partially based on the [flatpak security policy](https://github.com/flatpak/flatpak/blob/master/SECURITY.md).