Re: Re-shipping binaries due to _FORTIFY_SOURCE=3

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

Hello Peter,

well, this is a difficult topic. We have shipped quite a lot in the consecutive updates, but generally when we have any changes on the toolchain we cannot ship everything rebuilt at once. That would simply make the update too large.

Either we spend some time on Pakfire to upload less and then install so that we don’t have to worry about the update size at all any more, or we have to keep being conservative with what we ship at a time.

On this particular change, glibc is not affected, as it is being configured with its own CFLAGS. However, this particular change probably changes every single binary. We have re-shipped everything that exposes any network stuff, and crucial libraries that parse images, XML, and so on. I think that this pretty much the best we can do.

Best,
-Michael

> On 21 May 2024, at 10:50, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> while trying to figure out the odd Suricata and kernel behavior with Core Update 186
> I encountered the other day, I noted that cecad543cb59d0e052cea437cc064bb0924cdbd2
> mentions that having properly applied the  _FORTIFY_SOURCE=3 change entails that we
> re-ship "everything" (I assume that means every executable binary :-) ).
> 
> It seems like we didn't do so ever since this commit was merged into next, and while
> doing so in one go is not possible, I was wondering if we perhaps want to re-ship
> the most critical parts, such as binaries of services directly exposed to the network,
> the glibc, and similar components.
> 
> Just a thought that occurred to me.
> 
> Thanks, and best regards,
> Peter Müller