Upstream GLib only supports the most recent stable release series, the previous 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.
The previous stable release series will generally receive fixes only for high impact security issues, at maintainer discretion. Since such issues are rare, it's expected that there may be no backports or releases on the previous stable branch.
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).
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.
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 are made publicly via the
distributor tag on discourse.gnome.org.
Announcements for security issues with wide applicability or high impact may additionally be made via oss-security@lists.openwall.com.
This text was partially based on the github.com/containers security policy, and partially based on the flatpak security policy.