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
Re: Bug#962596: Backport to stretch?
Hi Michael, stretch is EOL, so I am not planning on touching it myself. Cc:ing the team that looks after stretch-lts in case they want to handle this. Cheers, Julien On Mon, Feb 01, 2021 at 03:14:38PM +, Michael Simons (.NET) wrote: > Hi Julien, > > > > Thanks for pushing the changes to buster. Will this get backported to stretch > as well? If so, what is the timeframe users can expect? > > > > > I'm not sure why this is blowing up again this week > > > > See https://github.com/NuGet/Announcements/issues/49 for details on how this > affected .NET users building on Debian. > > Thanks > > Michael > > > On Thu, 28 Jan 2021 15:17:34 +0100 “Julien Cristau" > wrote: > > Hi, > > > > > > I'm not sure why this is blowing up again this week when things have > > > been in a bit of a limbo state since June last year, but in any case > > > I've just pushed a change to buster to try and revert the blacklisting > > > of legacy Symantec CAs. That should hopefully make it to the archive in > > > the next few days. > > > > > > Cheers, > > > Julien >
Re: (semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
On Mon, Feb 01, 2021 at 11:32:13AM +, Holger Levsen wrote: > > One DLA has been reserved but not yet been published: > - DLA 2537-1 (31 Jan 2021) (ffmpeg) > It looks like this was just merged/published. > Have a great week! > You too! Regards, -Roberto -- Roberto C. Sánchez
Debian LTS and ELTS - January 2021
Here is my public monthly report. Thanks to our sponsors for making this possible, and to Freexian for handling the offering. https://www.freexian.com/services/debian-lts.html#sponsors LTS - imagemagick: - global triage - DLA 2523-1 https://lists.debian.org/debian-lts-announce/2021/01/msg00010.html - unbound: feasibility study for support https://lists.debian.org/debian-lts/2021/01/msg00011.html - spotweb: bypass CVE-2021-3286 fix and register CVE-2021-3286 https://github.com/spotweb/spotweb/issues/653 - reel: coordinate end of support https://lists.debian.org/debian-lts-announce/2021/01/msg00020.html - triage: php-horde-trean, golang/golang-1.8, cacti, pillow - sympa: answer questions about DLA 2499-1 (BTS/github/mail) - awstats: update CVE-2020-35176 info (DLA 2506-1) - IRC meeting ELTS - imagemagick: - common work with LTS - ELA-345-1 https://deb.freexian.com/extended-lts/updates/ela-345-1-imagemagick/ - triage: - common work with LTS - golang/golang-1.7, cacti, pillow -- Sylvain Beucler Debian LTS Team
(semi-)automatic unclaim of packages with more than 2 weeks of inactivity (and missing DLAs on www.do)
hi, today two packages were unclaimed for each LTS: - ceph (Emilio) - ruby-actionpack-page-caching (Brian May) ELTS: - ceph (Emilio) - phpldapadmin (Emilio) With these Emilio probably claimed too many packages (in LTS): - ceph - firefox-esr - libdatetime-timezone-perl - thunderbird - tzdata One DLA has been reserved but not yet been published: - DLA 2537-1 (31 Jan 2021) (ffmpeg) Have a great week! -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
