Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Nov 2017 00:48:41 +0000
From:      Ben Woods <>
To:        rplace <>
Subject:   =?UTF-8?Q?Re=3A_why_pkgs_with_vulnerabilities_on_quarterly_aren?= =?UTF-8?Q?=E2=80=99t_updated?=
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Sun, 26 Nov 2017 at 12:22 am, rplace <> wrote:

> Every day I check pkg audit -F on 11.1 from quarterly, and for like a mon=
> it=E2=80=99s listed many xorg-server vulnerabilities. And now it=E2=80=99=
s listed
> firefox-esr
> vulnerabilities for what seems like at least a week.
> For xorg-server, I see that there=E2=80=99s
> which has drawn zero attention.
> I see that there are newer versions in latest.
> How do I tell when issues have fallen between the cracks vs
> a change deliberately not being brought to quarterly?
> In cases like this, does it make sense to talk to maintainers,
> or to one of the pkg/ports lists, or=E2=80=A6?

Hi rplace,

Quartlery branches are definitely supposed to receive security updates.
Sometime people forget, and if this is the case you absolutely should
remind them. Ideally this would just be the minimal update to address the
vulnerability, without bringing new features. However, patches do not
always exist, and sometime this is not easy.

Where security issues have been addressed in the head branch, but not the
quarterly branch, I recommend:
- checking if the commit to head had a MFH request (merge from head)...
perhaps the committer is just waiting for the approval to merge the commit
to quarterly.
- if there was a bug report, check if it has been closed or if it is still
open awaiting the MFH (there is a flag in bugzilla that can be set to show
this is the status).
- if a number of days (closer to a week) has passed since it was addressed
in head and it still hasn=E2=80=99t been addressed in quarterly, or there w=
as no
MFH commentary to suggest it would be addressed in quarterly, then I
suggest either commenting on the bug report that was related to the commit
to state the MFH has been forgotten (reopen the bug), or raise a new bug
report, ensuring that the person who made the commit to head gets
automatically assigned as the assignee after raising or add them to the CC
list manually.


> --

From: Benjamin Woods

Want to link to this message? Use this URL: <>