[PATCH 01/21] Add --enable-fortify-source option

[Siddhesh Poyarekar]

On 2023-06-22 08:29, Adhemerval Zanella Netto wrote:
>>> I'd be happy to get more feedback on whether I should enforce
>>> disablement or not, especially from people who deal with distribution
>>> that set it by default.
>>
>> My worry is that with this on Ubuntu/Gentoo, there's no way through configure to disable fortification, which, importantly, is current behaviour.  The only way to do it would then be to pass CFLAGS to override the toolchain.  It's not the worst problem to have TBH, but I'd like Ubuntu or Gentoo maintainers to explicitly opt into it instead of us forcing it on them.
> 
> Do we really need another configure option? Any extra option requires extra
> maintainability effort to avoid it to bit-rotten (like --disable-shared [1]),
> this option would most likely to be always used (specially because distros
> are enabling fortify as default), and the fortify coverage are a superset
> of the default prototypes (meaning that programs that built and run with
> fortify enable should also run without it).

The option is needed for the small device users, where they often don't 
want to build with stack protector, fortification, or really anything 
that would accidentally make their devices more secure (sorry ;)).

The broader plan we had in mind was to disable by default in glibc-2.38 
and then enable by default in glibc-2.39.  That would also mean adding a 
b-m-g target with --disable-fortify to ensure that it doesn't bitrot.

Alternatively if we're feeling adventurous, we could just enable by 
default in 2.38 and be done with it.  Like you said, most distributions 
will enable it at first opportunity anyway and doing it by default is 
easier than modifying the build config to add a flag.  Let them add a 
flag if it's actually breaking things.  What do you think?

Thanks,
Sid