Salut Mathieu,
On 7 April 2014 10:16, Mathieu Malaterre wrote:
> Here is the dpatch version (thanks to
> http://matrixhasu.altervista.org/?view=use_dpatch).
>
> Raphaël do you have the time to produce a 1.3+dfsg-4.8 ?
I can find some time to do it and release a revision to the DSA to fix
the reg
Here is the dpatch version (thanks to
http://matrixhasu.altervista.org/?view=use_dpatch).
Raphaël do you have the time to produce a 1.3+dfsg-4.8 ?
Thanks,
segfault1.dpatch
Description: Binary data
On 04/05/2014 09:05 AM, Mathieu Malaterre wrote:
Here is the backported patch (attached). I have no clue on how to use
dpatch to convert it. 20.jp2 does not segfault anymore, and p0_06.j2k
does decode normally.
With this patch added and segfault1.dpatch removed, OpenSlide
successfully decodes
On Sat, Apr 5, 2014 at 3:05 PM, Mathieu Malaterre wrote:
> Control: tag -1 patch confirmed
>
> Here is the backported patch (attached). I have no clue on how to use
> dpatch to convert it. 20.jp2 does not segfault anymore, and p0_06.j2k
> does decode normally.
Of course segfault1.dpatch needs to
Control: tag -1 patch confirmed
Here is the backported patch (attached). I have no clue on how to use
dpatch to convert it. 20.jp2 does not segfault anymore, and p0_06.j2k
does decode normally.
--- libopenjpeg/tcd.c 2014-04-05 14:49:32.0 +0200
+++ ../../openjpeg-1.3+dfsg/libopenjpeg/tcd.c
Just for reference, I was given by geissert@d.o the input files to
reproduce the segfault.
segfaul1.dpatch work around issue as demonstrated in:
https://openjpeg.googlecode.com/svn/data/input/nonregression/edf_c2_20.jp2
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with
Control: tag -1 patch
As per upstream commit, I think the gulty patch could be safely exchanged with:
http://code.google.com/p/openjpeg/source/detail?r=2757#
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists
Indeed
p0_06.j2k is part of the conformance test suite and successful decoding of
it is mandatory to stay compliant with standard.
Cheers,
Antonin
-Original Message-
From: mathieu.malate...@gmail.com [mailto:mathieu.malate...@gmail.com] On
Behalf Of Mathieu Malaterre
Sent: mardi 7 janvi
Antonin,
As per:
http://bugs.debian.org/734238#17
It seems the code in openjpeg "assume that all components have at
least the number of blocks of the first component", hence a patch has
been applied as:
http://patch-tracker.debian.org/patch/series/view/openjpeg/1.3+dfsg-4.7/segfault1.dpatch
The slide file at [1] contains 4,569 chroma-subsampled J2K images, and
the file at [2] contains 25,120. The below program will decode every
image into memory via OpenSlide. It executes Valgrind-clean against
both slides on 1.3+dfsg-4.6.
The functionality does work, and people use it. Please
Hi,
For further reference, this is the change made with segfault1.dpatch
I'm not sure how it is that openjpeg even works with that image, as
there are some parts of the code that really assume that all
components have at least the number of blocks of the first component.
Possibly making it write
Control: tags -1 grave
This is clearly a regression. The patch should be reworked to match
upstream implementation.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Package: libopenjpeg2
Version: 1.3+dfsg-4.7+b1
The patch for CVE-2013-6045 disables decoding of images whose first
color component has a higher resolution than subsequent components.
This is a legitimate image encoding; consider, for example, YCbCr images
with chroma subsampling. This change
13 matches
Mail list logo