Re: Xen 4.1.6.1 backport + Ubuntu patches ready for testing (take 3)

2016-05-09 Thread Brian May 
Antoine Beaupré  writes:

> So there's *another* escalation through Qemu/HVM to backport. I wonder
> if it's worth postponing this upload?
>
> I have had good feedback about the above binary packages, by the
> way. They can be considered tested and working - unfortunately, I will
> not have time to followup on those until next week so I hope others can
> pick this up!

I think it might be worth uploading what he have, and then fixing this
security issue in another upload.
-- 
Brian May

Re: Wheezy update of ikiwiki?

2016-05-09 Thread Markus Koschany 
Am 10.05.2016 um 00:25 schrieb Simon McVittie:
> On Tue, 10 May 2016 at 00:06:01 +0200, Markus Koschany wrote:
>> Am 09.05.2016 um 23:51 schrieb Simon McVittie:
>>> I've uploaded a second test version, fixing a regression
>>
>> Looks manageable to me. Please go ahead.
> 
> Uploaded. I would appreciate it if someone from the LTS team prepares
> the DLA; it should probably look remarkably similar to DSA-3571.

I'll take care of that.

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of ikiwiki?

2016-05-09 Thread Simon McVittie 
On Tue, 10 May 2016 at 00:06:01 +0200, Markus Koschany wrote:
> Am 09.05.2016 um 23:51 schrieb Simon McVittie:
> > I've uploaded a second test version, fixing a regression
> 
> Looks manageable to me. Please go ahead.

Uploaded. I would appreciate it if someone from the LTS team prepares
the DLA; it should probably look remarkably similar to DSA-3571.

S

Re: Wheezy update of ikiwiki?

2016-05-09 Thread Markus Koschany 
Am 09.05.2016 um 23:51 schrieb Simon McVittie:
> On Mon, 09 May 2016 at 20:05:17 +0200, Markus Koschany wrote:
>> Please proceed with the upload to wheezy-security at your leisure.
> 
> I've uploaded a second test version, fixing a regression which I've
> also just fixed in unstable: images with upper-case extensions, such as
> the IMG1234.JPG frequently seen on cameras' FAT filesystems, were not
> accepted. Interdiff attached. Still good to go?
> 
> S

Looks manageable to me. Please go ahead.






signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of ikiwiki?

2016-05-09 Thread Simon McVittie 
On Mon, 09 May 2016 at 20:05:17 +0200, Markus Koschany wrote:
> Please proceed with the upload to wheezy-security at your leisure.

I've uploaded a second test version, fixing a regression which I've
also just fixed in unstable: images with upper-case extensions, such as
the IMG1234.JPG frequently seen on cameras' FAT filesystems, were not
accepted. Interdiff attached. Still good to go?

S
diffstat for ikiwiki-3.20120629.2+deb7u1 ikiwiki-3.20120629.2+deb7u1

 CHANGELOG |7 ---
 IkiWiki/Plugin/img.pm |2 +-
 NEWS  |2 +-
 debian/NEWS   |2 +-
 debian/changelog  |7 ---
 t/img.t   |   12 +---
 6 files changed, 20 insertions(+), 12 deletions(-)

diff -Nru ikiwiki-3.20120629.2+deb7u1/CHANGELOG ikiwiki-3.20120629.2+deb7u1/CHANGELOG
--- ikiwiki-3.20120629.2+deb7u1/CHANGELOG	2016-05-08 16:31:08.0 +0100
+++ ikiwiki-3.20120629.2+deb7u1/CHANGELOG	2016-05-09 22:39:24.0 +0100
@@ -2,14 +2,15 @@
 
   * HTML-escape error messages, in one case avoiding potential cross-site
 scripting (CVE-2016-4561, OVE-20160505-0012)
-  * Update img plugin to version 3.20160506 to mitigate ImageMagick
+  * Update img plugin to version 3.20160509 to mitigate ImageMagick
 vulnerabilities, including remote code execution (CVE-2016-3714):
 - Never convert SVG images to PNG; simply pass them through to the
   browser. This prevents exploitation of any ImageMagick SVG coder
   vulnerabilities. (joeyh)
 - Do not resize image formats other than JPEG, PNG, GIF unless
   specifically configured to do so. This prevents exploitation
-  of any vulnerabilities in less common coders, such as MVG. (smcv)
+  of any vulnerabilities in less common coders, such as MVG.
+  (schmonz, smcv)
 - Do not resize JPEG, PNG, GIF, PDF images if their extensions do
   not match their "magic numbers", because wiki admins might try to
   restrict attachments by extension, but ImageMagick can base its
@@ -29,7 +30,7 @@
 (chrysn, joeyh, schmonz, smcv)
   * debian/tests: add metadata to run the img test as an autopkgtest
 
- -- Simon McVittie   Sun, 08 May 2016 16:30:55 +0100
+ -- Simon McVittie   Mon, 09 May 2016 22:38:35 +0100
 
 ikiwiki (3.20120629.2) wheezy; urgency=medium
 
diff -Nru ikiwiki-3.20120629.2+deb7u1/debian/changelog ikiwiki-3.20120629.2+deb7u1/debian/changelog
--- ikiwiki-3.20120629.2+deb7u1/debian/changelog	2016-05-08 16:31:08.0 +0100
+++ ikiwiki-3.20120629.2+deb7u1/debian/changelog	2016-05-09 22:39:24.0 +0100
@@ -2,14 +2,15 @@
 
   * HTML-escape error messages, in one case avoiding potential cross-site
 scripting (CVE-2016-4561, OVE-20160505-0012)
-  * Update img plugin to version 3.20160506 to mitigate ImageMagick
+  * Update img plugin to version 3.20160509 to mitigate ImageMagick
 vulnerabilities, including remote code execution (CVE-2016-3714):
 - Never convert SVG images to PNG; simply pass them through to the
   browser. This prevents exploitation of any ImageMagick SVG coder
   vulnerabilities. (joeyh)
 - Do not resize image formats other than JPEG, PNG, GIF unless
   specifically configured to do so. This prevents exploitation
-  of any vulnerabilities in less common coders, such as MVG. (smcv)
+  of any vulnerabilities in less common coders, such as MVG.
+  (schmonz, smcv)
 - Do not resize JPEG, PNG, GIF, PDF images if their extensions do
   not match their "magic numbers", because wiki admins might try to
   restrict attachments by extension, but ImageMagick can base its
@@ -29,7 +30,7 @@
 (chrysn, joeyh, schmonz, smcv)
   * debian/tests: add metadata to run the img test as an autopkgtest
 
- -- Simon McVittie   Sun, 08 May 2016 16:30:55 +0100
+ -- Simon McVittie   Mon, 09 May 2016 22:38:35 +0100
 
 ikiwiki (3.20120629.2) wheezy; urgency=medium
 
diff -Nru ikiwiki-3.20120629.2+deb7u1/debian/NEWS ikiwiki-3.20120629.2+deb7u1/debian/NEWS
--- ikiwiki-3.20120629.2+deb7u1/debian/NEWS	2016-05-08 16:31:08.0 +0100
+++ ikiwiki-3.20120629.2+deb7u1/debian/NEWS	2016-05-09 22:39:24.0 +0100
@@ -18,7 +18,7 @@
   can be removed with the new img_allowed_formats setup option.
   See  for more details.
 
- -- Simon McVittie   Sun, 08 May 2016 16:30:55 +0100
+ -- Simon McVittie   Mon, 09 May 2016 22:38:35 +0100
 
 ikiwiki (3.20110122) unstable; urgency=low
 
diff -Nru ikiwiki-3.20120629.2+deb7u1/IkiWiki/Plugin/img.pm ikiwiki-3.20120629.2+deb7u1/IkiWiki/Plugin/img.pm
--- ikiwiki-3.20120629.2+deb7u1/IkiWiki/Plugin/img.pm	2016-05-08 16:31:08.0 +0100
+++ ikiwiki-3.20120629.2+deb7u1/IkiWiki/Plugin/img.pm	2016-05-09 22:39:24.0 +0100
@@ -89,7 +89,7 @@
 	my $extension;
 	my $format;
 
