So we have a few packages that seem to decide that if they fail with _FORTIFY_SOURCE they should undefine it and leave it at that, even if it's likely a bug in the code that causes overflow protections to be triggered, even though it might be a (rare) false positive (for what security is concerned at least). Since this is not the supposed approach, it would be a good idea to start warning when that method is used. Thanks, Diego
and what do you propose for the packages where foritfy source makes no sense ? like boot loaders or packages that dig around at the low level assembly ?
Ignore it as a false positive, given they are more than likely quite rare themselves?
dev-util/duma is "legally" using it: https://wiki.ubuntu.com/CompilerFlags#duma
Since the title mentions repoman, is it fair to assume that you only want to detect and warn when a Gentoo maintainer adds -U_FORTIFY_SOURCE, but allow when the upstream build system uses -U_FORTIFY_SOURCE on its own? If so, it seems like every place that repoman would flag is indeed an issue. Either the package is legitimately broken and needs to be fixed (not necessarily in Gentoo first) or the package is a false positive and upstream should be asked to suppress the fortification so that all distributions benefit from the determination that fortification was in error, at which point subsequent revisions of the Gentoo ebuild would no longer need to disable fortification on their own.
repoman support has been removed per bug 835013. Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
