Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
Hi That is a good practice, yes. // Ola On 21 October 2016 at 01:43, Holger Levsen wrote: > 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 > -- --- 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 / ---
Re: graphicsmagick security update
Luciano Bello writes: > On Wednesday 19 October 2016 09.07.42 László Böszörményi wrote: >> In short, I didn't have enough time and information of the individual >> fixes. Yesterday fixed other three vulnerabilities for Sid, will apply >> those to Jessie as well. > > Hi Laszlo (and Brian) >Brian mentioned that he was working in some patches for stable. Is there > any repo where he can merge them? No, not stable, oldstable (LTS). I uploaded an update for oldstable several days ago, however there are more security issues that I haven't patched yet. > The security tracker are link to each other. Usually it is up to the > maintainer to get the patches around. But it's true, we should find a better > way to share patches with derivatives. In this case I am part of the LTS team. However, yes, I agree, it would be good if both security teams and LTS teams had a better way of sharing patches. Unfortunately, I have no good ideas on how to do this. -- Brian May
Wheezy update of dwarfutils?
Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of dwarfutils: https://security-tracker.debian.org/tracker/source-package/dwarfutils Note that these appear to be a new round of issues not covered by the recent DLA 669-1 announcement: https://lists.debian.org/debian-lts-announce/2016/10/msg00024.html 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 dwarfutils 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: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
Hi Holger, On Thu, Oct 20, 2016 at 11:43:06PM +, Holger Levsen wrote: > 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. I think the later part is already LTS policy since at latest Debconf 16. It's up to us to handle things like that. Cheers, -- Guido
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
Guido Günther wrote:
> > or at least amend LTS-policies to always file a bug if one fixes a bug
> > in LTS which is still open in sid.
>
> I think the later part is already LTS policy since at latest
> Debconf 16. It's up to us to handle things like that.
Let's make this more concrete. Do we have a template? If not, how about:
To: sub...@bugs.debian.org
Subject: ${SOURCE}: CVE-2016-1234: ${CVE_DESCRIPTION}
Source: ${SOURCE}
Version: ${VERSION}
Severity: serious
Tags: security
X-Debbugs-Cc: debian-lts@lists.debian.org
Hi,
The following vulnerabilities have been published for ${SOURCE}:
https://security-tracker.debian.org/tracker/CVE-2016-1234
${CVE_DESCRIPTION}
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
Please adjust the affected versions in the BTS as needed.
Open questions for me are:
a) What Version we submit with? Wheezy's? Or unstable's, and then follow-up
with "found"?
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On Fri, Oct 21, 2016 at 11:14:24AM +0100, Chris Lamb wrote:
> Guido Günther wrote:
>
> > > or at least amend LTS-policies to always file a bug if one fixes a bug
> > > in LTS which is still open in sid.
> >
> > I think the later part is already LTS policy since at latest
> > Debconf 16. It's up to us to handle things like that.
>
> Let's make this more concrete. Do we have a template? If not, how about:
>
>
> To: sub...@bugs.debian.org
> Subject: ${SOURCE}: CVE-2016-1234: ${CVE_DESCRIPTION}
>
> Source: ${SOURCE}
> Version: ${VERSION}
> Severity: serious
> Tags: security
> X-Debbugs-Cc: debian-lts@lists.debian.org
>
> Hi,
>
> The following vulnerabilities have been published for ${SOURCE}:
>
> https://security-tracker.debian.org/tracker/CVE-2016-1234
> ${CVE_DESCRIPTION}
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> Please adjust the affected versions in the BTS as needed.
I'd just use bin/report-vuln ?
> Open questions for me are:
>
> a) What Version we submit with? Wheezy's? Or unstable's, and then follow-up
> with "found"?
I'd say unstable and then "found".
Cheers,
-- Guido
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
Hi
Do we really want LTS mailinglist filled with a lot of unstable bug updates?
I think we should file a bug with unstable version number, but write that
the origin is that it was found in wheezy. Is that the same as "found"
follow up?
The other alternative is that we file the bug with wheezy version number
and then close that one in wheezy-security upload.
If we file the bug with wheezy version number and not closing it in wheezy
upload, then it will look like the issue is still there in bts.
// Ola
On 21 October 2016 at 12:27, Guido Günther wrote:
> On Fri, Oct 21, 2016 at 11:14:24AM +0100, Chris Lamb wrote:
> > Guido Günther wrote:
> >
> > > > or at least amend LTS-policies to always file a bug if one fixes a
> bug
> > > > in LTS which is still open in sid.
> > >
> > > I think the later part is already LTS policy since at latest
> > > Debconf 16. It's up to us to handle things like that.
> >
> > Let's make this more concrete. Do we have a template? If not, how about:
> >
> >
> > To: sub...@bugs.debian.org
> > Subject: ${SOURCE}: CVE-2016-1234: ${CVE_DESCRIPTION}
> >
> > Source: ${SOURCE}
> > Version: ${VERSION}
> > Severity: serious
> > Tags: security
> > X-Debbugs-Cc: debian-lts@lists.debian.org
> >
> > Hi,
> >
> > The following vulnerabilities have been published for ${SOURCE}:
> >
> > https://security-tracker.debian.org/tracker/CVE-2016-1234
> > ${CVE_DESCRIPTION}
> >
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> >
> > Please adjust the affected versions in the BTS as needed.
>
> I'd just use bin/report-vuln ?
>
> > Open questions for me are:
> >
> > a) What Version we submit with? Wheezy's? Or unstable's, and then
> follow-up
> > with "found"?
>
> I'd say unstable and then "found".
> Cheers,
> -- Guido
>
>
--
--- 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 /
---
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
Guido Günther wrote: > I'd just use bin/report-vuln ? … one of these days I'm going to look at everything in bin/* and actually remember what it does :) (Yay, for saving myself writing such a thing!) > I'd say unstable and then "found". How come, out of interest? AIUI the tradeoff here is that if the "found" step gets skipped, the BTS does not believe it is vulnerable and thus it won't get (correctly) kicked out of testing, etc. etc. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
openjdk-7 CVEs
Hi, openjdk-7 is unclaimed in dla-needed.txt but I wonder if you guys have already a plans for fixing these. Cherry-picking patches or waiting for a new Iced Tea release? Since Wheezy and Jessie currently ship the same version I could prepare the update. Cheers, -- Guido
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
Am 20.10.2016 um 18:31 schrieb 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. >> >> 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. It's true that sponsors donate their money for getting security vulnerabilites fixed in *Wheezy* (or whatever oldstable is at the moment), but in my eyes a bugreport about these very security vulnerabilites could be seen as part of the LTS work. I don't even think that we explicitly have to ask for permission here. Isn't it more about the workflow we agree on in Debian regarding security vulnerabilites? So far the agreed practice (and prefered by the Security Team) is to first report the bugs against the version in unstable (if this version is vulnerable as well). And as this is the common workflow in our project, triaging security vulnerabilites as part of the paid LTS work should include reporting these bugs, no? >> 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. The upload to wheezy-security will not get lost, but the security vulnerability might not get tracked further. If we write a bugreport, it's ensured that the maintainer(s) are aware of the vulnerability. So if the Security Team doesn't disagree, I'm much in favour of doing the bug reporting against unstable as part of the LTS Team work. If we can use their template for doing so, even better. Cheers, jonas
Re: openjdk-7 CVEs
On Fri, Oct 21, 2016 at 02:54:18PM +0200, Guido Günther wrote: > Hi, > openjdk-7 is unclaimed in dla-needed.txt but I wonder if you guys have > already a plans for fixing these. Cherry-picking patches or waiting for > a new Iced Tea release? Since Wheezy and Jessie currently ship the same > version I could prepare the update. > Cheers, > -- Guido > I also could help (once I finish the ghostscript LTS update). I have prepared the last several LTS updates for ICU, which have typically involved digging through the commits to the JDK source to identify and then backport the proper fixes. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com
Re: openjdk-7 CVEs
On 21.10.2016 14:54, Guido Günther wrote: > Hi, > openjdk-7 is unclaimed in dla-needed.txt but I wonder if you guys have > already a plans for fixing these. Cherry-picking patches or waiting for > a new Iced Tea release? Since Wheezy and Jessie currently ship the same > version I could prepare the update. > Cheers, > -- Guido We usually backport the OpenJDK releases which are prepared in experimental. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: fixing in oldstable before unstable (was Re: Wheezy update of tre?)
On 21.10.2016 14:57, Jonas Meurer wrote: > Am 20.10.2016 um 18:31 schrieb Markus Koschany: >> On 20.10.2016 17:15, Holger Levsen wrote: [...] >>> 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. > > The upload to wheezy-security will not get lost, but the security > vulnerability might not get tracked further. If we write a bugreport, > it's ensured that the maintainer(s) are aware of the vulnerability. > > So if the Security Team doesn't disagree, I'm much in favour of doing > the bug reporting against unstable as part of the LTS Team work. If we > can use their template for doing so, even better. We were talking about making it mandatory to _fix_ CVEs in unstable first. I totally agree with submitting bug reports against affected packages as part of the LTS workflow. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: openjdk-7 CVEs
On Fri, Oct 21, 2016 at 03:02:26PM +0200, Markus Koschany wrote: > On 21.10.2016 14:54, Guido Günther wrote: > > Hi, > > openjdk-7 is unclaimed in dla-needed.txt but I wonder if you guys have > > already a plans for fixing these. Cherry-picking patches or waiting for > > a new Iced Tea release? Since Wheezy and Jessie currently ship the same > > version I could prepare the update. > > Cheers, > > -- Guido > > We usually backport the OpenJDK releases which are prepared in experimental. Feel free to claim it then - I'll grab another one. Cheers, -- Guido
Re: openjdk-7 CVEs
On 21.10.2016 15:07, Guido Günther wrote: > On Fri, Oct 21, 2016 at 03:02:26PM +0200, Markus Koschany wrote: >> On 21.10.2016 14:54, Guido Günther wrote: >>> Hi, >>> openjdk-7 is unclaimed in dla-needed.txt but I wonder if you guys have >>> already a plans for fixing these. Cherry-picking patches or waiting for >>> a new Iced Tea release? Since Wheezy and Jessie currently ship the same >>> version I could prepare the update. >>> Cheers, >>> -- Guido >> >> We usually backport the OpenJDK releases which are prepared in experimental. > > Feel free to claim it then - I'll grab another one. > Cheers, > -- Guido Please don't get me wrong. I just wanted to point out that we don't/can't backport patches because Oracle is rather secretive in this regard. Normally the OpenJDK maintainer uploads a new release to experimental and we backport and test it then on Wheezy. So please go ahead with the update. PS.: I'm subscribed to debian-lts. Cheers, Markus signature.asc Description: OpenPGP digital signature
Re: Call for advice and testing of nss (and nspr) and intention to upload correction
Hi Guido Thanks a lot for the information. I'll enable this and will also run abi-compliance check tool. Is it this [1] one you have used? [1] https://lvc.github.io/abi-compliance-checker/ Best regards // Ola On 20 October 2016 at 23:48, Guido Günther wrote: > 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 > > > -- --- 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 / ---
Re: Call for advice and testing of nss (and nspr) and intention to upload correction
On Fri, Oct 21, 2016 at 11:16:54PM +0200, Ola Lundqvist wrote: > Hi Guido > > Thanks a lot for the information. I'll enable this and will also run > abi-compliance check tool. > Is it this [1] one you have used? > > [1] https://lvc.github.io/abi-compliance-checker/ IIRC I've used the abi-compliance-checker Debian package. Cheers, -- Guido > > Best regards > > // Ola > > On 20 October 2016 at 23:48, Guido Günther wrote: > > > 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 > > > > > > > > > -- > --- 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 / > ---
