1# Security policy for GLib 2 3 * [Supported Versions](#Supported-Versions) 4 * [Reporting a Vulnerability](#Reporting-a-Vulnerability) 5 * [Security Announcements](#Security-Announcements) 6 * [Acknowledgements](#Acknowledgements) 7 8## Supported Versions 9 10Upstream GLib only supports the most recent stable release series, and the 11current development release series. Any older stable release series are no 12longer supported, although they may still receive backported security updates 13in long-term support distributions. Such support is up to the distributions, 14though. 15 16Under GLib’s versioning scheme, stable release series have an *even* minor 17component (for example, 2.66.0, 2.66.1, 2.68.3), and development release series 18have an *odd* minor component (2.67.1, 2.69.0). 19 20## Signed Releases 21 22The git tags for all releases ≥2.58.0 are signed by a maintainer using 23[git-evtag](https://github.com/cgwalters/git-evtag). The maintainer will use 24their personal GPG key; there is currently not necessarily a formal chain of 25trust for these keys. Please [create an issue](https://gitlab.gnome.org/GNOME/glib/-/issues/new) 26if you would like to work on improving this. 27 28Unsigned releases ≥2.58.0 should not be trusted. Releases prior to 2.58.0 were 29not signed. 30 31## Reporting a Vulnerability 32 33If you think you've identified a security issue in GLib, GObject or GIO, please 34**do not** report the issue publicly via a mailing list, IRC, a public issue on 35the GitLab issue tracker, a merge request, or any other public venue. 36 37Instead, report a 38[*confidential* issue in the GitLab issue tracker](https://gitlab.gnome.org/GNOME/glib/-/issues/new?issue[confidential]=1), 39with the “This issue is confidential” box checked. Please include as many 40details as possible, including a minimal reproducible example of the issue, and 41an idea of how exploitable/severe you think it is. 42 43**Do not** provide a merge request to fix the issue, as there is currently no 44way to make confidential merge requests on gitlab.gnome.org. If you have patches 45which fix the security issue, please attach them to your confidential issue as 46patch files. 47 48Confidential issues are only visible to the reporter and the GLib maintainers. 49 50As per the [GNOME security policy](https://security.gnome.org/), the next steps 51are then: 52 * The report is triaged. 53 * Code is audited to find any potential similar problems. 54 * If it is determined, in consultation with the submitter, that a CVE is 55 required, the submitter obtains one via [cveform.mitre.org](https://cveform.mitre.org/). 56 * The fix is prepared for the development branch, and for the most recent 57 stable branch. 58 * The fix is submitted to the public repository. 59 * On the day the issue and fix are made public, an announcement is made on the 60 [public channels listed below](#Security-Announcements). 61 * A new release containing the fix is issued. 62 63## Security Announcements 64 65Security announcements are made publicly via the 66[`distributor` tag on discourse.gnome.org](https://discourse.gnome.org/tag/distributor) 67and cross-posted to the 68[distributor-list](https://mail.gnome.org/mailman/listinfo/distributor-list). 69 70Announcements for security issues with wide applicability or high impact may 71additionally be made via 72[oss-security@lists.openwall.com](https://www.openwall.com/lists/oss-security/). 73 74## Acknowledgements 75 76This text was partially based on the 77[github.com/containers security policy](https://github.com/containers/common/blob/HEAD/SECURITY.md), 78and partially based on the [flatpak security policy](https://github.com/flatpak/flatpak/blob/HEAD/SECURITY.md). 79