Re: Security updates of ansible in buster and stretch
Hi Markus,
On 28/01/2021 00:02, Markus Koschany wrote:
> Hello Lee, hello security team,
>
> I have been working on security updates of ansible in Stretch and my intention
> was to fix the remaining issues in Buster as well. However testing those
> upstream patches proved to be rather difficult in older releases. I believe it
> is generally possible to fix most of the unresolved vulnerabilities with
> targeted fixes but this requires some effort for both distributions.
>
> First of all, are there any plans to update Buster in the foreseeable future,
> is anyone working on that right now?
It was my original plan to round-up many of the security issues (which
are all low-impact last time I checked) when I find the time, but I've
lately been busy getting ansible 2.10 in shape. So if you feel like
fixing those, feel free to go ahead, and push those to the corresponding
git branch.
>
> I saw that newer versions of ansible were uploaded to stretch-, and buster-
> backports? What do you think of updating ansible in oldstable and stable
> instead, to fix the remaining security vulnerabilities properly?
That might be quite disruptive; see below.
>
> How big is the risk of breaking existing installations of ansible in oldstable
> and stable? I have successfully built ansible 2.9.16+dfsg-1.1 from Bullseye,
> there is only a minor problem with building the documentation, and it seems the
> same version should work in Stretch too.
Backporting a new feature release will be disruptive, as ansible
deprecates many things within 2 feature releases. Meaning that an
upgrade in oldstable from 2.2 to 2.7 will likely break the playbooks for
most users there. In stable the bump would be from 2.7 to 2.9, which
will be less disruptive (but still break some playbooks). However, my
gut feeling is that most users are using stable-backports (or straight
sid) for their workstations, anyway.
The other thing is that there are no unit tests (I'm currently working
on them for 2.10). In 2.3 for example there was a fatal bug that only
appeared with certain versions of python-jinja2 (it was fine in sid back
then, but broke in testing), so I'd be very hesitant to backport feature
releases without thoroughly testing them. In the future backporting (for
-security and for -backports) will get better when there are unit tests
in place.
>
> All in all, we could try to backport the latest version to older stable
> releases or we could walk a middle way and base the patches all on Buster or
> the newer buster-backports version or something in between. This would
> certainly reduce the maintenance costs in those older releases.
>
> What are your thoughts?
I'd leave oldstable untouched; I don't believe there are any users on it
anymore.
For stable I'd backport only the security fixes, though I'm fairly
certain those won't be straight forward, as upstream does refactor
larger chunks of code in every feature release. I believe they all were
pretty low-impact CVEs, upstream tends to err on the side of caution and
give things CVEs very easily. I think it's fine to wrap them up in a
Debian release and release it via stable-updates.
>
> Regards,
>
> Markus
>
>
Greets,
Lee
Reply to: