wheezy-specific bind9 issue

While trying to write a reproducer for CVE-2016-2776, I discovered that the 1:9.8.4.dfsg.P1-6+nmu2+deb7u10 version in wheezy would crash, while unpatched jessie and upstream would not: This might be due to an incomplete fix for CVE-2015-

Re: NMU debsecan for wheezy

* Guido Günther: > I'd like to update debsecan in Wheezy to fix #842428 with the attached > debdiff and put out a corresponding DLA. O.k. ? Sure, please go ahead. Thanks for doing this.

Re: Better communication about spectre/meltdown

* Emilio Pozuelo Monfort: > Your new GCC builds binaries such as libgcc1 and libstdc++6. That is > going to affect nearly all the archive at runtime, and I wonder if > it's the right approach. We introduced GCC 4.8 in wheezy, named > gcc-mozilla (a bad name I know) which didn't build these librari

Re: squeeze-lts and the security tracker

* Moritz Muehlenhoff: > There's an additional caveat which I missed so far: The Security Tracker > needs to parse the Packages file of squeeze-lts. > > I'm adding Florian Weimer to CC, can you please add this to the tracker? First, I need a definite list of source.list en

Re: squeeze-lts and the security tracker

* Holger Levsen: > Having the oldstable tracker working would be really useful to pick packages > to work on... > > Isn't it just 5m work for you to enable it? There's some code that assumes that oldstable has a security archive, which is not quite true for LTS. The LTS archive has to be configu

Re: Glassfish security support (in Squeeze)

* Emmanuel Bourg: > - CVE-2013-3827 is related to Java Server Faces, but I couldn't find any > code related to JSF (grep -R 'import javax.faces') This is probably about the components imported from Mojarra into Glassfish. -- To UNSUBSCRIBE, email to debian-lts-requ...@lists.debian.org with a s

Re: End of life for MySQL 5.1

* Raphael Hertzog: >> - Try to backport fixes based on the 5.5.x interdiffs (since Oracle >> publishes no detailed bug details). Complicated, but could be done >> in collaboration with Red Hat, RHEL 6 is also based on MySQL 5.1. > > Do we have contacts at RedHat to discuss such plans ? Florian

Re: End of life for MySQL 5.1

* Raphael Hertzog: > Hi, > > On Tue, 27 Jan 2015, Florian Weimer wrote: >> * Raphael Hertzog: >> >> >> - Try to backport fixes based on the 5.5.x interdiffs (since Oracle >> >> publishes no detailed bug details). Complicated, but could be done >

Re: TLSv1.2 needed in Debian 6 LTS

* Disch Services GmbH: > To sum this up: we need Debian 6 LTS with TLSv1.2 (i.e. with a recent > OpenSSL implemenation). Alternatively, you could set up proxies running wheezy and continue to use a squeeze-based core infrastructure. HTTPS has very good support for this, but for SMTP and IMAP, it

Re: [debian-lts] file package

* Christoph Biedl: > And that's a bad thing. The maintainer very likely has more experience > with the package than anybody else, and also with the packaging. Knows > the gotchas in the code. Has out-of-tree test suites, and better > connections to upstream. Part of the LTS deal was that it would

Re: glusterfs setuid issue

* Ben Hutchings: > - Since Linux 3.1 setuid() never fails because of the process limit. > Thus wheezy and jessie should be unaffected, even if there's some > flaw in the first two points. I think with user namespace support at least, setuid can allocate memory, which can fail. But it's of co

Re: Using the same nss in all suites

* Mike Hommey: > On ABI stability, both NSPR and NSS have a very strict policy. NSPR > receives very few ABI changes, and it's only adding new functions. NSS > has much more ABI changes, but also only adding new functions. This is incorrect, there have been unplanned ABI changes related to SSL_Im

Re: Using the same nss in all suites

* Guido Günther: > On Thu, Nov 05, 2015 at 09:00:51PM +0100, Florian Weimer wrote: >> * Mike Hommey: >> > The biggest issue with NSS version bumps is that defaults change, >> > such as cyphers, protocols, etc. That can have unexpected >> > consequences on

Re: Using the same nss in all suites

* Moritz Muehlenhoff: (NSS backwards compatibility) >> Yes, for mere backporting of new versions, this can be helpful. > > OTOH, new Iceweasel ESR releases also deprecate insecure crypto features, > so doing the same in nss seems somewhat acceptable to me. NSS is far more radical than that: Upst

Re: Using the same nss in all suites

* Guido Günther: > One thing though is that we don't have a DSA for announcing the new > nss version in the point release but we don't have this for other > packages either. Did this turn out to be problematic for other packages > in the past that switch to new version in a point release? I don't

Re: Wheezy update of quagga?

* Santiago Ruano Rincón: > the Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of quagga: > https://security-tracker.debian.org/tracker/source-package/quagga > > Would you like to take care of this yourself? I suggest to wait until upstream h