-	if ($base =~ m/\.([a-z0-9]+)$/) {
+	if ($base =~ m/\.([a-z0-9]+)$/is) {
 		$extension = $1;
 	}
 	else {
diff -Nru ikiwiki-3.20120629.2+deb7u1/NEWS ikiwiki-3.20120629.2+deb7u1/NEWS
--- iki

Re: Wheezy update of roundcube?

2016-05-09 Thread Sandro Knauß 
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.

Re: Wheezy update of ikiwiki?

2016-05-09 Thread Markus Koschany 
Am 09.05.2016 um 19:50 schrieb Simon McVittie:
[...]
>> This used to work with the current version in Wheezy. Is this
>> intentional or a regression?
> 
> There was no option of that name in the current version in Wheezy. All
> versions prior to last Friday effectively had the same behaviour as if you
> used
> 
> img_allowed_formats: [everything]
> 
> in the updated version.
> 
> When you tried it, it "worked" in the sense that it was accepted and
> ignored like any other unimplemented setting, exactly as though you
> had written
> 
> permissive format is permissive: 'yes, this'
> 
> in your setup file :-)
> 

OK. True I installed the old version first, then the new version but
then I also used ikiwiki --setup /etc/ikiwiki/auto.setup with the new
one. Makes sense now. :)

Please proceed with the upload to wheezy-security at your leisure.

Markus



signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of ikiwiki?

2016-05-09 Thread Simon McVittie 
On Mon, 09 May 2016 at 19:34:37 +0200, Markus Koschany wrote:
> However when I edit test.setup and edit
> 
> img_allowed_formats: 'png, jpeg'
> 
> because I want to be even more restrictive I get the following error
> message:
> 
> Error: Can't use string ("png, jpeg") as an ARRAY ref while "strict
> refs" in use at /usr/share/perl5/IkiWiki/Plugin/img.pm line 39

It's meant to be a YAML list, you've set it to a string. The correct
syntax is, for example, any of

img_allowed_formats: [png, jpeg]

img_allowed_formats: ["PNG", "JPEG"]

img_allowed_formats:
- png
- jpeg

 describes one form of correct
syntax. I didn't include documentation updates in the wheezy update to keep it
minimal.

> This used to work with the current version in Wheezy. Is this
> intentional or a regression?

There was no option of that name in the current version in Wheezy. All
versions prior to last Friday effectively had the same behaviour as if you
used

img_allowed_formats: [everything]

in the updated version.

When you tried it, it "worked" in the sense that it was accepted and
ignored like any other unimplemented setting, exactly as though you
had written

permissive format is permissive: 'yes, this'

in your setup file :-)

S

Re: Wheezy update of ikiwiki?

2016-05-09 Thread Markus Koschany 
Am 08.05.2016 um 23:58 schrieb Simon McVittie:
[...]
> Note that I haven't done any real-world testing on this version, because
> I haven't run wheezy since around the time jessie was released, and my
> production ikiwiki instances use the latest upstream release from
> jessie-backports. t/img.t passes in autopkgtest and an SVG [[!img]]
> in the documentation still works, though.
[...]

Hi,

thanks for preparing this update. I installed the new version on my
wheezy box, set up a wiki and did some smoke testing.

When I use the default settings the following works as expected and the
image is shown

[[!img test.png]]

However when I edit test.setup and edit

img_allowed_formats: 'png, jpeg'

because I want to be even more restrictive I get the following error
message:

Error: Can't use string ("png, jpeg") as an ARRAY ref while "strict
refs" in use at /usr/share/perl5/IkiWiki/Plugin/img.pm line 39

This used to work with the current version in Wheezy. Is this
intentional or a regression?

The rest looks good to me and I think we can proceed with an upload to
wheezy-security if the error message above is a feature and not a bug.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Re: icu package and debdiff [new contributor, first attempt]

2016-05-09 Thread Roberto C . Sánchez 
Hi Markus,

On Mon, May 09, 2016 at 05:09:30PM +0200, Markus Koschany wrote:
> Hello Roberto, welcome on board!
> 

Thanks!

