SECURITY.md - external/gitlab.gnome.org/GNOME/glib - Git at Google

 # 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, 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).

 ## Signed Releases

 The git tags for all releases ≥2.58.0 are signed by a maintainer using
 [git-evtag](https://github.com/cgwalters/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](https://gitlab.gnome.org/GNOME/glib/-/issues/new)
 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](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).

 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/HEAD/SECURITY.md),
 and partially based on the [flatpak security policy](https://github.com/flatpak/flatpak/blob/HEAD/SECURITY.md).
	# 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, 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).

	## Signed Releases

	The git tags for all releases ≥2.58.0 are signed by a maintainer using
	[git-evtag](https://github.com/cgwalters/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](https://gitlab.gnome.org/GNOME/glib/-/issues/new)
	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](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).

	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/HEAD/SECURITY.md),
	and partially based on the [flatpak security policy](https://github.com/flatpak/flatpak/blob/HEAD/SECURITY.md).