glib/SECURITY.md
Philip Withnall 1a43d950b4 docs: Update various external links to use HEAD instead of master
Update several links to allow the remote to use its configured default
branch name, rather than specifying `master` as the default branch name.
This will help avoid breakage if any of these projects rename their
default branch in the future.

Fix a few of the links where they were hitting redirects or had moved.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2348
2021-06-07 14:03:48 +01:00

3.0 KiB
Raw Blame History

Security policy for GLib

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 GLibs 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, 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, 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.
  • 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.
  • A new release containing the fix is issued.

Security Announcements

Security announcements are made publicly via the distributor tag on discourse.gnome.org and cross-posted to the distributor-list.

Announcements for security issues with wide applicability or high impact may additionally be made via oss-security@lists.openwall.com.

Acknowledgements

This text was partially based on the github.com/containers security policy, and partially based on the flatpak security policy.