Wheezy update of tre?
Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of tre: https://security-tracker.debian.org/tracker/source-package/tre 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 tre updates for the LTS releases. (In case we don't get any answer for months, we may also take it as an opt-out, too.) 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=markup Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Re: Wheezy update of tre?
Hi. Looking at this right now. But I'm a little bit surprised that the whole story begins in wheezy LTS. Should this not start in unstable with a bug report?
fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On Thu, Oct 20, 2016 at 03:59:53PM +0200, Santiago Vila wrote: > But I'm a little bit surprised that the whole story begins in wheezy LTS. > Should this not start in unstable with a bug report? this often happens when there was a CVE with or without a bug filed and noone uploaded a fix. then, at some point, the LTS team comes around and is paid to fix this in LTS… I also think it would be better to always (well, unless the package is gone) make sure this is fixed in unstable first and then in LTS but I dont think this is an individual question but rather think this should be addressed by implementing it as mandatory part of the LTS workflow. -- cheers, Holger signature.asc Description: Digital signature
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On 20.10.2016 16:26, Holger Levsen wrote: > On Thu, Oct 20, 2016 at 03:59:53PM +0200, Santiago Vila wrote: >> But I'm a little bit surprised that the whole story begins in wheezy LTS. >> Should this not start in unstable with a bug report? > > this often happens when there was a CVE with or without a bug filed and > noone uploaded a fix. then, at some point, the LTS team comes around and > is paid to fix this in LTS… > > I also think it would be better to always (well, unless the package is > gone) make sure this is fixed in unstable first and then in LTS but I > dont think this is an individual question but rather think this should > be addressed by implementing it as mandatory part of the LTS workflow. Fixing bugs in unstable or any other suite in Debian is not a part of Wheezy LTS. That doesn't mean that other Debian releases don't benefit from LTS work too. When the versions are quite similar in different distributions it is often just as simple as applying the LTS debdiff on Jessie/Stretch or unstable again. Fixing a package in unstable might require a completely different approach compared with Wheezy, a new upstream release or fixing a totally different code base. Usually the security team files the bug report against the affected package. There is even a template that can be used for this task. I wouldn't mind filing those bug reports when nobody from the security team has found the time to do so yet but then we should also clarify if they appreciate this foray because determining the bug severity is clearly their domain. A suitable compromise would be that we file all bug reports with severity important and they can later check whether it should be release critical. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
Hi, On Thu, Oct 20, 2016 at 04:52:07PM +0200, Markus Koschany wrote: > On 20.10.2016 16:26, Holger Levsen wrote: > > On Thu, Oct 20, 2016 at 03:59:53PM +0200, Santiago Vila wrote: > >> But I'm a little bit surprised that the whole story begins in wheezy LTS. > >> Should this not start in unstable with a bug report? > > > > this often happens when there was a CVE with or without a bug filed and > > noone uploaded a fix. then, at some point, the LTS team comes around and > > is paid to fix this in LTS… > > > > I also think it would be better to always (well, unless the package is > > gone) make sure this is fixed in unstable first and then in LTS but I > > dont think this is an individual question but rather think this should > > be addressed by implementing it as mandatory part of the LTS workflow. > > Fixing bugs in unstable or any other suite in Debian is not a part of > Wheezy LTS. That doesn't mean that other Debian releases don't benefit > from LTS work too. When the versions are quite similar in different > distributions it is often just as simple as applying the LTS debdiff on > Jessie/Stretch or unstable again. > > Fixing a package in unstable might require a completely different > approach compared with Wheezy, a new upstream release or fixing a > totally different code base. > > Usually the security team files the bug report against the affected > package. There is even a template that can be used for this task. I > wouldn't mind filing those bug reports when nobody from the security > team has found the time to do so yet but then we should also clarify if > they appreciate this foray because determining the bug severity is > clearly their domain. A suitable compromise would be that we file all > bug reports with severity important and they can later check whether it > should be release critical. Please file these bugs! The security team has asked for help on this task on several occasions. It's on the LTS TODO list since the BoF at Debconf16: https://wiki.debian.org/LTS/TODO#Update_documentation_on_frontdesk_work:_filling_bug_reports_when_triaging_CVEs and I've added it to the housekeeping tasks recently as well: https://wiki.debian.org/LTS/Development#Housekeeping_Tasks Cheers, -- Guido
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On Thu, Oct 20, 2016 at 05:00:36PM +0200, Guido Günther wrote: > Please file these bugs! The security team has asked for help on this > task on several occasions. It's on the LTS TODO list since the BoF at > Debconf16: > > > https://wiki.debian.org/LTS/TODO#Update_documentation_on_frontdesk_work:_filling_bug_reports_when_triaging_CVEs > > and I've added it to the housekeeping tasks recently as well: > > https://wiki.debian.org/LTS/Development#Housekeeping_Tasks Agreed. And on the topic of severity; if you've triaged a vulnerability and feel it's severe enough to warrant a DLA, feel free to mark them as RC. Severities are easy to adapt after all. Cheers, Moritz
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On Thu, Oct 20, 2016 at 04:52:07PM +0200, Markus Koschany wrote: > Fixing bugs in unstable or any other suite in Debian is not a part of > Wheezy LTS. yes, but it should be! That was entirely the point of my mail. Of course it's more work and of course it might be difficult. But if it's not been done, the fix might get lost and your work was void. -- cheers, Holger signature.asc Description: Digital signature
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On 20.10.2016 17:15, Holger Levsen wrote: > On Thu, Oct 20, 2016 at 04:52:07PM +0200, Markus Koschany wrote: >> Fixing bugs in unstable or any other suite in Debian is not a part of >> Wheezy LTS. > > yes, but it should be! That was entirely the point of my mail. Yes, I got that. And my point was that it should not be mandatory. > Of course it's more work and of course it might be difficult. It's not just about "more work", it is mainly about how you define the scope of a long term support release. We have paid and unpaid contributors. You can't force volunteers to work on something. By declaring it mandatory to fix bugs in unstable, you increase their workload and make it less likely that someone will fix a bug in Wheezy LTS. As for paid contributors: They are paid to keep Wheezy secure and to support users of this distribution. Of course you can extend the scope of Wheezy LTS to unstable but then you need to ask all involved parties, especially the sponsors, if they agree with this change. You get paid for repairing my car if you repair my other car too, just doesn't work. > But if it's not been done, the fix might get lost and your work was void. Why would the work get lost? The patch for Wheezy won't vanish and a fix for unstable is often a totally different issue. signature.asc Description: OpenPGP digital signature
Re: Wheezy update of tre?
Hi Not necessarily. Unstable is the development branch where we do not really have security support. Debian stable has security support by the Debian Security team. And Debian oldstable has security support by the Debian Long Term Security team. // Ola On 20 October 2016 at 15:59, Santiago Vila wrote: > Hi. > > Looking at this right now. > > But I'm a little bit surprised that the whole story begins in wheezy LTS. > > Should this not start in unstable with a bug report? > -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comFolkebogatan 26\ | o...@debian.org 654 68 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Call for advice and testing of nss (and nspr) and intention to upload correction
Hi LTS team, Mozilla maintainers, Mike and Florian I have been working on the security problem reported in nss (and nspr). https://security-tracker.debian.org/tracker/TEMP-000-583651 It is about unprotected environment variables. I did a check on what Florian Weimer had done for jessie-security and the solution there was simply to package the new upstream release. So I decided to do that approach as well. The advantage with this is that we will not only have this problem solved, but also a few more. TEMP-000-583651 (nspr and nss) CVE-2014-3566 CVE-2014-1490 CVE-2013-1740 The disadvantage is that we are not playing safe. However it looks backwards compatible, but you never know. So all in all I have produced the following: nspr: http://apt.inguza.net/wheezy-security/nspr This is essentially a mimic of the jessie-security package changes. nss: http://apt.inguza.net/wheezy-security/nss This is essentially a re-build of the jessie-security package with changes file kept and only updated with one new entry. Call for advice: 1) Do you have an opinion about the fact that I backport new upstream release? 2) Will we have a build problem as nss depends on the latest nspr? I guess I shall upload nspr first. 3) Shall I create one DLA covering both packages or shall I just produce one DLA covering both nspr and nss? I think one DLA is the best as both are needed to solve the problem reported. But maybe that is against some practice. If you think I shall write two, then please advice me what to write in the DLA for nspr. Call for testing: 4) As this package can have a rather big impact on lot of other packages it would be good if all of you install the new version (nss is the important one) to see if it works for you. I did not produce a debdiff as that diff was way too large to be useful. I have installed it myself but I have not been able to verify that the tools using it is really working. Most are GUI tools and I do not have a GUI environment to test wheezy in. The libnss3-tools package seems to work fine to the limit I was able to check. I have not tried to reproduce the problem as the report was too vague to give any good advice on what environment variable that could actually cause a problem. If I do not hear any objections in four days I will upload anyway. Thanks in advance // Ola -- --- Inguza Technology AB --- MSc in Information Technology | o...@inguza.com Folkebogatan 26 | o...@debian.org 654 68 KARLSTAD | http://inguza.com/Mobile: +46 (0)70-332 1551 | gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
Hi, 2016-10-20 18:31 GMT+02:00 Markus Koschany : > On 20.10.2016 17:15, Holger Levsen wrote: >> On Thu, Oct 20, 2016 at 04:52:07PM +0200, Markus Koschany wrote: >>> Fixing bugs in unstable or any other suite in Debian is not a part of >>> Wheezy LTS. >> >> yes, but it should be! That was entirely the point of my mail. > > Yes, I got that. And my point was that it should not be mandatory. I think it would be a good approach to file bugs against unstable, offer help in updating the version and if we don't get a response NMU the affected package in unstable according to NMU rules. > >> Of course it's more work and of course it might be difficult. > > It's not just about "more work", it is mainly about how you define the > scope of a long term support release. We have paid and unpaid > contributors. You can't force volunteers to work on something. By > declaring it mandatory to fix bugs in unstable, you increase their > workload and make it less likely that someone will fix a bug in Wheezy LTS. I think we are close to be able to handle the Wheezy issues in a reasonable time thus if keep Wheezy the highest priority, then LTS's quality wouldn't suffer. > > As for paid contributors: They are paid to keep Wheezy secure and to > support users of this distribution. Of course you can extend the scope > of Wheezy LTS to unstable but then you need to ask all involved parties, > especially the sponsors, if they agree with this change. You get paid > for repairing my car if you repair my other car too, just doesn't work. I would ask our sponsors, too. I think extending the scope of the LTS project to helping with security issues in perfectly reasonable, since stable will sooner or later become oldstable then LTS, unstable will become stable thus the quality of LTS would also gain from that work. I would also make an exception, when a package is not used by sponsors (and probably is widely used) we should not spend too much time on fixing unstable to avoid keeping insecure and obsolete packages in testing. Cheers, Balint > >> But if it's not been done, the fix might get lost and your work was void. > > Why would the work get lost? The patch for Wheezy won't vanish and a fix > for unstable is often a totally different issue. > > >
October Report
This month I had 13 hours and I spent my 13 hours on the following projects: * Continue patching graphicsmagick for various security issues. CVE-2016-7446, CVE-2016-7447, CVE-2016-7449, CVE-2016-7800. * Attempted to patch graphicsmagick for CVE-2016-7448 however found code has changed and couldn't get it to compile. * Uploaded new graphicsmagick with fixes for CVE-2016-7446, CVE-2016-7447, CVE-2016-7449, CVE-2016-7800. * Create fix to systemd for CVE-2016-7796, get patch peer reviewed, and test. * Upload fixed systemd to security-wheezy. * Update to sign-advisory.sh to make it work with DLAs. * Preliminary investigations into latest batch of security issues with graphicsmagick. -- Brian May https://linuxpenguins.xyz/brian/
October Report
This month I had 13 hours and I spent my 13 hours on the following projects: * Continue patching graphicsmagick for various security issues. CVE-2016-7446, CVE-2016-7447, CVE-2016-7449, CVE-2016-7800. * Attempted to patch graphicsmagick for CVE-2016-7448 however found code has changed and couldn't get it to compile. * Uploaded new graphicsmagick with fixes for CVE-2016-7446, CVE-2016-7447, CVE-2016-7449, CVE-2016-7800. * Create fix to systemd for CVE-2016-7796, get patch peer reviewed, and test. * Upload fixed systemd to security-wheezy. * Update to sign-advisory.sh to make it work with DLAs. * Preliminary investigations into latest batch of security issues with graphicsmagick. -- Brian May
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On Thu, Oct 20, 2016 at 14:26:41 +, Holger Levsen wrote: > On Thu, Oct 20, 2016 at 03:59:53PM +0200, Santiago Vila wrote: > > But I'm a little bit surprised that the whole story begins in wheezy LTS. > > Should this not start in unstable with a bug report? > > this often happens when there was a CVE with or without a bug filed and > noone uploaded a fix. then, at some point, the LTS team comes around and > is paid to fix this in LTS… > > I also think it would be better to always (well, unless the package is > gone) make sure this is fixed in unstable first and then in LTS but I > dont think this is an individual question but rather think this should > be addressed by implementing it as mandatory part of the LTS workflow. > Yes please. The amount of QA you can do pre-release on wheezy updates is presumably fairly limited. Having patches tested in unstable in the (presumably not that rare) cases where the backport isn't the most difficult/risky part of fixing the bug seems like it would benefit everyone, except for maybe delaying your payments a bit. (My pet peeve here are the recent libx* CVEs, which aren't critical, and where the patches are tricky enough that regressions aren't exactly unlikely. Maybe that's rare. I don't think it is.) Cheers, Julien
Re: Call for advice and testing of nss (and nspr) and intention to upload correction
Hi Ola, On Thu, Oct 20, 2016 at 11:15:29PM +0200, Ola Lundqvist wrote: > Hi LTS team, Mozilla maintainers, Mike and Florian > > I have been working on the security problem reported in nss (and nspr). > https://security-tracker.debian.org/tracker/TEMP-000-583651 > It is about unprotected environment variables. > > I did a check on what Florian Weimer had done for jessie-security and > the solution there was simply to package the new upstream release. So > I decided to do that approach as well. The advantage with this is that > we will not only have this problem solved, but also a few more. > > TEMP-000-583651 (nspr and nss) > CVE-2014-3566 > CVE-2014-1490 > CVE-2013-1740 > > The disadvantage is that we are not playing safe. However it looks > backwards compatible, but you never know. > > So all in all I have produced the following: > > nspr: > http://apt.inguza.net/wheezy-security/nspr > This is essentially a mimic of the jessie-security package changes. > > nss: > http://apt.inguza.net/wheezy-security/nss > This is essentially a re-build of the jessie-security package with > changes file kept and only updated with one new entry. > > Call for advice: > 1) Do you have an opinion about the fact that I backport new upstream release? See my discussion with the release team abot this: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824872 > 2) Will we have a build problem as nss depends on the latest nspr? I > guess I shall upload nspr first. See my runs of the abi compliance checker in the above URL. > 3) Shall I create one DLA covering both packages or shall I just > produce one DLA covering both nspr and nss? The rule is one DLA per package AFAIK. > I think one DLA is the best as both are needed to solve the problem > reported. But maybe that is against some practice. If you think I > shall write two, then please advice me what to write in the DLA for > nspr. > > Call for testing: > 4) As this package can have a rather big impact on lot of other > packages it would be good if all of you install the new version (nss > is the important one) to see if it works for you. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806207 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806639 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809723 that enable the internal test suites and add some autopkgtests. This should help to gain some confidence. Cheers, -- Guido > > I did not produce a debdiff as that diff was way too large to be useful. > > I have installed it myself but I have not been able to verify that the > tools using it is really working. Most are GUI tools and I do not have > a GUI environment to test wheezy in. The libnss3-tools package seems > to work fine to the limit I was able to check. > > I have not tried to reproduce the problem as the report was too vague > to give any good advice on what environment variable that could > actually cause a problem. > > If I do not hear any objections in four days I will upload anyway. > > Thanks in advance > > // Ola > > -- > --- Inguza Technology AB --- MSc in Information Technology > | o...@inguza.com Folkebogatan 26 > | o...@debian.org 654 68 KARLSTAD > | http://inguza.com/Mobile: +46 (0)70-332 1551 > | gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 >
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On Thu, Oct 20, 2016 at 11:21:14PM +0200, Bálint Réczey wrote: > I think it would be a good approach to file bugs against unstable, offer > help in updating the version and if we don't get a response NMU the > affected package in unstable according to NMU rules. yes, that. or at least amend LTS-policies to always file a bug if one fixes a bug in LTS which is still open in sid. -- cheers, Holger signature.asc Description: Digital signature
Re: Wheezy update of tre?
On Thu, Oct 20, 2016 at 9:59 PM, Santiago Vila wrote: > Should this not start in unstable with a bug report? This is what the stable security team usually do, because they know that if they don't they will eventually have to do the work themselves. They also do NMUs in unstable in some cases. -- bye, pabs https://wiki.debian.org/PaulWise
