Re: [PATCH 1/5] __fdelt_chk: Removed range check

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

Hi,

Thanks for giving me input.

>> For openSUSE, we would only update glibc for a new release - and
>> recompile all packages against this new glibc anyway. So, we should be
>> fine.

Understood.


>> But this would also affect third-party binary packages that are outside
>> of the distribution - and this might be packages that are used on a
>> variety of distributions.

Hmmm...
Yes, this is terribly difficult issue. Unfortunately I also don't have
any data about third party softwares. I hope someone give us another
good input. ;)



> Can I check I understand the consequences of this correctly.

Sure. Of course.

>With this
> patch, binaries built against glibc prior to 2.18 will still work, but
> any _FORTIFY_SOURCE checks will not be performed until the
> software is rebuilt?

Right.


> It that is correct, it would be annoying in Arch Linux (we have
> _FORTIFY_SOURCE in our packaging CPPFLAGS, not hard coded in the
> compiler), as our packages are only rebuilt with updates - either to the
> software itself or with soname bumps in its dependencies.

Even if I drop this patch, you need to rebuild either. Because
softwares which uses Linux select() extension (e.g. bind, sudo,
rsyslog, openssh)
may crash if I drop this patch and you don't rebuild. Current glibc
code doesn't work on Linux extension.

Unfortunately, Nobody have full lists which packages affected this
issue. Then, you need to audit all packages manually and carefully
cherry pick
affected softwares. (or rebuild all packages)

In the other words, either disabling or not disabling, we'll get several pains.

1. If we disable __fdelt_chk and distro doesn't rebuild any packages.
   -> it works. but the packages are no longer protected by FORTIFY
       until rebuilt.

2. If we don't disable __fdelt_chk and distro doesn't rebuild any packages.
   -> Several software based on Linux extensions still may crash.
       Maybe this is not an option either.

3. If we disable __fdelt_chk and distro rebuild all packages.
   -> No sense. We don't need disable it if distro agree all rebuild.

4. If we don't disable __fdelt_chk and distro rebuild cherry
    picked packages.
    -> It works. Affected softwares are expected less than twenty.
        However the remained problem is, nobody know full lists
        of affected packages. And third party software which doesn't
        built still may crash.

Practically, only (1) and (4) are an option. There are no free lunch either.
Thus, I'd like to ask distro developers.