[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Security updates of ansible in buster and stretch

Hi Lee,

Am Dienstag, den 02.02.2021, 03:56 +0100 schrieb Lee Garrett:

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

Thanks for your reply! That sounds like ansible is only borderline suitable for
a Debian stable release in my opinion. I can understand that people upgrade to
stable-backports to get new features but using sid (really?) on a production
system is rather brave. I also find it strange that we assume users will use
-backports and sid updates, which should regularly break their playbooks, but
we don't consider to provide regular updates in supported stable releases.

I have had a look at how Red Hat supports Ansible and I found this page. [1]
They appear to limit full support and provide only targeted fixes for a couple
of months and then urge users to upgrade to the next supported upstream
version. I suggest we consider doing something similar in the future. It could
be mentioned in the release notes at least. I believe it would be more
transparent and fair to acknowledge that Ansible is not your typical long-term
supportable package.

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

Ok, indeed the lack of unit tests and testing capabilities in general makes it
difficult to maintain ansible in oldstable and stable right now.

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

Fine with me. I will investigate the remaining issues in stable and try to fix
as many of them as reasonably possible and get back to you. However I feel we
should try our best effort for oldstable too because if you make something
available and claim it is long-term supported then there are usually some users
left who still use your package unless they know way beforehand about the
difficulties. As I suggested we probably should make it explicit in the Debian
release notes and simply announce the EOL status after support for Debian
stable has ended. 



[1] https://access.redhat.com/support/policy/updates/ansible-engine

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: