[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ASAN builds and exiv2



On 28/11/17 20:43, Antoine Beaupré wrote:
> On 2017-11-27 20:38:20, Roberto C. Sánchez wrote:
>> On Thu, Nov 23, 2017 at 02:51:56PM -0500, Antoine Beaupré wrote:
>>>
>>> So I ended up adding it to the debian/rules file, but that wasn't enough
>>> either - I had to add "export" to every line so it shows up in the
>>> environment.
>>
>> I think that the problem you are seeing is related to sbuild.  Here is
>> the command I used to build with gbp and cowbuilder:
>>
>> DH_VERBOSE=1 DEB_CFLAGS_APPEND=-fsanitize=address
>> DEB_CPPFLAGS_APPEND=-fsanitize=address
>> DEB_CXXFLAGS_APPEND=-fsanitize=address
>> DEB_LDFLAGS_APPEND=-lasan gbp buildpackage --git-dist=jessie 
>>
>> The -static-libasan option produced the linking error you reported near
>> the end of the build, which is why I switched to -lasan.  I also had to
>> add libasan1 to Build-Depends.
>>
>> I have attached the build log so that you can confirm the resulting
>> commands that were executed to build the package.
>>
>> After building with that command I installed the packages in a wheezy
>> Docker and ran the exiv2 binary with the three proofs of concept from
>> the three GitHub issues.  None of them appear to trigger the reported
>> vulnerabilities.  Based on this and on Raphael's comments in this
>> thread, I think that the correct reolution is to mark the issues as
>> not-affected for wheezy.
>>
>> I have attached the verbose output of the POC runs with the ASAN version
>> of the package so that you or someone else can review the output and
>> either concur or dissent with my analysis.
> 
> I agree. I can't reproduce the issues with 0.23-1 (no need even to go
> back to +deb7u1) either (using valgrind).
> 
> So I'll just mark those as N/A.

Note that valgrind doesn't catch all problems that asan does. The asan state in
wheezy is not very good, it may be easier to test in jessie in some cases if the
package in question builds fine there (I did that in the past). In any case I
don't think you can conclude that the package is not affected because this is
not reproducible with valgrind.

Cheers,
Emilio


Reply to: