https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: dev-cpp/notcurses-3.0.8 redefines _FORTIFY_SOURCE (HARDENED-SYSTEM). Discovered on: amd64 (internal ref: hardened_tinderbox) NOTE: (HARDENED-SYSTEM) in the summary means that the bug was found on a machine that runs an hardened profile with -D_FORTIFY_SOURCE=3 and -D_GLIBCXX_ASSERTIONS (https://www.gentoo.org/support/news-items/2023-01-01-hardening-fortify-assertions.html) but this bug MAY or MAY NOT BE related to the changes related to hardened.
Created attachment 849902 [details] build.log build log and emerge --info
ought i remove -D_FORTIFY_SOURCE from the upstream source? i'd rather not, since i want it on distros where it's not being injected. if i redefine it to be 3, it ought match the injected gentoo flags, and this issue would go away, right? tracking upstream at https://github.com/dankamongmen/notcurses/issues/2703
(In reply to nick black from comment #2) > ought i remove -D_FORTIFY_SOURCE from the upstream source? i'd rather not, > since i want it on distros where it's not being injected. > I usually suggest that folks add some build system arg to enable/disable hardening. > if i redefine it to be 3, it ought match the injected gentoo flags, and this > issue would go away, right? Our hardened profiles do F_S=3, and normal ones do F_S=2. You could do -U_F_S -D_F_S=3, but it's not very future proof. I'd say the best way is to just give an opt-out for distros where we do it via the toolchain instead, or write own form of https://www.gnu.org/software/autoconf-archive/ax_add_fortify_source.html (there's a PR pending upstream to add F_S=3 support for that). > > tracking upstream at https://github.com/dankamongmen/notcurses/issues/2703 thanks!
