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.
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
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>
