Hi,
On 04/10/2021 01:20, Utkarsh Gupta wrote:
> Hello LTS team,
>
> Apparently, I've sent the following mail thrice to the -announce
> list but it doesn't seem to be going through. Could somebody
> please send the below announcement from my end? TIA! \o/
>
> The website update has already been pu
Utkarsh Gupta
> October 03, 2021https://wiki.debian.org/LTS
> - ---
>
> Package: tiff
> Version: 4.0.8-2+deb9u7
> CVE ID : CVE-2020-19131 CVE-2020-19
Thank you merci
Le Lun 18 Fév 2019 8:13, Brian May a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Package : tiff
> Version: 4.0.3-12.3+deb8u8
> CVE ID : CVE-2018-17000 CVE-2018-19210 CVE-2019-7663
>
>
> Brief introduction
&
Hugo Lefeuvre writes:
>> ++if (0x / tilew < spp) {
>
> I don't really like this patch... it has not been merged yet (the PR has
> been closed, so I guess it will never get merged) and looks more like a
> hack to me.
>
> What if tilew * spp = INT_MAX ?
>
> Then oskew + iskew will s
Transferfunction) allows an attacker
> +to cause a denial-of-service through a crafted tiff file. This
> vulnerability
> +can be triggered by the executable tiffcp.
This patch is actually the one for CVE-2019-7663, which happens to also
fix CVE-2018-17000 (not confirmed by upstream
Hi Brian,
I am currently testing the update. I already had a look at the patches.
> diff -Nru tiff-4.0.3/debian/patches/CVE-2018-12900.patch
> tiff-4.0.3/debian/patches/CVE-2018-12900.patch
> --- tiff-4.0.3/debian/patches/CVE-2018-12900.patch1970-01-01
> 10:00:00.0 +100
Hi,
> Attached is my proposed patch for tiff in Jessie.
I will be able to test the upload with my usual set of test files tomorrow
if necessary.
> +From d0a842c5dbad2609aed43c701a12ed12461d3405 Mon Sep 17 00:00:00 2001
> +From: Hugo Lefeuvre
> +Date: Wed, 21 Nov 2018 18:50:34 +010
Hi Brian
I made a brief look and I have nothing to complain about.
// Ola
On Sun, 10 Feb 2019 at 21:55, Brian May wrote:
> Hello,
>
> Attached is my proposed patch for tiff in Jessie.
>
> Regards
> --
> Brian May
>
--
--- Inguza Technology AB --- MSc in Informat
Hello,
Attached is my proposed patch for tiff in Jessie.
Regards
--
Brian May
diff -Nru tiff-4.0.3/debian/changelog tiff-4.0.3/debian/changelog
--- tiff-4.0.3/debian/changelog 2018-10-28 22:03:02.0 +1100
+++ tiff-4.0.3/debian/changelog 2019-02-08 14:52:01.0 +1100
@@ -1,3 +1,22
According to https://security-tracker.debian.org/tracker/CVE-2014-8127:
tiff 4.0.3-12.3+deb8u5 is vulnerable to CVE-2014-8127.
But according to the changelog CVE-2014-8127 was fixed in version
4.0.3-12.3+deb8u3:
tiff (4.0.3-12.3+deb8u3) jessie-security; urgency=high
* Backport fix for the
ok like the problem.
It puzzles me that I see an additional "Integer arithmetic
overflow". The revelant code is. I believe tmsize_t==tsize_t which is a
signed int32, although I only can see this mentioned in a comment. I
can't find the definition of tsize_t.
=== code ===
tmsize_t
Brian May writes:
> I can reproduce CVE-2018-19210. Both on wheezy and stretch. Doesn't
Me getting distributions confused. I tested on Jessie, and I was able to
reproduce the problem. I did not test wheezy.
--
Brian May
Brian May writes:
> Ola Lundqvist writes:
>
>> Could it be so that the problem is only reproducible on 32-bit
>> systems?
>
> Good point. Will try.
Nope. Can't reproduce i386 build on amd64 kernel. I would be rather
surprised if choice of kernel mattered.
I can reproduce CVE-2018-19210. Both o
Ola Lundqvist writes:
> Could it be so that the problem is only reproducible on 32-bit
> systems?
Good point. Will try.
--
Brian May
Hi
Could it be so that the problem is only reproducible on 32-bit systems?
// Ola
On Tue, 13 Nov 2018 at 07:30, Brian May wrote:
> Ola Lundqvist writes:
>
> > Interesting. I wonder what the fix do differently in this case. It is a
> > little worrying that it exit with a zero return code, but
Ola Lundqvist writes:
> Interesting. I wonder what the fix do differently in this case. It is a
> little worrying that it exit with a zero return code, but maybe not major.
> On the other hand, if we cannot reproduce the problem maybe it is not worth
> patching... Hmm.
I tried to reproduce this
Hi Brian
Interesting. I wonder what the fix do differently in this case. It is a
little worrying that it exit with a zero return code, but maybe not major.
On the other hand, if we cannot reproduce the problem maybe it is not worth
patching... Hmm.
// Ola
On Mon, 12 Nov 2018 at 07:24, Brian May
Ola Lundqvist writes:
> Hi Brian
>
> To me it looks like you have been able to reproduce the problem. You
> clearly get different results with and without the patch indicating
> that you have in fact triggered the problem. I do not see that you
> have run the program using a debugger, so are you
security:
>
> (jessie-i386-default)root@silverfish:/home/brian/tree/debian/lts/packages/tiff/tiff-4.0.3#
> tiff2bw /tmp/poc /dev/null
> TIFFReadDirectory: Warning, Unknown field with tag 292 (0x124) encountered.
> TIFFScanlineSize: Integer arithmetic overflow.
> TIFFReadDirectory:
I applied the fix for this CVE. Patch attached.
However, then I found out I can't reproduce the bug under Debian/Jessie,
with or without the security update.
Version 4.0.3-12.3+deb8u7 in Jessie+security:
(jessie-i386-default)root@silverfish:/home/brian/tree/debian/lts/packages/tiff/tiff-
On 2018-08-29 12:24:30, Brian May wrote:
> Antoine Beaupré writes:
>
>> Brian, are you sure you're getting those failures in jessie? Which
>> architecture? Here my tests were done in a VirtualBox VM using an up to
>> date Debian jessie amd64 box.
>
> My tests were done in a schroot. Not sure if I
Antoine Beaupré writes:
> Brian, are you sure you're getting those failures in jessie? Which
> architecture? Here my tests were done in a VirtualBox VM using an up to
> date Debian jessie amd64 box.
My tests were done in a schroot. Not sure if I used i386 or amd64 now.
--
Brian May
> }
>
> However, I cannot see how this could cause a buffer overflow
> condition. We appear to allocate nstrips uint64, and then use nstrips
> uint64.
I can't reproduce this either in a jessie VM:
[...]
ii libtiff-tools4.0.3-12.3+deb8u6 a
I have been trying to reproduce this bug (buffer overflow), but instead
I get increasing memory usage until my computer crashes. With versions
from Jessie, Stretch, and Sid. So maybe another security issue?
I note that CVE-2017-11613 and CVE-2018-5784 can use unbounded
memory. However these are ma
> So, what is the solution ?
>
> First, change
>
> TIFFReadScanline(in, buf, row, s) < 0
>
> in tools/tiffcp.c to
>
> TIFFReadScanline(in, buf, row, s) <= 0
>
> It is important to understand that 0 is also an error code here. Otherwise,
> change error handling in tif_lzw to return negative num
Hi,
> It looks like this buffer overflow is the consequence of an earlier buffer
> overflow in the GetNextCodeCompat macro:
Hum, that was not completely true. But I think I got it now.
The buggy sequence is:
1) Initialy oldcodep points to 0x63201890.
We get code 0x010c = 268, add it to t
It looks like this buffer overflow is the consequence of an earlier buffer
overflow in the GetNextCodeCompat macro:
> #define GetNextCodeCompat(sp, bp, code) { \
> nextdata |= (unsigned long) *(bp)++ << nextbits;\
> nextbits += 8;
Hi,
My current understanding of the problem (based on investigations on
latest master, but also valid for older versions):
The code_t string type is defined as a kind of chained list. Each entry
contains:
. a pointer to the next string entry
. a length field indicating the remaining length of th
Hi,
I have successfully reproduced this issue in latest upstream master
branch and Buster but couldn't reproduce it neither in Wheezy nor in
Jessie or Stretch.
I am going to take a closer look, try to prepare a patch and declare
Wheezy, Jessie and Stretch unaffected if appropriate.
Regards,
Hug
Hi Antoine,
> I see you have the `tiff` package claimed in dla-needed.txt, but not
> `tiff3`. I suspect both are fairly similar issues and that you intended
> to work on both, so I figured it might be better to claim both next
> time.
Right, I will prepare an upload for both packages
On 2018-03-22 09:19:31, Hugo Lefeuvre wrote:
> * Start working on tiff and tiff3:
>
> - Investigate, debug/prepare and test patch for CVE-2018-7456 (git master
> version). This issue was very long to debug because it required me
> to have a good understanding of the TIFF s
..d9295800 100644
--- a/libtiff/tif_dirread.c
+++ b/libtiff/tif_dirread.c
@@ -4024,6 +4024,26 @@ TIFFReadDirectory(TIFF* tif)
}
}
}
+
+ /*
+ * Make sure all non-color channels are extrasamples.
+ * If it's not the case, define them as such.
+ */
+if (tif->ti
Hi Brian,
> > So, in fact it may very well be that the size of the TransferFunction table
> > is always at most 3 rows and this definition is right.
>
> Is the code that loads the transfer function safe? Is there any
> possibility of tricking the loading function to try and set the 4th row?
Hum,
> Seems good to me. I would suggest sending a patch upstream, see what
> they think.
Thanks for the feedback ! I'll write the remaining part and submit it to
upstream.
> Also I tend to think some some of assertion might be a good idea,
> something that aborts if
>
> (td->td_samplesperpixel - td
Hugo Lefeuvre writes:
> So, after some debugging on CVE-2018-7456, I start to get the feeling to
> understand the issue.
>
> Here are my conclusions for the moment:
>
> * In any case, the transfer function should not care about other
> channels defined by ExtraSamples (see 2nd and 3rd paragraph
Hugo Lefeuvre writes:
> Sure ? To me it looked like three entries are provided, but the fourth
> (td->td_transferfunction[3]) isn't.
I was about to write justification for how I was absolutely sure of
this.
Then I realized the loop is:
for (i = 1; i < td->td_samplesperpixel; i++)
i.e. it star
Hugo Lefeuvre writes:
> So, in fact it may very well be that the size of the TransferFunction table
> is always at most 3 rows and this definition is right.
Is the code that loads the transfer function safe? Is there any
possibility of tricking the loading function to try and set the 4th row?
--
it work now ?
I think so ! I didn't write the second part of the patch and will wait
for feedback. But you can convince yourself that it doesn't crash anymore
by modifying the sample to add an ExtraSamples = 1 field (using
"tiffset -s 338 1 0 $(sample)" for example).
bthread_db library
"/lib/x86_64-linux-gnu/libthread_db.so.1".
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are
not sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 314 (0x13a)
encountered.
TIFFReadDirectory: Warning, Unknown field with tag 54034 (0xd312)
encou
Hugo Lefeuvre writes:
> Under certain conditions, the td->td_transferfunction table might not
> have the excepted size, that is it may not have the excepted number of
> samples per pixel (td->td_samplesperpixel). In this case for example,
> the table is only 3 rows large while td->td_samplesperpi
with
> -O0 / some compilers, it might not always be the case.
Absolutely, out-of-bounds access has undefined behaviour. The compiler
will (in general) optimise on the assumption that the input program
never attempts to do anything that's specified as having undefined
behaviour, which can ha
Hi Brian,
I've had a look at your patch, here are some comments.
> I attempted to fix CVE-2018-7456 issue in tiff, for the version in
> stretch. My patch is below. But curiously my patch only works if I
> enable the commented out call to fprintf or use -O0 instead of the
> defa
Hi Brian,
> I attempted to fix CVE-2018-7456 issue in tiff, for the version in
> stretch. My patch is below. But curiously my patch only works if I
> enable the commented out call to fprintf or use -O0 instead of the
> default -O2 (-O1 also fails). Otherwise the if condition never get
I attempted to fix CVE-2018-7456 issue in tiff, for the version in
stretch. My patch is below. But curiously my patch only works if I
enable the commented out call to fprintf or use -O0 instead of the
default -O2 (-O1 also fails). Otherwise the if condition never gets
executed, and it segfaults
commit 3dd8f6a357981a4090f126ab9025056c938b6940
+Author: Brian May
+Date: Thu Dec 7 07:46:47 2017 +1100
+
+tiff2pdf: Fix CVE-2017-9935
+
+Fix for http://bugzilla.maptools.org/show_bug.cgi?id=2704
+
+This vulnerability - at least for the supplied test case - is because we
+assume that a tiff will only ha
Brian May writes:
> Now to see if the patch will apply to the older tiff3, also in wheezy.
Done.
I note that the previous version of tiff3 is a security update for
tiff2pdf.
However I also note that - for the tiff3 package - we don't build a
binary for tiff2pdf. The newer tiff package
> I have a version available for testing.
>
> https://people.debian.org/~bam/debian/pool/main/t/tiff/
Here is the diff:
diff -Nru tiff-4.0.2/debian/changelog tiff-4.0.2/debian/changelog
--- tiff-4.0.2/debian/changelog 2017-09-10 10:03:56.0 +1000
+++ tiff-4.0.2/debian/changelog 2
I have a version available for testing.
https://people.debian.org/~bam/debian/pool/main/t/tiff/
Now to see if the patch will apply to the older tiff3, also in wheezy.
--
Brian May
On Fri, Nov 17, 2017 at 03:45:07PM +1100, Brian May wrote:
> Brian May writes:
>
> > --- tiff-4.0.8.orig/libtiff/tif_dir.c
> > +++ tiff-4.0.8/libtiff/tif_dir.c
> > @@ -1065,6 +1065,9 @@
> > if (td->td_samplesp
Brian May writes:
> --- tiff-4.0.8.orig/libtiff/tif_dir.c
> +++ tiff-4.0.8/libtiff/tif_dir.c
> @@ -1065,6 +1065,9 @@
> if (td->td_samplesperpixel - td->td_extrasamples > 1) {
> *va_arg(ap, uint16**) =
>
update the client and not the
library. However I tend to think the correct solution lies in the
library.
(actually I wonder if that if statement is even required... but keeping
changes minimal here)
--- tiff-4.0.8.orig/libtiff/tif_dir.c
+++ tiff-4.0.8/libtiff/tif_dir.c
@@ -1065,6 +1065,9
Brian May writes:
> I added a comment to the upstream bug report:
>
> http://bugzilla.maptools.org/show_bug.cgi?id=2704#c14
Anybody got a sample (good) tiff file with transfer function tables?
I am a bit puzzled, as per last comment in upstream bug report, because
the tiff2pdf se
I added a comment to the upstream bug report:
http://bugzilla.maptools.org/show_bug.cgi?id=2704#c14
--
Brian May
"Roberto C. Sánchez" writes:
> That sounds like a flawed assumption. The spec (I provide a working
> link below) describes the format of a TIFF as being made up of an 8 byte
> header and one or more images (IFDs, or image file directories).
>
> The descriptions do not
"Roberto C. Sánchez" writes:
> That sounds like a flawed assumption. The spec (I provide a working
> link below) describes the format of a TIFF as being made up of an 8 byte
> header and one or more images (IFDs, or image file directories).
Yes, that was my guess too, altho
Hi Brian,
I tried looking at this when I prepared the last tiff and tiff3 updates
a couple of months ago. However, you went much deeper than I did.
On Tue, Nov 14, 2017 at 08:22:26AM +1100, Brian May wrote:
> Looks like this vulnerability - at least for the first test case - is
> beca
Looks like this vulnerability - at least for the first test case - is
because we assume that a tiff will only have one transfer function that
is the same for all pages. However, we read the transfer function for
every page.
Depending on the transfer function, we allocate either 2 or 4 bytes to
Hi Raphael,
On Tue, Jun 06, 2017 at 12:05:14PM +0200, Raphael Hertzog wrote:
> Hi,
>
> On Fri, 02 Jun 2017, Guido Günther wrote:
> > > but it's not worth arguing and providing that in jessie might be useful
> > > for
> > > building building custom tools still.
> >
> > But then again the fix for
Hi,
On Fri, 02 Jun 2017, Guido Günther wrote:
> > but it's not worth arguing and providing that in jessie might be useful for
> > building building custom tools still.
>
> But then again the fix for this should be in Wheezy already as far as I
> can tell. Raphael (since you provided the upstream
reasoning for @51764. This marks tiff as
> > > affected by CVE-2016-10095. However from the upstream bug and the
> > > changes we made in wheezy it looks like the changes we made already are
> > > sufficient to fix the issue. Do you have a hint why you think this is
> &g
On Fri, Jun 02, 2017 at 11:02:06AM +0200, Moritz Muehlenhoff wrote:
> On Fri, Jun 02, 2017 at 10:25:29AM +0200, Guido Günther wrote:
> > Hi Moritz,
> > I'm trying to figure out the reasoning for @51764. This marks tiff as
> > affected by CVE-2016-10095. However fro
On Fri, Jun 02, 2017 at 10:25:29AM +0200, Guido Günther wrote:
> Hi Moritz,
> I'm trying to figure out the reasoning for @51764. This marks tiff as
> affected by CVE-2016-10095. However from the upstream bug and the
> changes we made in wheezy it looks like the changes we
Hi Moritz,
I'm trying to figure out the reasoning for @51764. This marks tiff as
affected by CVE-2016-10095. However from the upstream bug and the
changes we made in wheezy it looks like the changes we made already are
sufficient to fix the issue. Do you have a hint why you think this is
no
Dear maintainer(s),
The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of tiff:
https://security-tracker.debian.org/tracker/CVE-2016-10266
https://security-tracker.debian.org/tracker/CVE-2016-10267
https://security-tracker.debian.org/tracker
Hi,
I've built an update for the tiff package for all the pending issues in
the security tracker, including some issues that were marked "no-dsa"
for various reasons. I believe some of those were actually misfiled, as
arbitrary code execution seems serious enough, in my opinion
Hello dear maintainer(s),
The Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of tiff:
https://security-tracker.debian.org/tracker/CVE-2016-9533
https://security-tracker.debian.org/tracker/CVE-2016-9534
https://security-tracker.debian.org
Hello dear maintainer(s),
the Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of tiff:
https://security-tracker.debian.org/tracker/source-package/tiff
Would you like to take care of this yourself?
If yes, please follow the workflow we have
27;s just due to "gbp pq" usage. Looks like the last set of patches
> have been added without using it while the initial set was done that way.
Understood, this is what i suspected.
>> It seems that your approach of addressing whatever CopyField uses in the
>> tiff tools bi
e been added without using it while the initial set was done that way.
> It seems that your approach of addressing whatever CopyField uses in the
> tiff tools binaries is a good short-term solution. I would be worried,
> however, that third-party tools may be using other tags, but that seems
&
On 2016-10-28 10:25:31, Raphael Hertzog wrote:
> I also attach both debdiff for review by other Debian developers. I intend
> to upload the packages early next week. For tiff, my changes are in git
> too:
> https://anonscm.debian.org/cgit/collab-maint/tiff.git/log/?id=refs/heads/maste
Hello,
I just finished preparing new version of tiff/tiff3 packages.
One of the patch has not been officially acked by upstream yet
(cf http://bugzilla.maptools.org/show_bug.cgi?id=2580 )
and thus I would like some user testing before I release
the DLA to make sure that my changes do not have
Raphael Hertzog writes:
>> What does the TIFFReadDirectoryFindFieldInfo function do? What
>> situations is TIFFReadDirectoryFindFieldInfo unsuccessful?
>
> I don't know.
It searches for the field in the tiff file. As I guessed.
Which confused me (and still does), if the
On Thu, 15 Sep 2016, Brian May wrote:
> What does the TIFFReadDirectoryFindFieldInfo function do? What
> situations is TIFFReadDirectoryFindFieldInfo unsuccessful?
I don't know.
> You could perhaps mitigate by requiring an extra parameter that declares
> the number of options you are parsing, how
On Thu, 15 Sep 2016, Brian May wrote:
> Salvatore Bonaccorso writes:
>
> > Minor comment: if you are sure that those are duplicates you might try
> > to contact MITRE to made them aware.
>
> I was just going based on what others have said, e.g. in the linked
> reports. Would hope that one of the
Raphael Hertzog writes:
> I agree on all this but somehow I have the feeling that we can still
> do better for example by blacklisting tags that are known to use a single
> extension and refusing to handle them as custom
>
> My problem is that I'm not sure that we have a comprehensive list of suc
Salvatore Bonaccorso writes:
> Minor comment: if you are sure that those are duplicates you might try
> to contact MITRE to made them aware.
I was just going based on what others have said, e.g. in the linked
reports. Would hope that one of them has already contacted MITRE...
--
Brian May
Hi Brian,
On Wed, Sep 14, 2016 at 08:26:06AM +1000, Brian May wrote:
> CVE-2015-7554 / http://bugzilla.maptools.org/show_bug.cgi?id=2564
>
> Duplicate:
>
> CVE-2016-5318 / http://bugzilla.maptools.org/show_bug.cgi?id=2561
Minor comment: if you are sure that those are duplicates you might try
to
gt; documenting somewhere (e.g. the DSA/DLA) that the scope of the fix is
> restricted?
To me it looks like the RedHat patch fixes the issue with the specificly
crafted file... but you can just recreate the same problem with
another (non-standard) tiff tag and their patch is then useless.
Cheers
CVE-2015-7554 / http://bugzilla.maptools.org/show_bug.cgi?id=2564
Duplicate:
CVE-2016-5318 / http://bugzilla.maptools.org/show_bug.cgi?id=2561
What would be considered an acceptable fix here? It looks like a proper
fix is not available without changing the API due to limitations in the
stdarg.h
On 26/06/16 16:10, Bálint Réczey wrote:
> Added that information in dla-needed.txt.
Thanks. I added links to each cve in data/CVE/list but forgot to add a note to
dla-needed.
> In that case I don't claim them yet. Let's see how upstream responds.
OK.
Cheers,
Emilio
Hi Emilio,
2016-06-26 9:58 GMT+02:00 Emilio Pozuelo Monfort :
> On 26/06/16 02:19, Bálint Réczey wrote:
>> Hi,
>>
>> There are newly discovered vulnerabilities in tiff [1].
>>
>> I no one objects I plan looking into them and working with the
>> maintainer(s)
On 26/06/16 02:19, Bálint Réczey wrote:
> Hi,
>
> There are newly discovered vulnerabilities in tiff [1].
>
> I no one objects I plan looking into them and working with the
> maintainer(s) to get them fixed in Wheezy LTS and in newer
> releases.
I looked at this yesterd
Hi,
There are newly discovered vulnerabilities in tiff [1].
I no one objects I plan looking into them and working with the
maintainer(s) to get them fixed in Wheezy LTS and in newer
releases.
Damyan, who prepared the latest DLA is marked as inactive
for the month and I'm also CC-ing San
Hi, Damyan
El 28/01/16 a las 12:45, Damyan Ivanov escribió:
> Hi, new trainee here.
>
welcome aboard!
> I want to work on the remaining tiff issues. However I saw a DLA
> issued a couple of days ago by Santiago (in CC).
>
> dla-needed.txt has no claim, but I'd rather b
Hi, new trainee here.
I want to work on the remaining tiff issues. However I saw a DLA
issued a couple of days ago by Santiago (in CC).
dla-needed.txt has no claim, but I'd rather be sure not to step over.
Santiago, are you working on tiff or shall I proceed?
Cheers,
dam
signatur
kages seems to work well, but reviews are welcome.
Santiago
diff -Nru tiff-3.9.4/debian/changelog tiff-3.9.4/debian/changelog
--- tiff-3.9.4/debian/changelog 2015-05-06 23:37:44.0 +0200
+++ tiff-3.9.4/debian/changelog 2016-01-20 10:23:45.0 +0100
@@ -1,3 +1,11 @@
+tiff (3.9.4-5+squeez
queeze LTS update yourself.
I (with my LTS team hat on) just signed up for looking at fixing tiff
in squeeze-lts.
@László: once you finished your research tomorrow, could you send a
short summary with your findings (or even upload a new package version
to unstable)?
Thanks+>Greets,
Mike
Hi Ondřej, Ben,
On Thu, Dec 31, 2015 at 10:04 AM, Ondřej Surý wrote:
> I have a git mirror[1] (git cvsimport) of upstream CVS and right now
> it's a tad bit confusing which patches are relevant to those CVEs.
I've packaged 4.0.6, fixed two CVEs and two other vulnerabilities
that don't have an id
thub.com/oerdnj/libtiff.git
On Thu, Dec 31, 2015, at 01:24, Ben Hutchings wrote:
> Hello dear maintainer(s),
>
> the Debian LTS team would like to fix the security issues which are
> currently open in the Squeeze version of tiff:
> https://security-tracker.debian.org/tracker/CV
Hello dear maintainer(s),
the Debian LTS team would like to fix the security issues which are
currently open in the Squeeze version of tiff:
https://security-tracker.debian.org/tracker/CVE-2015-7554
https://security-tracker.debian.org/tracker/CVE-2015-8665
https://security-tracker.debian.org
On Wed, 2015-12-30 at 13:05 -0500, Jay Berkenbilt wrote:
> Hello. I am no longer maintaining the tiff packages, but I have cc'ed
> the new maintainers so that they can read the message quoted below and
> respond if they are interested. I wonder whether it might make sense for
&g
Hello dear maintainer(s),
the Debian LTS team would like to fix the security issues which are
currently open in the Squeeze version of tiff:
https://security-tracker.debian.org/tracker/CVE-2015-7554
https://security-tracker.debian.org/tracker/CVE-2015-8665
https://security-tracker.debian.org
I have prepared a security update to tiff and uploaded it to
<https://people.debian.org/~benh/packages/squeeze-lts/>. However it
has a limited test suite and I don't know what would be a good way to
test for regressions.
(I did check that this version doesn't have bug #7835
Hi,
this is my debdiff for CVE-2013-4243 in tiff.
I used the patch for wheezy as template.
Thorsten
diff -Nru tiff-3.9.4/debian/changelog tiff-3.9.4/debian/changelog
--- tiff-3.9.4/debian/changelog 2013-08-24 17:23:06.0 +0200
+++ tiff-3.9.4/debian/changelog 2014-06-26 19:43
94 matches
Mail list logo
