Re: Unsupported packages for Wheezy LTS

2015-11-04 Thread Mike Hommey
On Wed, Nov 04, 2015 at 05:44:36PM +0100, Raphael Hertzog wrote:
> [ Many people are on copy, please trim the list as appropriate when you reply 
> ]
> 
> On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote:
> > These need to be discussed, since they will be a significant
> > time drain (e.g. are they in the sponsors's interests?). They
> > are supportable, but it will take a lot of work and sometimes
> > special domain knowledge:
> > 
> > icedove
> > iceweasel
> > qemu
> > qemu-kvm
> > xen
> > libvirt
> > ffmpeg -> libav
> > vlc
> > rails -> several split packages (only the 3.2 packages are supported in 
> > wheezy)
> 
> Nobody commented here but I believe that we should aim to support them.
> Except vlc, they are all used by some of the current sponsors (even though
> they are not currently supported in squeeze).
> 
> It would be good to identify Debian maintainers with the required "special
> domain knowledge" for all those packages so that they can be paid to
> take care of those packages when the need arises (cf
> https://www.freexian.com/services/debian-lts-details.html#join for
> details about requirement for paid contributors).

Speaking for iceweasel, backports to wheezy are not a significant
overhead compared to packaging for unstable and stable-security.

With that being said, the fact that we're backporting new upstream
ESR releases is going to have its own problems sooner or later, related
to the toolchains. First and foremost, while GCC 4.7 is the current
minimum version supported, it's likely to become GCC 4.8 in the near
future, because of some wanted C++11/C++14 features. Second, Firefox is
soon going to require the rust compiler, which we have no package for
except in unstable.

So there should be a discussion about what we do about those toolchains
first (and that's a broader discussion to have than LTS).

Mike



Re: Unsupported packages for Wheezy LTS

2015-11-04 Thread Guido Günther
Hi,

On Wed, Nov 04, 2015 at 05:44:36PM +0100, Raphael Hertzog wrote:
> [ Many people are on copy, please trim the list as appropriate when you reply 
> ]
> 
> On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote:
> > These need to be discussed, since they will be a significant
> > time drain (e.g. are they in the sponsors's interests?). They
> > are supportable, but it will take a lot of work and sometimes
> > special domain knowledge:
> > 
> > icedove
> > iceweasel
> > qemu
> > qemu-kvm
> > xen
> > libvirt
> > ffmpeg -> libav
> > vlc
> > rails -> several split packages (only the 3.2 packages are supported in 
> > wheezy)
> 

For wheezy I think it would be possible to maintain libvirt. Especially
if we don't support all hypervisors in Wheezy. I could probably set
aside the extra time given enough advanced notice when the LTS team
takes over Wheezy.

Should we decide to support e.g. KVM via backports this would change the
picture since there are usually always changes needed for e.g. newer
qemu-kvm versions, some of them being very intrusive.

For qemu/qemu-kvm I'm not so sure given the large amount of dependencies
and code changes between versions. It would be great to hear what
Michael things about this.

Cheers,
 -- Guido



Re: Using the same nss in all suites

2015-11-04 Thread Mike Hommey
On Thu, Nov 05, 2015 at 08:25:47AM +0100, Guido Günther wrote:
> Hi,
> 
> Backporting fixes for nss can become a challenge over time due to:
> 
> * Bugs related to MFAs (often containing test cases) being restricted so
>   one can only look at hg and try to find all the relevant commits.
> 
> * The library has rather frequent security updates
> 
> * The code diverges over the years
> 
> 
> I haven't found an explicit statement about ABI stability on the nss
> site but RedHat and others seem to be doing fine with always using the
> latest version in all suites and I wonder if we should do the same. This
> would probably include updating the nspr dependency from time to time
> too.
> 
> I wonder what's the maintainers and security teams stance on this?
> Should we do this? Should we start with this during Jessie? If so I
> would be happy to prepare packages for the different distributions and
> do some testing.

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.
The biggest issue with NSS version bumps is that defaults change, such
as cyphers, protocols, etc. That can have unexpected consequences on
existing setups.

Mike



Re: Unsupported packages for Wheezy LTS

2015-11-04 Thread Moritz Muehlenhoff
On Thu, Nov 05, 2015 at 06:47:03AM +0900, Mike Hommey wrote:
> First and foremost, while GCC 4.7 is the current
> minimum version supported, it's likely to become GCC 4.8 in the near
> future, because of some wanted C++11/C++14 features. 

That problem also bit us with chromium in wheezy. Introducing an updated
g++ isn't simple since libstdc++ is also built from the source package.

> Second, Firefox is
> soon going to require the rust compiler, which we have no package for
> except in unstable.

I'd say lets ask the maintainers (and stable release managers) to 
introduce it in the next jessie point release.

Cheers,
Moritz



Re: Unsupported packages for Wheezy LTS

2015-11-04 Thread Guido Günther
Hi,
On Wed, Nov 04, 2015 at 05:44:36PM +0100, Raphael Hertzog wrote:
> [ Many people are on copy, please trim the list as appropriate when you reply 
> ]
> 
> On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote:
> > These need to be discussed, since they will be a significant
> > time drain (e.g. are they in the sponsors's interests?). They
> > are supportable, but it will take a lot of work and sometimes
> > special domain knowledge:
> > 
> > icedove
> > iceweasel
> > qemu
> > qemu-kvm
> > xen
> > libvirt
> > ffmpeg -> libav
> > vlc
> > rails -> several split packages (only the 3.2 packages are supported in 
> > wheezy)
> 
> Nobody commented here but I believe that we should aim to support them.
> Except vlc, they are all used by some of the current sponsors (even though
> they are not currently supported in squeeze).
> 
> It would be good to identify Debian maintainers with the required "special
> domain knowledge" for all those packages so that they can be paid to
> take care of those packages when the need arises (cf
> https://www.freexian.com/services/debian-lts-details.html#join for
> details about requirement for paid contributors).
> 
> Thus putting the respective maintainers/maintainance team in copy (Mike
> Hommey for iceweasel, Guido Günther for multiple package, Christop Göhre for 
> Icedove,
> Aurelien Jarno, Riku Voipio, Vagrant Cascadian for qemu, Michael Tokarev
> for qemu-kvm, Guido Trotter and Bastian Blank for Xen, Laurent Léonard
> for libvirt, Sebastian Ramacher and pkg-multimedia for libav/vlc).
> 
> Do you know someone from the Debian maintenance team or from the upstream
> project which could be hired a few hours from time to time to provide the
> required security updates on the above source packages when it gets too
> complicated for the LTS contributors? Feel free to pass around this email
> if you think of someone and want to inform him/her...

If we do iceweasel then icedove wouldn't be hard on top but I'll let
Christoph and Carsten (added to cc:) comment on this since I've not
done any real Icedove work since ages.

Cheers,
 -- Guido



Re: Unsupported packages for Wheezy LTS

2015-11-04 Thread Dominic Hargreaves
On Wed, Nov 04, 2015 at 05:42:43PM +0100, Raphael Hertzog wrote:
> > movabletype-opensource
> > -> Upstream went closed source, Dominic kept in on life support,
> > should be checked with him
> 
> Dominic, do you think movabletype-opensource can be supported in wheezy
> until May 2018?

No, I would rather not do this: the last open source version went out 
of support at the end of September as far as I can tell from this:

https://movabletype.org/product-life-cycle-policy.html

so there is nothing to backport upstream fixes from any more.
We should send out an EOL notice for wheezy-security too.

Thanks for checking!

Cheers,
Dominic.



Re: squeeze update of nss?

2015-11-04 Thread Raphael Hertzog
Hi,

On Wed, 04 Nov 2015, Mike Hommey wrote:
> (While on the subject, there's another round of Iceweasel security
> updates coming, along with NSPR and NSS fixes, this time)

Yes, I was about to contact you again about those but you are already
aware of them:

For nss:
https://security-tracker.debian.org/tracker/CVE-2015-7181
https://security-tracker.debian.org/tracker/CVE-2015-7182

For nspr:
https://security-tracker.debian.org/tracker/CVE-2015-7183

They are all in our radar.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/



[SECURITY] [DLA-329-2] postgresql-8.4 update corrected

2015-11-04 Thread Christoph Berg
Package: postgresql-8.4
Version: 8.4.22lts5-0+deb6u2

The 8.4.22lts5-0+deb6u1 update failed to build on the i386
architecture because the regression tests were not correctly adapted
for changes in lts5. This has now been corrected, updated binaries for
i386 and amd64 (which were unaffected) have been published.

> Several bugs were discovered in PostgreSQL, a relational database server
> system.  The 8.4 branch is EOLed upstream, but still present in Debian 
> squeeze.
> This new LTS minor version contains the fixes that were applied upstream to 
> the
> 9.0.22 version, backported to 8.4.22 which was the last version officially
> released by the PostgreSQL developers.  This LTS effort for squeeze-lts is a
> community project sponsored by credativ GmbH.
> 
> ## Migration to Version 8.4.22lts5
> 
> A dump/restore is not required for those running 8.4.X.  However, if you are
> upgrading from a version earlier than 8.4.22, see the relevant release notes.
> 
> ## Security Fixes
> 
> Fix contrib/pgcrypto to detect and report too-short crypt salts (Josh
> Kupershmidt)
> 
> Certain invalid salt arguments crashed the server or disclosed a few
> bytes of server memory. We have not ruled out the viability of attacks
> that arrange for presence of confidential information in the disclosed
> bytes, but they seem unlikely. (CVE-2015-5288)

Christoph
-- 
c...@df7cb.de | http://www.df7cb.de/


signature.asc
Description: PGP signature


Re: Unsupported packages for Wheezy LTS

2015-11-04 Thread Raphael Hertzog
[ Many people are on copy, please trim the list as appropriate when you reply ]

On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote:
> as a followup to yesterday's BoF I compared the list of unsupported
> packages in Squeeze LTS against the current status quo:

> Support for these ended in Wheezy already, so unsupported in LTS as well:
> chromium-browser
> typo3-src
> mediawiki (support will cease in April 2016)

For mediawiki, might it not make sense to update to a new upstream version
when upstream supports ends? I know there's an ecosystem of plugins and
stuff like that but having to deal with an upgrade is probably better than
having a Mediawiki with security holes...

> Not covered by security support in normal security support, did
> someone actually check whether this still works in LTS? IMHO
> LTS should be limited to main. We shouldn't endorse the Flash plugin
> in LTS:
> flashplugin-nonfree

I agree that non-free should not be covered.

> Should probably be dropped:
> 
> mantis
> -> No active maintainer for years, has been kept on life support
>via security updates, frequent issues

Ack.

> asterisk
> -> Complicated to update/test, lack of effort by maintainers

Pinging the Asterisk maintainers. Do you think it is realistic to
support asterisk 1.8.13.1 in wheezy until May 2018?

Shall it be excluded from LTS support? Do you think you can support
it through backports?

(I see you have troubles supporting it in unstable/testing already...)

> openswan
> -> Dead upstream, strongswan exists as a supported alternative

Ack.

> movabletype-opensource
> -> Upstream went closed source, Dominic kept in on life support,
> should be checked with him

Dominic, do you think movabletype-opensource can be supported in wheezy
until May 2018?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/



Re: Unsupported packages for Wheezy LTS

2015-11-04 Thread Raphael Hertzog
Hello,

On Wed, 16 Sep 2015, Raphael Hertzog wrote:
> On Tue, 25 Aug 2015, Holger Levsen wrote:
> > > In addition it would make sense to exclude the OpenStack packages
> > > in wheezy, they are fully unsupported upstream und very unlikely
> > > to be used since OpenStack is evolving so fast. You should discuss
> > > that with Thomas Goirand.
> > 
> > Thomas, what's your stance on this?

While Thomas did not reply directly, I discussed with him on IRC and he
confirmed me that he already has troubles supporting OpenStack in the
current stable releases, so expecting to support OpenStack for 5 years
is not realistic.

I thus suggest to exclude OpenStack packages from LTS support.

Thomas, can you provide us the list of the corresponding source packages?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/



Re: Unsupported packages for Wheezy LTS

2015-11-04 Thread Raphael Hertzog
[ Many people are on copy, please trim the list as appropriate when you reply ]

On Wed, 19 Aug 2015, Moritz Muehlenhoff wrote:
> These need to be discussed, since they will be a significant
> time drain (e.g. are they in the sponsors's interests?). They
> are supportable, but it will take a lot of work and sometimes
> special domain knowledge:
> 
> icedove
> iceweasel
> qemu
> qemu-kvm
> xen
> libvirt
> ffmpeg -> libav
> vlc
> rails -> several split packages (only the 3.2 packages are supported in 
> wheezy)

Nobody commented here but I believe that we should aim to support them.
Except vlc, they are all used by some of the current sponsors (even though
they are not currently supported in squeeze).

It would be good to identify Debian maintainers with the required "special
domain knowledge" for all those packages so that they can be paid to
take care of those packages when the need arises (cf
https://www.freexian.com/services/debian-lts-details.html#join for
details about requirement for paid contributors).

Thus putting the respective maintainers/maintainance team in copy (Mike
Hommey for iceweasel, Guido Günther for multiple package, Christop Göhre for 
Icedove,
Aurelien Jarno, Riku Voipio, Vagrant Cascadian for qemu, Michael Tokarev
for qemu-kvm, Guido Trotter and Bastian Blank for Xen, Laurent Léonard
for libvirt, Sebastian Ramacher and pkg-multimedia for libav/vlc).

Do you know someone from the Debian maintenance team or from the upstream
project which could be hired a few hours from time to time to provide the
required security updates on the above source packages when it gets too
complicated for the LTS contributors? Feel free to pass around this email
if you think of someone and want to inform him/her...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/



Accepted postgresql-8.4 8.4.22lts5-0+deb6u2 (source all i386) into squeeze-lts

2015-11-04 Thread Christoph Berg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 04 Nov 2015 11:48:05 +0100
Source: postgresql-8.4
Binary: libpq-dev libpq5 libecpg6 libecpg-dev libecpg-compat3 libpgtypes3 
postgresql-8.4 postgresql-client-8.4 postgresql-server-dev-8.4 
postgresql-doc-8.4 postgresql-contrib-8.4 postgresql-plperl-8.4 
postgresql-plpython-8.4 postgresql-pltcl-8.4 postgresql postgresql-client 
postgresql-doc postgresql-contrib
Architecture: source all i386
Version: 8.4.22lts5-0+deb6u2
Distribution: squeeze-lts
Urgency: medium
Maintainer: Debian PostgreSQL Maintainers 

Changed-By: Christoph Berg 
Description: 
 libecpg-compat3 - older version of run-time library for ECPG programs
 libecpg-dev - development files for ECPG (Embedded PostgreSQL for C)
 libecpg6   - run-time library for ECPG programs
 libpgtypes3 - shared library libpgtypes for PostgreSQL 8.4
 libpq-dev  - header files for libpq5 (PostgreSQL library)
 libpq5 - PostgreSQL C client library
 postgresql - object-relational SQL database (supported version)
 postgresql-8.4 - object-relational SQL database, version 8.4 server
 postgresql-client - front-end programs for PostgreSQL (supported version)
 postgresql-client-8.4 - front-end programs for PostgreSQL 8.4
 postgresql-contrib - additional facilities for PostgreSQL (supported version)
 postgresql-contrib-8.4 - additional facilities for PostgreSQL
 postgresql-doc - documentation for the PostgreSQL database management system
 postgresql-doc-8.4 - documentation for the PostgreSQL database management 
system
 postgresql-plperl-8.4 - PL/Perl procedural language for PostgreSQL 8.4
 postgresql-plpython-8.4 - PL/Python procedural language for PostgreSQL 8.4
 postgresql-pltcl-8.4 - PL/Tcl procedural language for PostgreSQL 8.4
 postgresql-server-dev-8.4 - development files for PostgreSQL 8.4 server-side 
programming
Changes: 
 postgresql-8.4 (8.4.22lts5-0+deb6u2) squeeze-lts; urgency=medium
 .
   * Fix regression test failure on i386.
   * Update watchfile to look at github.
Checksums-Sha1: 
 414d6c40e4fb670a5ecd69c50244957460dab6fd 3374 
postgresql-8.4_8.4.22lts5-0+deb6u2.dsc
 f8d67687dcd1ddd0c5aea5c2fb6bce7451e77e24 76941 
postgresql-8.4_8.4.22lts5-0+deb6u2.diff.gz
 b2ccad5caf21edd9550163b390611cae44f58cbc 2249404 
postgresql-doc-8.4_8.4.22lts5-0+deb6u2_all.deb
 8224dc8beb1d9b16fce24e7f6dd8419716006ff2 36934 
postgresql_8.4.22lts5-0+deb6u2_all.deb
 dacfb8b63ea064e86e5ee3ab039dc58acf416498 36906 
postgresql-client_8.4.22lts5-0+deb6u2_all.deb
 407ced00feb928f0970acfb8766eb9a7da9a645d 36748 
postgresql-doc_8.4.22lts5-0+deb6u2_all.deb
 b10eeb9f1f91263951d4fb3fc8e664e2dbe1d87f 36804 
postgresql-contrib_8.4.22lts5-0+deb6u2_all.deb
 c7aa89bb521fa69853f5c1ee37a9d54fffe353b6 249878 
libpq-dev_8.4.22lts5-0+deb6u2_i386.deb
 560fe9fc502c2e03710d4ec17031d29534795c1d 171696 
libpq5_8.4.22lts5-0+deb6u2_i386.deb
 48eb9b3c3b4ffc27166047425d8835825092fc9d 115358 
libecpg6_8.4.22lts5-0+deb6u2_i386.deb
 243e6f24a87678308543d0ea7082cd0923c83514 260066 
libecpg-dev_8.4.22lts5-0+deb6u2_i386.deb
 162afa9ca22a1b5009e14e8c09eff9344d92f9e4 43722 
libecpg-compat3_8.4.22lts5-0+deb6u2_i386.deb
 842e7ae23a1fea59b8fee959499b1ee9f6ab0ba8 67408 
libpgtypes3_8.4.22lts5-0+deb6u2_i386.deb
 a2292c68b48dd4dd074d86f7e36eb44c9436ed5d 5638322 
postgresql-8.4_8.4.22lts5-0+deb6u2_i386.deb
 b89663256e371a2850d6b84c6cd26d8cd71cbb14 1562414 
postgresql-client-8.4_8.4.22lts5-0+deb6u2_i386.deb
 edf38e6d5319a012ebab83ddf36e6ca2f0f700ae 658136 
postgresql-server-dev-8.4_8.4.22lts5-0+deb6u2_i386.deb
 99f59e4e5d2182ec3ffa6b05cfd45495cf0f 409286 
postgresql-contrib-8.4_8.4.22lts5-0+deb6u2_i386.deb
 658469bfca46b826bf90791e0d3b4c567fa98783 73896 
postgresql-plperl-8.4_8.4.22lts5-0+deb6u2_i386.deb
 3d8345b3859b85f42c93d52475445d2333093c0d 74364 
postgresql-plpython-8.4_8.4.22lts5-0+deb6u2_i386.deb
 864b77afd3c954932b62b8aa06f5d7cb58437307 59544 
postgresql-pltcl-8.4_8.4.22lts5-0+deb6u2_i386.deb
Checksums-Sha256: 
 471881cc536094bd52afb0220caef503abb67bec72f6d77353da2a039ac4d9c8 3374 
postgresql-8.4_8.4.22lts5-0+deb6u2.dsc
 b5da9a7987cb7444c0f0453268cfe924dd38c4dd467dc38f38de5b6466e6719b 76941 
postgresql-8.4_8.4.22lts5-0+deb6u2.diff.gz
 05539ca5a036bff045fc260710235d0eb07b0a2b4d744378f467906d9f82c096 2249404 
postgresql-doc-8.4_8.4.22lts5-0+deb6u2_all.deb
 b5bcca11d0139679fcca8cb6f6186d1fccc7ce78201f0464785127b67cedb849 36934 
postgresql_8.4.22lts5-0+deb6u2_all.deb
 737d403f40726920a109f15f8c9b294c750d24bd71c07ea34de53b446fd63369 36906 
postgresql-client_8.4.22lts5-0+deb6u2_all.deb
 28d2cc449b32150cf4867bfddcede5686ffa00f1287ac7ccd154a7032cca2791 36748 
postgresql-doc_8.4.22lts5-0+deb6u2_all.deb
 d02ea01e58574b21e7a0c2c2b01cca48f0dde62f823bd54cd821e649851e8a91 36804 
postgresql-contrib_8.4.22lts5-0+deb6u2_all.deb
 588339f4beb48a31858eaa055dbf3fc2b4a9de12a34ea5edb838a1ef185608c3 249878 
libpq-dev_8.4.22lts5-0+deb6u2_i386.deb