Re: [SECURITY] CVE-2019-7443 (kauth) in kdelibs
Hi, > kdelibs last release was 4.14.35 in August 2017. > > kdelibs is no longer maintained. > > Qt 4 last release was 4.8.7 in May 2015. > > Qt 4 is no longer maintained. > > Our suggestion is to stop using any qt4/kdelibs based software and move to > the future if you're concerned about security and/or want to use maintained > software. It is not that we do not try it, to remove Qt4 from Debian. We try since Aug 2017 to reach this goal to remove all qt4/kdelibs software, but still there is a lot depending on qt4/kdelibs: https://wiki.debian.org/Qt4Removal (If you have any notes about status of packages aka dead by upstream - input is very welcomed). In next Debian Buster released in some months we still need to ship qt4/ kdelibs. Regards, hefee
Re: Wheezy update of kdepim?
Hey, Me is not interested in doing it. Just a little warning: Upstream splitted kdepim into many packages, you should also take care of for example about security issues in kf5-messagelib, kdepim-addons, kdepim-apps-libs, libkf5calendarsupport, libkf5eventviews,, libkf5sieve... when you want to fix all security issues in kdepim (maxy had uploaded all the packages, so he might have a list of all). Regards, sandro -- On Sonntag, 18. Juni 2017 02:06:41 CEST Chris Lamb wrote: > Dear maintainer(s), > > The Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of kdepim: > https://security-tracker.debian.org/tracker/source-package/kdepim > > Would you like to take care of this yourself? > > If yes, please follow the workflow we have defined here: > https://wiki.debian.org/LTS/Development > > If that workflow is a burden to you, feel free to just prepare an > updated source package and send it to debian-lts@lists.debian.org > (via a debdiff, or with an URL pointing to the source package, > or even with a pointer to your packaging repository), and the members > of the LTS team will take care of the rest. Indicate clearly whether you > have tested the updated package or not. > > If you don't want to take care of this update, it's not a problem, we > will do our best with your package. Just let us know whether you would > like to review and/or test the updated package before it gets released. > > You can also opt-out from receiving future similar emails in your > answer and then the LTS Team will take care of kdepim updates > for the LTS releases. > > Thank you very much. > > Chris Lamb, > on behalf of the Debian LTS team. > > PS: A member of the LTS team might start working on this update at > any point in time. You can verify whether someone is registered > on this update in this file: > https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=ma > rkup > > > Regards, signature.asc Description: This is a digitally signed message part.
Re: Wheezy update of roundcube?
Hey, On the one side I'm totally with Guilhem, that getting rid of the old roundcube in old-stable would be the best thing. Upstream itself do not support this version for a longer time. I'm not sure if any CVEs are filed for such old versions anymore from upstream. On the other side: The upgrade from 0.7->0.9->1.0 was never tested on a bit audience, because roundcube was not released with stable. So we have a very small testset, who tested this upgrade. So pushing this upgrade to lts is exactly the opposite of providing a stable upgrade. Regards, sandro -- Am Dienstag, 3. Mai 2016, 18:52:32 CEST schrieb Markus Koschany: > Am 03.05.2016 um 18:37 schrieb Moritz Muehlenhoff: > > On Tue, May 03, 2016 at 06:28:03PM +0200, Markus Koschany wrote: > >> The second best solution would be to backport either the 1.0.x branch or > >> your jessie-backport packages to Wheezy. Since you actively maintain > >> them, what do you think, how complex is the task to backport the > >> packages from jessie-backports to Wheezy? > > > > What's the point in updating a server package like roundcube in LTS > > to the version from LTS+1? I creates significant churn on the sysadmin's > > side, which is better spent on upgrading the entire VM/machine to LTS+1. > > > > Clearly not all packages are suitable for five years maintenance, so it's > > better to not paper over the systems, but rather make this explicit. > > You should also take into consideration that Roundcube is a web > application and depending on the package in question and options > available, a backport is a reasonable solution, for the same reasons we > have backported other packages before. Also the whole point of LTS is > that you don't have to upgrade the entire system, especially if you run > multiple different PHP applications on the same server. The order of > options is still valid. > > Regards, > > Markus signature.asc Description: This is a digitally signed message part.
