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
