Re: Building LO 6.1.4.2 --with-system-jpeg and jpeg-9c fails

2019-01-22 Thread Kaganski Mike
On 22.01.2019 23:56, Dilyan Palauzov wrote:
> Hello Caolán,
> 
> what is the usefulness of a test, that behaves differently with different 
> jpeg libraries, but none of the test-outcomes is clearly wrong?

You could notice that the failing test is called testCVEs. It tests that 
known vulnerabilities are detected and rejected by the library, rather 
than get opened, so it checks that LibreOffice uses library versions 
that are safe with regards of those vulnerabilities.

But some libraries versions may decide later to stop rejecting those 
samples, including for good reasons, e.g. they might mitigate the 
exploit differently, so that the file could get opened then. This is not 
something that we should just accept without noticing. If that happens, 
we need to see it and understand why has it happened (is that an 
unintended regression in that external library, which could make 
LibreOffice vulnerable if overlooked, or is that actually a safe change 
there, which needs to change our tests to cover this library version?). 
This is what Caolán told you ("Someone who wants to use a system 
libjpeg-9 would have to investigate if it succeeds for a good reason or 
if its pure luck, e.g. via uninitialized data"). This is not the same as

> removing it completely.
> ...
> So removing this tests makes life simpler and causes no side effects.


-- 
Best regards,
Mike Kaganski
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice


Re: Building LO 6.1.4.2 --with-system-jpeg and jpeg-9c fails

2019-01-22 Thread Dilyan Palauzov
Hello Caolán,

what is the usefulness of a test, that behaves differently with different jpeg 
libraries, but none of the test-outcomes is clearly wrong?

Provided nobody states, that this test has an added value, I propose removing 
it completely.

Playing with build options costs just too much time and there are other issues 
(see my other mails) that forces one to try different --with(out)- 
combinations.  So removing this tests makes life simpler and causes no side 
effects.

Regards
  Дилян

On January 22, 2019 5:31:39 PM GMT+01:00, "Caolán McNamara" 
 wrote:
>On Tue, 2019-01-22 at 13:58 +, Дилян Палаузов wrote:
>> Hello,
>> 
>> libjpeg.so can originate from 
>> 
>> libjpeg-turbo, https://en.wikipedia.org/wiki/Libjpeg#libjpeg-turbo
>> mozjpeg, https://en.wikipedia.org/wiki/Libjpeg#mozjpeg or
>> ijg.org (jpeg-9c)
>> 
>> With ./configure --with-system-jpeg, having installed jpeg-9c as
>> /usr/local/lib/libjpeg.so, make fails with
>
>> I tried with or without --with-system-jpeg and it fails only in the
>> latter case.
>> 
>> What exactly is the problem?
>
>Well, its simply that the test expects
>vcl/qa/cppunit/graphicfilter/data/jpg/fail/crash-1.jpg to fail to load
>and it unexpectedly succeeded in loading.
>
>All those --with-system-foo options aren't guaranteed to work in all
>combinations. The bundled case is supposed to work, and the others are
>at your own risk, with the major distros typically keeping their own
>working, and libjpeg9 is unpopular as a default distro libjpeg
>
>Someone who wants to use a system libjpeg-9 would have to investigate
>if it succeeds for a good reason or if its pure luck, e.g. via
>uninitialized data. Running it under valgrind like the trailing debug
>text mentions would probably be good enough to rule out a "bad" success
>there.
>
>You can move it from the "fail" dir to the "indeterminate" if you just
>want to "get on with it"
>
>___
>LibreOffice mailing list
>LibreOffice@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/libreoffice
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice