glib/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).
-												docs: Add a policy for handling security issues

This also gives details of how to report a security issue, including the
key point that merge requests are (unfortunately) not confidential.

Heavily based on the flatpak security policy which just landed:
https://github.com/flatpak/flatpak/blob/master/SECURITY.md

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

											
										
										
											2021-03-11 18:38:51 +01:00
+								# Security policy for GLib
 								 * [Supported Versions](#Supported-Versions)
 								 * [Reporting a Vulnerability](#Reporting-a-Vulnerability)
 								 * [Security Announcements](#Security-Announcements)
 								 * [Acknowledgements](#Acknowledgements)
 								## Supported Versions
-												Expand security policy to cover previous stable branch

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.

											
										
										
											2023-09-28 18:08:01 +02:00
+								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.
-												docs: Add a policy for handling security issues

This also gives details of how to report a security issue, including the
key point that merge requests are (unfortunately) not confidential.

Heavily based on the flatpak security policy which just landed:
https://github.com/flatpak/flatpak/blob/master/SECURITY.md

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

											
										
										
											2021-03-11 18:38:51 +01:00
 								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).
-												docs: Add a note about git-evtag to SECURITY.md

											
										
										
											2021-09-07 13:21:12 +02:00
+								## 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.
-												docs: Add a policy for handling security issues

This also gives details of how to report a security issue, including the
key point that merge requests are (unfortunately) not confidential.

Heavily based on the flatpak security policy which just landed:
https://github.com/flatpak/flatpak/blob/master/SECURITY.md

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

											
										
										
											2021-03-11 18:38:51 +01:00
+								## 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
-												docs: Update SECURITY to stop mentioning a deprecated mailing list

Discourse has replaced the GNOME mailing lists.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

											
										
										
											2022-12-13 20:16:35 +01:00
+								[`distributor` tag on discourse.gnome.org](https://discourse.gnome.org/tag/distributor).
-												docs: Add a policy for handling security issues

This also gives details of how to report a security issue, including the
key point that merge requests are (unfortunately) not confidential.

Heavily based on the flatpak security policy which just landed:
https://github.com/flatpak/flatpak/blob/master/SECURITY.md

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

											
										
										
											2021-03-11 18:38:51 +01:00
 								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
-												docs: Update various external links to use HEAD instead of master

Update several links to allow the remote to use its configured default
branch name, rather than specifying `master` as the default branch name.
This will help avoid breakage if any of these projects rename their
default branch in the future.

Fix a few of the links where they were hitting redirects or had moved.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2348

											
										
										
											2021-06-07 14:16:50 +02:00
+								[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).