openkylin
/
glib2.0
mirror of https://gitee.com/openkylin/glib2.0.git
9
0
Fork 0
Code Issues Projects Releases Wiki Activity
glib2.0/SECURITY.md

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

Signed Releases

The git tags for all releases ≥2.58.0 are signed by a maintainer using git-evtag. The maintainer will use their personal GPG key; there is currently not necessarily a formal chain of trust for these keys. Please create an issue if you would like to work on improving this.

Unsigned releases ≥2.58.0 should not be trusted. Releases prior to 2.58.0 were not signed.

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.