SECURITY.md

   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
  10 Upstream GLib only supports the most recent stable release series, and the
  11 current development release series. Any older stable release series are no
  12 longer supported, although they may still receive backported security updates
  13 in long-term support distributions. Such support is up to the distributions,
  14 though.
  15
  16 Under GLib’s versioning scheme, stable release series have an *even* minor
  17 component (for example, 2.66.0, 2.66.1, 2.68.3), and development release series
  18 have an *odd* minor component (2.67.1, 2.69.0).
  19
  20 ## Signed Releases
  21
  22 The 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
  24 their personal GPG key; there is currently not necessarily a formal chain of
  25 trust for these keys. Please [create an issue](https://gitlab.gnome.org/GNOME/glib/-/issues/new)
  26 if you would like to work on improving this.
  27
  28 Unsigned releases ≥2.58.0 should not be trusted. Releases prior to 2.58.0 were
  29 not signed.
  30
  31 ## Reporting a Vulnerability
  32
  33 If 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
  35 the GitLab issue tracker, a merge request, or any other public venue.
  36
  37 Instead, report a
  38 [*confidential* issue in the GitLab issue tracker](https://gitlab.gnome.org/GNOME/glib/-/issues/new?issue[confidential]=1),
  39 with the “This issue is confidential” box checked. Please include as many
  40 details as possible, including a minimal reproducible example of the issue, and
  41 an 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
  44 way to make confidential merge requests on gitlab.gnome.org. If you have patches
  45 which fix the security issue, please attach them to your confidential issue as
  46 patch files.
  47
  48 Confidential issues are only visible to the reporter and the GLib maintainers.
  49
  50 As per the [GNOME security policy](https://security.gnome.org/), the next steps
  51 are 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
  65 Security announcements are made publicly via the
  66 [`distributor` tag on discourse.gnome.org](https://discourse.gnome.org/tag/distributor).
  67
  68 Announcements for security issues with wide applicability or high impact may
  69 additionally be made via
  70 [oss-security@lists.openwall.com](https://www.openwall.com/lists/oss-security/).
  71
  72 ## Acknowledgements
  73
  74 This text was partially based on the
  75 [github.com/containers security policy](https://github.com/containers/common/blob/HEAD/SECURITY.md),
  76 and partially based on the [flatpak security policy](https://github.com/flatpak/flatpak/blob/HEAD/SECURITY.md).