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