This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 03/05/13 23:35, Andreas Jaeger wrote:
> On 05/03/2013 04:52 AM, Carlos O'Donell wrote:
>> [...]
>>> 1) If not disabling, Ubuntu/OpenSUSE need to recompile ALL of affected
>>> >packages. Do you suggest to recompile all of them?
>> No. They need only recompile those applications that don't
>> conform to POSIX and expect a Linux-style select with support for
>> fds > 1024. Once recompiled we rely on __bos0 to make the
>> check dynamic, if it doesn't, then the package will need to disable
>> the check with a special fortify source flag.
>>
>> At the end of the day the community has worked hard to enable
>> _FORTIFY_SOURCE. The distributions made a*conscious*  choice to
>> turn on these checks. We are doing them a disservice if we disable
>> the checks in glibc because applications are having problems.
>>
>> It was the distribution's choice to enable the check. The package
>> maintainers need to work with the distribution and glibc to understand
>> the issues and fix their code. Nothing is fixed by Ruby calling
>> glibc "wrong" e.g. "the implementation is wrong... it wrongly assume
>> fd is always less than FD_SETSIZE (i.e. 1024)...". It's not wrong,
>> it's POSIX;-)
>>
>>> >Dear Ubuntu and OpenSUSE guys, please tell me your opinion. This patch
>>> >doesn't affect Fedora/RHEL/Debian. So I want to know which is close to
>>> >your desire.
>> Added Andreas and Adam to the TO.
> 
> 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.
> 
> 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.

Can I check I understand the consequences of this correctly.  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?

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.

Allan



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]