Re: How much no-dsa is too much no-dsa?
On Tue, May 27, 2025 at 04:08:00PM -0400, Roberto C. Sánchez wrote:
>...
> I am
> also interested to know whether people think that our more clearly
> defined "(un)stable-first" approach to package updates might make this
> less of a pressing issue going forward (because we would be landing
> fixes in stable before* landing them in LTS).
>
> * Which may actually mean "landing fixes in the PU queue before landing
> them in LTS").
>...
A strict interpretation of "(un)stable-first" does not make much sense.
When preparing a DLA, fixing the same issues also in unstable and
(old)stable-pu (or DSA) is usually a nearly free byproduct.
It is also unclear what you mean with "landing fixes in the PU queue".
Does "landing" mean "submitted" or "accepted by the release team"?
It sometimes takes months until the release team reviews a request.[1]
>...
> If the CVE is
> not fixed in stable then there is a possibility that a user may
> experience an upgrade regression. This happens when a CVE is fixed in an
> older release and then when the upgrade to a newer release is performed
> that CVE is suddenly no longer fixed in the new system. This is an
> undesirable situation that we want to try to avoid.
>...
It takes on average 2 months and in the worst case more than 4 months
until fixes in the oldstable-pu queue reach users.
If the goal is to delay providing non-DSA security fixes in (E)LTS
to users by several months until the next (old)stable point releases,
then making (E)LTS point releases every 4 months at the same time as
oldstable[2] point releases would be the option.
> Regards,
>
> -Roberto
cu
Adrian
[1] they clearly aim to review the queue in time for a point release,
but review cadence between point releases is varying
[2] or every 2 months at the same time as stable, during the half of the
time when only one non-LTS stable release exists
Reply to: