pkgsrc-Users archive

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

Re: Another build failure - security/clamav



Pierre Pronchery <khorben%defora.org@localhost> writes:

> On 08/07/2017 00:36, Paul Goyette wrote:
>> Well, the issue with memtestplus is resolved, but now I'm getting the
>> following errors with clamav.
>>
>> Looks like a problem with the 'gets' macro? [...]
>
> This is because of FORTIFY indeed. I have an (ugly) patch for that
> (attached). Thoughts?

> [2. text/x-chdr; patch-libclamav_fmap.h]...

Thoughts:

  1) When something breaks with one of the newly-enabled security
  features, even if it's because the upstream code is buggy, we should
  just disable that feature on that package immediately.  I think we're
  doing that as the plan normally, but in this case clamav is still
  failing to build for me.

  2) If people don't like immediate disabling, we should probably have
  two values for the variable to disable it, one for things that people
  think can/should be fixed and one for those that are intractable, so
  that paranoid people can set something to force builds to fail for the
  first category.   But really that's a separate issue.

  3) These issues/fixes are not so conceptually different from other build
  fixes where a newer/different compiler catches bad code that the older
  compilers did not.  So they should be reported upstream, who may have
  something useful to say about how to fix.  If they don't, then we have
  to proceed anyway.

  4) It seems like clamav shouldn't even use gets.

and on the patch itself:

  It would be nice to have a comment that explains what is actually
  going on.  I'm guessing that the code defines a macro that shadows the
  function, but it would be good to say that and explain why the undef
  doesn't hurt.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index