Re: tiff / CVE-2018-18661

[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 sure that you did
> not end up in a crash?

Looks like it it exiting normally to me:

(jessie-amd64-default)root@silverfish:/tmp/brian/tmph6ow42nt/build/amd64# gdb 
tiff2bw  
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from tiff2bw...(no debugging symbols found)...done.
(gdb) set args /tmp/poc /dev/null
(gdb) r
Starting program: /usr/bin/tiff2bw /tmp/poc /dev/null
TIFFReadDirectory: Warning, Unknown field with tag 292 (0x124) encountered.
LZWDecode: Not enough data at scanline 0 (short 6442004472 bytes).
TIFFWriteDirectoryTagData: IO error writing tag data.
[Inferior 1 (process 31103) exited normally]
(gdb) 
-- 
Brian May 

Re: updates on the gnupg/enigmail/thunderbird/firefox situation

[Antoine Beaupré]

On 2018-11-11 23:03:07, Emilio Pozuelo Monfort wrote:
> On 11/11/2018 15:47, Antoine Beaupré wrote:
>> On 2018-11-11 13:21:05, Emilio Pozuelo Monfort wrote:
>>> Hi Antoine,
>>>
>>> On 09/11/2018 20:37, Antoine Beaupré wrote:
 On 2018-11-05 16:26:44, Emilio Pozuelo Monfort wrote:
> Hi,
>
> On 30/10/2018 16:46, Antoine Beaupré wrote:
>> Which brings us to Thunderbird (and Firefox) themselves. The last I
>> heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if
>> he needed help on that last week, but haven't got a response. Hopefully
>> all that work will come to fruitition synchronously in a grand fanfare
>> of uploads all working out perfectly in the end. :)
>
> Sorry if I missed your mail. Anyway, here's an update:
>
> LLVM (and the necessary deps) were accepted. Unfortunately I run into some
> trouble while bootstrapping rustc and cargo. I tried some different ways 
> and
> finally fixed the first one (bootstrap using upstream binaries). I am 
> uploading
> the packages now and will follow up with firefox/thunderbird if all goes 
> well.

 Just so I see how fast I should be moving on Enigmail, when do you plan
 on uploading Thunderbird?
>>>
>>> The update is ready, and the blocker was an update to stretch, which has 
>>> already
>>> happen. So I believe we are ready, and this could happen anytime now.
>>>
>>> However since we don't have a working enigmail, should we delay the update 
>>> until
>>> we do? Given the security issues in thunderbird and the fact that the new
>>> version has a Breaks on the old enigmail, I would say that we can go ahead 
>>> with
>>> thunderbird, and enigmail can be fixed asynchronously. However if the 
>>> update is
>>> not too far ahead, we could also delay this a bit longer.
>>>
>>> Thoughts?
>> 
>> I think we could manage a resolution with Enigmail soon enough, and
>> considering how fast those updates were deployed on stretch, i don't
>> know if we have a reasonable excuse to delay those in jessie.
>
> Just to be clear, with 'those' are you referring to thunderbird, i.e. saying
> that we should release the update now, and update enigmail asynchronously? 
> That
> is what I think you meant, but perhaps you were referring to enigmail instead,
> maybe suggesting that we shouldn't delay the enigmail updates, i.e. we should
> block the thunderbird update until the enigmail changes are ready.
>
> Maybe I'm just being too dense, but if you could clarify which one you meant,
> I'd appreciate it.

Sorry for being unclear - I meant that the Thunderbird and Firefox
updates were deployed quickly, without waiting for Enigmail to be
ready. So we should do the same with Jessie (upload FF and TB before
Enigmail) especially since we had a long ways to prepare ourselves and
indeed have a plan already.

So please do go ahead.

A.

-- 
We won't have a society if we destroy the environment.
- Margaret Mead

Re: updates on the gnupg/enigmail/thunderbird/firefox situation

[Emilio Pozuelo Monfort]

On 11/11/2018 15:47, Antoine Beaupré wrote:
> On 2018-11-11 13:21:05, Emilio Pozuelo Monfort wrote:
>> Hi Antoine,
>>
>> On 09/11/2018 20:37, Antoine Beaupré wrote:
>>> On 2018-11-05 16:26:44, Emilio Pozuelo Monfort wrote:
 Hi,

 On 30/10/2018 16:46, Antoine Beaupré wrote:
> Which brings us to Thunderbird (and Firefox) themselves. The last I
> heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if
> he needed help on that last week, but haven't got a response. Hopefully
> all that work will come to fruitition synchronously in a grand fanfare
> of uploads all working out perfectly in the end. :)

 Sorry if I missed your mail. Anyway, here's an update:

 LLVM (and the necessary deps) were accepted. Unfortunately I run into some
 trouble while bootstrapping rustc and cargo. I tried some different ways 
 and
 finally fixed the first one (bootstrap using upstream binaries). I am 
 uploading
 the packages now and will follow up with firefox/thunderbird if all goes 
 well.
>>>
>>> Just so I see how fast I should be moving on Enigmail, when do you plan
>>> on uploading Thunderbird?
>>
>> The update is ready, and the blocker was an update to stretch, which has 
>> already
>> happen. So I believe we are ready, and this could happen anytime now.
>>
>> However since we don't have a working enigmail, should we delay the update 
>> until
>> we do? Given the security issues in thunderbird and the fact that the new
>> version has a Breaks on the old enigmail, I would say that we can go ahead 
>> with
>> thunderbird, and enigmail can be fixed asynchronously. However if the update 
>> is
>> not too far ahead, we could also delay this a bit longer.
>>
>> Thoughts?
> 
> I think we could manage a resolution with Enigmail soon enough, and
> considering how fast those updates were deployed on stretch, i don't
> know if we have a reasonable excuse to delay those in jessie.

Just to be clear, with 'those' are you referring to thunderbird, i.e. saying
that we should release the update now, and update enigmail asynchronously? That
is what I think you meant, but perhaps you were referring to enigmail instead,
maybe suggesting that we shouldn't delay the enigmail updates, i.e. we should
block the thunderbird update until the enigmail changes are ready.

Maybe I'm just being too dense, but if you could clarify which one you meant,
I'd appreciate it.

Thanks,
Emilio

(E)LTS report for October

[Emilio Pozuelo Monfort]

Hi,

For October, I spent 12h working on LTS on the rustc/cargo bootstrap My original
approach showed some problems, so I attempted to follow the approach taken for
stretch, reusing old packages from snapshot.debian.org. In the end that brought
its own set of problems due to those old packages depending on shared libs that
were too new for jessie, so I finally decided to went back to the original
approach, fixing the various problems that I saw.

I have accumulated some hours backlog, so I'll work this month towards clearing
that, and returning hours to the pool if necessary.

Cheers,
Emilio

Accepted imagemagick 8:6.8.9.9-5+deb8u15 (source all amd64) into oldstable

[Thorsten Alteholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 11 Nov 2018 17:03:02 +0100
Source: imagemagick
Binary: imagemagick-common imagemagick-doc libmagickcore-6-headers 
libmagickwand-6-headers libmagick++-6-headers imagemagick libimage-magick-perl 
libmagickcore-6-arch-config imagemagick-6.q16 libmagickcore-6.q16-2 
libmagickcore-6.q16-2-extra libmagickcore-6.q16-dev libmagickwand-6.q16-2 
libmagickwand-6.q16-dev libmagick++-6.q16-5 libmagick++-6.q16-dev 
imagemagick-dbg libimage-magick-q16-perl perlmagick libmagickcore-dev 
libmagickwand-dev libmagick++-dev
Architecture: source all amd64
Version: 8:6.8.9.9-5+deb8u15
Distribution: jessie-security
Urgency: high
Maintainer: ImageMagick Packaging Team 

Changed-By: Thorsten Alteholz 
Description:
 imagemagick - image manipulation programs -- binaries
 imagemagick-6.q16 - image manipulation programs -- quantum depth Q16
 imagemagick-common - image manipulation programs -- infrastructure
 imagemagick-dbg - debugging symbols for ImageMagick
 imagemagick-doc - document files of ImageMagick
 libimage-magick-perl - Perl interface to the ImageMagick graphics routines
 libimage-magick-q16-perl - Perl interface to the ImageMagick graphics routines 
-- Q16 versio
 libmagick++-6-headers - object-oriented C++ interface to ImageMagick - header 
files
 libmagick++-6.q16-5 - object-oriented C++ interface to ImageMagick
 libmagick++-6.q16-dev - object-oriented C++ interface to ImageMagick - 
development files
 libmagick++-dev - object-oriented C++ interface to ImageMagick
 libmagickcore-6-arch-config - low-level image manipulation library - 
architecture header files
 libmagickcore-6-headers - low-level image manipulation library - header files
 libmagickcore-6.q16-2 - low-level image manipulation library -- quantum depth 
Q16
 libmagickcore-6.q16-2-extra - low-level image manipulation library - extra 
codecs (Q16)
 libmagickcore-6.q16-dev - low-level image manipulation library - development 
files (Q16)
 libmagickcore-dev - low-level image manipulation library -- transition package
 libmagickwand-6-headers - image manipulation library - headers files
 libmagickwand-6.q16-2 - image manipulation library
 libmagickwand-6.q16-dev - image manipulation library - development files
 libmagickwand-dev - image manipulation library - transition for development 
files
 perlmagick - Perl interface to ImageMagick -- transition package
Changes:
 imagemagick (8:6.8.9.9-5+deb8u15) jessie-security; urgency=high
 .
   * Non-maintainer upload by the LTS Team.
   * CVE-2018-18025
 Fix for heap-based buffer over-read which can result in a denial of
 service via a crafted file.
Checksums-Sha1:
 aad94e4493f777860008a2a35eb7caf88c85b7c1 4387 imagemagick_6.8.9.9-5+deb8u15.dsc
 84abbeab6d142267fe6eedfbbfaec11d43075c48 7891624 
imagemagick_6.8.9.9.orig.tar.xz
 84e3972ed5c76855ff789ff1e52de3a9de533636 299836 
imagemagick_6.8.9.9-5+deb8u15.debian.tar.xz
 f8b6a227b168ffc3d0e149fc7f462f5dd722b166 154738 
imagemagick-common_6.8.9.9-5+deb8u15_all.deb
 3aeba02e4661ae82c4c184632e68df5c8d7dc7c3 7705938 
imagemagick-doc_6.8.9.9-5+deb8u15_all.deb
 3265fe7ac0ee0fe5785340072007181e0ad3f065 172408 
libmagickcore-6-headers_6.8.9.9-5+deb8u15_all.deb
 a52a0bee73b939a76e5e8766d59ff1bfa397701c 136212 
libmagickwand-6-headers_6.8.9.9-5+deb8u15_all.deb
 940171255a555d2a698a0cb39f24d7ec4096647b 170892 
libmagick++-6-headers_6.8.9.9-5+deb8u15_all.deb
 8bedd08fbd18118091e3c7da56113b9f0bbb35eb 160970 
imagemagick_6.8.9.9-5+deb8u15_amd64.deb
 6b3a6514e75c8677d2548ab52990e2cec6acfd1d 179516 
libimage-magick-perl_6.8.9.9-5+deb8u15_all.deb
 bf86248e9133ce641ebd2bde68a9b663610e10aa 134946 
libmagickcore-6-arch-config_6.8.9.9-5+deb8u15_amd64.deb
 7cb041272ffcced13f008596b8c078f25e0821f3 515120 
imagemagick-6.q16_6.8.9.9-5+deb8u15_amd64.deb
 6cd58a2a1425fcb6ff8d8ed6234fc51775cacb74 1692910 
libmagickcore-6.q16-2_6.8.9.9-5+deb8u15_amd64.deb
 4697e92411cfe940773e0f9312e4bb55b3561726 174676 
libmagickcore-6.q16-2-extra_6.8.9.9-5+deb8u15_amd64.deb
 82cf8fb03c8010f51038704fc0c10e98b2353bfa 1031692 
libmagickcore-6.q16-dev_6.8.9.9-5+deb8u15_amd64.deb
 a8b565cfd5b1dc1210c5e79ba0f54afe63146e6f 409216 
libmagickwand-6.q16-2_6.8.9.9-5+deb8u15_amd64.deb
 d0c562b5a9e53e0e73c5cb7de61f007bbd25dbe0 395854 
libmagickwand-6.q16-dev_6.8.9.9-5+deb8u15_amd64.deb
 91a6a451edfc2680faf31952f57b65fe729bcb57 259394 
libmagick++-6.q16-5_6.8.9.9-5+deb8u15_amd64.deb
 9b4af132c443aea587e60f10619b4d9040d0fa08 226156 
libmagick++-6.q16-dev_6.8.9.9-5+deb8u15_amd64.deb
 2cc8d77d51e2972fdd7e1cf07417f7cdf0481f45 5008712 
imagemagick-dbg_6.8.9.9-5+deb8u15_amd64.deb
 450c01f1a0e525451388d426d3b32499d1b70328 225250 
libimage-magick-q16-perl_6.8.9.9-5+deb8u15_amd64.deb
 763710fec7029335a1049cdc92d75e01beb7d34c 127408 
perlmagick_6.8.9.9-5+deb8u15_all.deb
 25d4e8d76fecf1658346f12f9a421a1ab6426457 127390 
libmagickcore-dev_6.8.9.9-5+deb8u15_all.deb
 e8e38eef7f57e35a19f4988c35d3243179ee8c15 127380 
libmagickwand-dev_6.8.9.9-5+deb8u15_all.deb
 

Re: updates on the gnupg/enigmail/thunderbird/firefox situation

[Antoine Beaupré]

On 2018-11-11 13:21:05, Emilio Pozuelo Monfort wrote:
> Hi Antoine,
>
> On 09/11/2018 20:37, Antoine Beaupré wrote:
>> On 2018-11-05 16:26:44, Emilio Pozuelo Monfort wrote:
>>> Hi,
>>>
>>> On 30/10/2018 16:46, Antoine Beaupré wrote:
 Which brings us to Thunderbird (and Firefox) themselves. The last I
 heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if
 he needed help on that last week, but haven't got a response. Hopefully
 all that work will come to fruitition synchronously in a grand fanfare
 of uploads all working out perfectly in the end. :)
>>>
>>> Sorry if I missed your mail. Anyway, here's an update:
>>>
>>> LLVM (and the necessary deps) were accepted. Unfortunately I run into some
>>> trouble while bootstrapping rustc and cargo. I tried some different ways and
>>> finally fixed the first one (bootstrap using upstream binaries). I am 
>>> uploading
>>> the packages now and will follow up with firefox/thunderbird if all goes 
>>> well.
>> 
>> Just so I see how fast I should be moving on Enigmail, when do you plan
>> on uploading Thunderbird?
>
> The update is ready, and the blocker was an update to stretch, which has 
> already
> happen. So I believe we are ready, and this could happen anytime now.
>
> However since we don't have a working enigmail, should we delay the update 
> until
> we do? Given the security issues in thunderbird and the fact that the new
> version has a Breaks on the old enigmail, I would say that we can go ahead 
> with
> thunderbird, and enigmail can be fixed asynchronously. However if the update 
> is
> not too far ahead, we could also delay this a bit longer.
>
> Thoughts?

I think we could manage a resolution with Enigmail soon enough, and
considering how fast those updates were deployed on stretch, i don't
know if we have a reasonable excuse to delay those in jessie.

A.

-- 
To be naive and easily deceived is impermissible, today more than
ever, when the prevailing untruths may lead to a catastrophe because
they blind people to real dangers and real possibilities.
- Erich Fromm

Re: Accepted firefox-esr 60.3.0esr-1~deb8u1 (source amd64 all) into oldstable, oldstable

[Emilio Pozuelo Monfort]

On 11/11/2018 13:50, Pascal Hambourg wrote:
> Hello,
> 
> In
> ,
> the status for i386 build is "Maybe-Given-back". What does it mean ?

It looks like the installability check wasn't run, and the build was tried even
if the build dependencies couldn't be satisfied. That moved the package to that
state.

Basically consider that a dep-wait on cargo, which is blocked on rustc. I'm
investigating that failure (and the armel llvm one, which is blocking the
firefox armel build).

Cheers,
Emilio

Re: Accepted firefox-esr 60.3.0esr-1~deb8u1 (source amd64 all) into oldstable, oldstable

[Pascal Hambourg]

Hello,

In 
, 
the status for i386 build is "Maybe-Given-back". What does it mean ?

Re: updates on the gnupg/enigmail/thunderbird/firefox situation

[Emilio Pozuelo Monfort]

Hi Antoine,

On 09/11/2018 20:37, Antoine Beaupré wrote:
> On 2018-11-05 16:26:44, Emilio Pozuelo Monfort wrote:
>> Hi,
>>
>> On 30/10/2018 16:46, Antoine Beaupré wrote:
>>> Which brings us to Thunderbird (and Firefox) themselves. The last I
>>> heard of this is that LLVM was NEW in jessie. I wrote Emilio to see if
>>> he needed help on that last week, but haven't got a response. Hopefully
>>> all that work will come to fruitition synchronously in a grand fanfare
>>> of uploads all working out perfectly in the end. :)
>>
>> Sorry if I missed your mail. Anyway, here's an update:
>>
>> LLVM (and the necessary deps) were accepted. Unfortunately I run into some
>> trouble while bootstrapping rustc and cargo. I tried some different ways and
>> finally fixed the first one (bootstrap using upstream binaries). I am 
>> uploading
>> the packages now and will follow up with firefox/thunderbird if all goes 
>> well.
> 
> Just so I see how fast I should be moving on Enigmail, when do you plan
> on uploading Thunderbird?

The update is ready, and the blocker was an update to stretch, which has already
happen. So I believe we are ready, and this could happen anytime now.

However since we don't have a working enigmail, should we delay the update until
we do? Given the security issues in thunderbird and the fact that the new
version has a Breaks on the old enigmail, I would say that we can go ahead with
thunderbird, and enigmail can be fixed asynchronously. However if the update is
not too far ahead, we could also delay this a bit longer.

Thoughts?

Emilio