> Am 08.05.2016 um 05:34 schrieb Roberto C. Sánchez:
> > Hi All,
> > 
> > I'm still "in-training" and I thought I would attempt to prepare an
> > upload of the icu package for wheezy.
> > 
> > The package is here: https://people.debian.org/~roberto/
> > dsc - https://people.debian.org/~roberto/icu_4.8.1.1-12+deb7u4.dsc
> > debdiff - 
> > https://people.debian.org/~roberto/icu_4.8.1.1-12+deb7u3_deb7u4.diff
> 
> I couldn't download the package with dget -x because the original
> tarball is currently missing, so I used the debdiff.
> 
I seem to have overlooked the original tarball.  I went ahead and
uploaded it so that the .dsc is retrievable with dget.

> > I would appreciate a review of the package by someone knowledgable
> > and experienced with LTS support to make sure I handled it correctly.
> > Please read on for details of the steps I took.
> > 
> > Based on the information I found on the security tracker, there are
> > three vulnerabilities affecting icu in wheezy: CVE-2015-2632,
> > CVE-2015-4844, and CVE-2016-0494.
> > 
> > I pulled the patch for CVE-2015-2632 from the icu package in unstable,
> > which has been fixed.
> 
> That's a sensible approach. In this case the patch applied cleanly for
> the version in Wheezy but sometimes you have to be more careful when the
> code is considerably different.
> 
I understand.

