mirror of
https://gitlab.gnome.org/GNOME/glib.git
synced 2024-09-20 01:06:15 +02:00
61075ef0bd
The goal here is to reconcile the difference between GLib's 6-month security policy and GNOME's 12-month policy (which may soon be expanded to 13 months, gnome-build-meta#731). It's strange for GLib to be an exception when the rest of GNOME supports two stable branches at a time. I'm not aware of any other GNOME project with a shorter release lifetime than GNOME itself, and it results in a situation where the previous stable version of the GNOME runtime never receives any GLib updates, since we stick with the same GLib version for the entire release and do not do security backports. But I also want to avoid creating an expectation that GLib maintainers will do a bunch of additional backporting work, so most commits should be out of scope. We can say maintainer discretion will be used to determine whether a backport to the previous stable branch is warranted. And normally, it won't be, so the goal should be no previous stable branch releases. But occasionally we might feel a CVE is important enough that a release really is warranted.
82 lines
3.7 KiB
Markdown
82 lines
3.7 KiB
Markdown
# 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).
|