> > I pulled the patch for CVE-2015-4844 from the upstream jdk8u project
> > (based on the commit reference in openjdk-8's debian/changelog).  I
> > confirmed that this fix matched what was done by upstream in their
> > subversion repository.
> > 
> > I pulled the patch for CVE-2016-0494 from the upstream jdk8u project
> > (based on the commit reference in openjdk-8's debian/changelog).  I
> > attempted to confirm this fix in upstream's subversion repository, but
> > it appears to not have been fixed upstream yet.
> 
> Antoine (anarcat) fixed this issue for Squeeze LTS and he also left some
> comments at
> 
> https://ssl.icu-project.org/trac/ticket/12020
> 
> He also changed the runConfigure script and his patch for CVE-2016-0494
> looks different to me. Perhaps you should contact him (or he will simply
> respond to this message because he is subscribed too), discuss this
> patch with him and ask him why his approach contains more changes than
> the original upstream commit at
> 
> http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f556d4c82ef1
> 
OK.  I likely will not be able to do anything with this today, so if he
responds then I will follow his guidance.  Otherwise, I'll have another
look tomorrow and then contact Antoine.

> > I built the package in a wheezy chroot, signed the resulting package,
> > and uploaded it (along with the debdiff between the prior version and my
> > updated package) to the above location.
> 
> That's fine. You don't have to upload a new revision to
> people.debian.org but it is a useful approach if you want to get more
> feedback for your patches. You could also:
> 
> * Check the output of the test suite (if it exists)
> * Write your own tests or ask upstream for advice how to test the issue
> * Contact upstream and ask for code reviews
> * Try the reproducer with the old and new version (if it exists)
> * Install the package, do some smoke testing and try to verify if the
>   update didn't introduce any regressions
> 
I'll attempt some of these tomorrow as well.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: icu package and debdiff [new contributor, first attempt]

2016-05-09 Thread Markus Koschany 
Hello Roberto, welcome on board!

Am 08.05.2016 um 05:34 schrieb Roberto C. Sánchez:
> Hi All,
> 
> I'm still "in-training" and I thought I would attempt to prepare an
> upload of the icu package for wheezy.
> 
> The package is here: https://people.debian.org/~roberto/
> dsc - https://people.debian.org/~roberto/icu_4.8.1.1-12+deb7u4.dsc
> debdiff - https://people.debian.org/~roberto/icu_4.8.1.1-12+deb7u3_deb7u4.diff

I couldn't download the package with dget -x because the original
tarball is currently missing, so I used the debdiff.

> I would appreciate a review of the package by someone knowledgable
> and experienced with LTS support to make sure I handled it correctly.
> Please read on for details of the steps I took.
> 
> Based on the information I found on the security tracker, there are
> three vulnerabilities affecting icu in wheezy: CVE-2015-2632,
> CVE-2015-4844, and CVE-2016-0494.
> 
> I pulled the patch for CVE-2015-2632 from the icu package in unstable,
> which has been fixed.

That's a sensible approach. In this case the patch applied cleanly for
the version in Wheezy but sometimes you have to be more careful when the
code is considerably different.

> I pulled the patch for CVE-2015-4844 from the upstream jdk8u project
> (based on the commit reference in openjdk-8's debian/changelog).  I
> confirmed that this fix matched what was done by upstream in their
> subversion repository.
> 
> I pulled the patch for CVE-2016-0494 from the upstream jdk8u project
> (based on the commit reference in openjdk-8's debian/changelog).  I
> attempted to confirm this fix in upstream's subversion repository, but
> it appears to not have been fixed upstream yet.

Antoine (anarcat) fixed this issue for Squeeze LTS and he also left some
comments at

https://ssl.icu-project.org/trac/ticket/12020

He also changed the runConfigure script and his patch for CVE-2016-0494
looks different to me. Perhaps you should contact him (or he will simply
respond to this message because he is subscribed too), discuss this
patch with him and ask him why his approach contains more changes than
the original upstream commit at

http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/f556d4c82ef1

> I built the package in a wheezy chroot, signed the resulting package,
> and uploaded it (along with the debdiff between the prior version and my
> updated package) to the above location.

That's fine. You don't have to upload a new revision to
people.debian.org but it is a useful approach if you want to get more
feedback for your patches. You could also:

* Check the output of the test suite (if it exists)
* Write your own tests or ask upstream for advice how to test the issue
* Contact upstream and ask for code reviews
* Try the reproducer with the old and new version (if it exists)
* Install the package, do some smoke testing and try to verify if the
  update didn't introduce any regressions

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Re: Xen 4.1.6.1 backport + Ubuntu patches ready for testing (take 3)

2016-05-09 Thread Antoine Beaupré 
On 2016-05-04 17:09:39, Antoine Beaupré wrote:
> Hi,
>
> TL;DR: debdiff below, features only changes to debian/changelog and
> debian/patches (apart from the upstream upgrade of course). Binary
> packages in:

Obviously, something *had* to come up here to make this incomplete
again:

http://xenbits.xen.org/xsa/advisory-179.html

So there's *another* escalation through Qemu/HVM to backport. I wonder
if it's worth postponing this upload?

I have had good feedback about the above binary packages, by the
way. They can be considered tested and working - unfortunately, I will
not have time to followup on those until next week so I hope others can
pick this up!

A.

-- 
Nature hides her secret because of her essential loftiness, but not by
means of ruse.
   - Albert Einstein

Re: how reliable is "debian-security-support" ? AW: [SECURITY] Security support for Wheezy handed over to the LTS team

2016-05-09 Thread Santiago Ruano Rincón 
El 09/05/16 a las 11:43, Moritz Muehlenhoff escribió:
> On Mon, May 09, 2016 at 09:35:22AM +, Holger Levsen wrote:
> > On Mon, May 09, 2016 at 08:43:37AM +, Schulz, Reiner wrote:
> > > How often i have to update the "debian-security-support" package?
> > 
> > "never" is valid answer I'd say (though maybe a bit confusing at first).
> 
> Quite the contrary, it needs to be updated whenever an update is available:
> If a package is EOLed during the lifetime of a release, it's added to 
> debian-security-support, which will than report that to the user.
> 
> Cheers,
> Moritz
> 

I have a pending upload for today that will include the
security-support-ended.deb7 list file from git.

Cheers,

Santiago


signature.asc
Description: PGP signature

Re: how reliable is "debian-security-support" ? AW: [SECURITY] Security support for Wheezy handed over to the LTS team

2016-05-09 Thread Moritz Muehlenhoff 
On Mon, May 09, 2016 at 09:35:22AM +, Holger Levsen wrote:
> On Mon, May 09, 2016 at 08:43:37AM +, Schulz, Reiner wrote:
> > How often i have to update the "debian-security-support" package?
> 
> "never" is valid answer I'd say (though maybe a bit confusing at first).

Quite the contrary, it needs to be updated whenever an update is available:
If a package is EOLed during the lifetime of a release, it's added to 
debian-security-support, which will than report that to the user.

Cheers,
Moritz

Re: how reliable is "debian-security-support" ? AW: [SECURITY] Security support for Wheezy handed over to the LTS team

2016-05-09 Thread Holger Levsen 
On Mon, May 09, 2016 at 08:43:37AM +, Schulz, Reiner wrote:
> How often i have to update the "debian-security-support" package?

"never" is valid answer I'd say (though maybe a bit confusing at first).

My point is: the package itself does nothing, it's only used for
documenting what is supported.

The most recent version of security-support-ended.deb7 is what you are
looking for - and even that might be outdated in the sense that it has
been decided that package foo has become unsupportable and thus is not
supported anymore, but noone had time to update security-support-ended.deb7
yet.

https://bugs.debian.org/src:debian-security-support lists some packages
which are not supported anymore in wheezy and which are not listed in
security-support-ended.deb7 yet.
 

-- 
cheers,
Holger


signature.asc
Description: Digital signature

how reliable is "debian-security-support" ? AW: [SECURITY] Security support for Wheezy handed over to the LTS team

2016-05-09 Thread Schulz, Reiner 
How often i have to update the "debian-security-support" package?

Since wheezy went to LTS, there are serveral updates to the  " 
security-support-ended.deb7" file (which lists the support state).

On my wheezy LTS test system i have:

ii  debian-security-support   2015.04.04~deb7u1

with this " security-support-ended.deb7" content:

iceape  2.7.12-1+alpha  2013-12-16 
https://lists.debian.org/debian-security-announce/2013/msg00233.html
chromium-browser 37.0.2062.120-1~deb7u1 2015-01-31 
https://lists.debian.org/debian-security-announce/2015/msg00031.html
ruby-actionmailer-2.3 2.3.14-3  2014-07-19 
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-actionpack-2.3 2.3.14-5  2014-07-19 
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-activerecord-2.3 2.3.14-6  2014-07-19 
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-activeresource-2.3 2.3.14-3  2014-07-19 
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-actionmailer-2.3 2.3.14-3  2014-07-19 
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-activesupport-2.3 2.3.14-7 2014-07-19 
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-rails-2.3 2.3.14-4  2014-07-19 
https://lists.debian.org/debian-security-announce/2014/msg00164.html

But on 
https://anonscm.debian.org/cgit/collab-maint/debian-security-support.git/tree/security-support-ended.deb7

There are some more packages listet:

hromium-browser 37.0.2062.120-1~deb7u1  2015-01-31  
https://lists.debian.org/debian-security-announce/2015/msg00031.html
iceape   2.7.12-1+alpha  2013-12-16  
https://lists.debian.org/debian-security-announce/2013/msg00233.html
ruby-actionmailer-2.32.3.14-32014-07-19  
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-actionpack-2.3  2.3.14-52014-07-19  
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-activerecord-2.32.3.14-62014-07-19  
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-activeresource-2.3  2.3.14-32014-07-19  
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-actionmailer-2.32.3.14-32014-07-19  
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-activesupport-2.3   2.3.14-72014-07-19  
https://lists.debian.org/debian-security-announce/2014/msg00164.html
ruby-rails-2.3   2.3.14-42014-07-19  
https://lists.debian.org/debian-security-announce/2014/msg00164.html
redmine  1.4.4+dfsg1-2+deb7u12014-07-19  Depends on 
ruby-rails-2.3 which is not supported
tomcat6  6.0.45+dfsg-1~deb7u12016-12-31  
https://tomcat.apache.org/tomcat-60-eol.html
typo3-src4.5.19+dfsg1-5+wheezy4  2015-07-23  
https://lists.debian.org/debian-security-announce/2015/msg00210.html
virtualbox   4.1.42-dfsg-1+deb7u12016-01-27  
https://lists.debian.org/debian-security-announce/2016/msg00024.html

# Packages below are no longer supported in Wheezy during the LTS period
mantis  1.2.18-12016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00019.html)
movabletype-opensource  5.1.4+dfsg-4+deb7u3 2016-02-06  Not supported in 
Debian LTS (http://lists.debian.org/20151104190529.gy7...@urchin.earth.li)
openjdk-6   6b38-1.13.10-1~deb7u1   2016-04-15  Not supported in 
Wheezy LTS https://lists.debian.org/debian-lts/2016/02/msg00153.html
openswan1:2.6.37-3  2016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00019.html)
# Openstack support dropped
glance  2012.1.1-5  2016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00024.html)
horizon 2012.1.1-10 2016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00024.html)
keystone2012.1.1-13+wheezy1 2016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00024.html)
nova2012.1.1-18 2016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00024.html)
python-keystoneclient   2012.1-3+deb7u1 2016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00024.html)
python-novaclient   1:2012.1-4  2016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00024.html)
swift   1.4.8-2+deb7u1  2016-02-06  Not supported in 
Debian LTS (https://lists.debian.org/debian-lts/2015/11/msg00024.html)
# End Opensta

Wheezy update of sogo?

2016-05-09 Thread Markus Koschany 
Hello Jeroen,

the Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of sogo:
https://security-tracker.debian.org/tracker/CVE-2015-5395

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.

Thank you very much.

Markus Koschany,
  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

Wheezy update of wpa?

2016-05-09 Thread Markus Koschany 
Hello dear maintainer(s),

the Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of wpa:
https://security-tracker.debian.org/tracker/CVE-2016-4477
https://security-tracker.debian.org/tracker/CVE-2016-4476

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.

Thank you very much.

Markus Koschany,
  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

Re: libidn test packages [resent]

2016-05-09 Thread Brian May 
Added CC Debian Libidn Team 

I now have fixed the packages libidn packages initially produced by
Alessandro Ghedini and destined for wheezy-security and jessie-security.
They now build fine.

In particular, for the Jessie version I had to edit the Makefile.am to
prevent it rebuilding the documentation which was failing to build after
applying security patches triggered a rebuild.

Versions for wheezy and jessie available here:
https://people.debian.org/~bam/debian/pool/main/libi/libidn/

Please test.

Also attached is the debdiff patches.
-- 
Brian May 
diff -Nru libidn-1.25/debian/changelog libidn-1.25/debian/changelog
--- libidn-1.25/debian/changelog	2012-05-30 22:41:06.0 +1000
+++ libidn-1.25/debian/changelog	2016-05-06 17:37:02.0 +1000
@@ -1,3 +1,9 @@
+libidn (1.25-2+deb7u1) wheezy-security; urgency=high
+
+  * Fix out-of-bounds read on invalid UTF-8 input as per CVE-2015-2059
+
+ -- Alessandro Ghedini   Tue, 18 Aug 2015 10:21:50 +0200
+
 libidn (1.25-2) unstable; urgency=low
 
   * Fix copyright format.  Use https for upstream homepage.
diff -Nru libidn-1.25/debian/patches/01_CVE-2015-2059.patch libidn-1.25/debian/patches/01_CVE-2015-2059.patch
--- libidn-1.25/debian/patches/01_CVE-2015-2059.patch	1970-01-01 10:00:00.0 +1000
+++ libidn-1.25/debian/patches/01_CVE-2015-2059.patch	2016-05-06 17:37:02.0 +1000
@@ -0,0 +1,976 @@
+From 2e97c2796581c27213962c77f5a8571a598f9a2e Mon Sep 17 00:00:00 2001
+From: Simon Josefsson 
+Date: Wed, 08 Jul 2015 00:06:22 +
+Subject: libidn: stringprep_utf8_to_ucs4 now rejects invalid UTF-8. CVE-2015-2059
+
+---
+--- a/lib/gl/Makefile.am
 b/lib/gl/Makefile.am
+@@ -21,7 +21,7 @@
+ # the same distribution terms as the rest of that program.
+ #
+ # Generated by gnulib-tool.
+-# Reproduce by: gnulib-tool --import --dir=. --local-dir=lib/gl/override --lib=libgnu --source-base=lib/gl --m4-base=lib/gl/m4 --doc-base=doc --tests-base=lib/gltests --aux-dir=build-aux --with-tests --avoid=iconv-h-tests --avoid=string-tests --avoid=wchar-tests --lgpl=2 --no-conditional-dependencies --libtool --macro-prefix=lgl --no-vc-files gettext-h lib-msvc-compat lib-symbol-versions lib-symbol-visibility stdint striconv strverscmp
++# Reproduce by: gnulib-tool --import --dir=. --local-dir=lib/gl/override --lib=libgnu --source-base=lib/gl --m4-base=lib/gl/m4 --doc-base=doc --tests-base=lib/gltests --aux-dir=build-aux --with-tests --avoid=iconv-h-tests --avoid=string-tests --avoid=wchar-tests --lgpl=2 --no-conditional-dependencies --libtool --macro-prefix=lgl --no-vc-files gettext-h lib-msvc-compat lib-symbol-versions lib-symbol-visibility stdint striconv strverscmp unistr/u8-check
+ 
+ AUTOMAKE_OPTIONS = 1.5 gnits subdir-objects
+ 
+@@ -489,6 +489,14 @@
+ 
+ ## end   gnulib module unistr/base
+ 
++## begin gnulib module unistr/u8-check
++
++if LIBUNISTRING_COMPILE_UNISTR_U8_CHECK
++libgnu_la_SOURCES += unistr/u8-check.c
++endif
++
++## end   gnulib module unistr/u8-check
++
+ ## begin gnulib module unistr/u8-mbtoucr
+ 
+ if LIBUNISTRING_COMPILE_UNISTR_U8_MBTOUCR
+--- a/lib/gl/m4/gnulib-cache.m4
 b/lib/gl/m4/gnulib-cache.m4
+@@ -27,7 +27,7 @@
+ 
+ 
+ # Specification in the form of a command-line invocation:
+-#   gnulib-tool --import --dir=. --local-dir=lib/gl/override --lib=libgnu --source-base=lib/gl --m4-base=lib/gl/m4 --doc-base=doc --tests-base=lib/gltests --aux-dir=build-aux --with-tests --avoid=iconv-h-tests --avoid=string-tests --avoid=wchar-tests --lgpl=2 --no-conditional-dependencies --libtool --macro-prefix=lgl --no-vc-files gettext-h lib-msvc-compat lib-symbol-versions lib-symbol-visibility stdint striconv strverscmp
++#   gnulib-tool --import --dir=. --local-dir=lib/gl/override --lib=libgnu --source-base=lib/gl --m4-base=lib/gl/m4 --doc-base=doc --tests-base=lib/gltests --aux-dir=build-aux --with-tests --avoid=iconv-h-tests --avoid=string-tests --avoid=wchar-tests --lgpl=2 --no-conditional-dependencies --libtool --macro-prefix=lgl --no-vc-files gettext-h lib-msvc-compat lib-symbol-versions lib-symbol-visibility stdint striconv strverscmp unistr/u8-check
+ 
+ # Specification in the form of a few gnulib-tool.m4 macro invocations:
+ gl_LOCAL_DIR([lib/gl/override])
+@@ -39,6 +39,7 @@
+   stdint
+   striconv
+   strverscmp
++  unistr/u8-check
+ ])
+ gl_AVOID([iconv-h-tests string-tests wchar-tests])
+ gl_SOURCE_BASE([lib/gl])
+--- a/lib/gl/m4/gnulib-comp.m4
 b/lib/gl/m4/gnulib-comp.m4
+@@ -111,6 +111,8 @@
+   # Code from module unistd:
+   # Code from module unistd-tests:
+   # Code from module unistr/base:
++  # Code from module unistr/u8-check:
++  # Code from module unistr/u8-check-tests:
+   # Code from module unistr/u8-mbtoucr:
+   # Code from module unistr/u8-mbtoucr-tests:
+   # Code from module unistr/u8-uctomb:
+@@ -172,6 +174,7 @@
+ fi
+ gl_STRING_MODULE_INDICATOR([strverscmp])
+ gl_LIBUNISTRING_LIBHEADER([0.9.2], [unistr.h])
++gl_LIBUNISTRING_MODULE([0.9], [unistr/u8-check])
+ gl_MODULE_INDICATOR([unistr/u8-mbtoucr])
+ gl_LIBUNISTRING_