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 Mon, May 06, 2013 at 09:13:54AM +1000, Allan McRae wrote:
> On 06/05/13 00:46, Carlos O'Donell wrote:
> >>>
> >>> 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.
> >>>
> >>> 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.
> 
> Essentially.  I suppose the false positives are probably only a minor
> inconvenience as far as Linux distros go, given most rebuild their
> entire system when a glibc update happens and others can rebuild the
> small number of packages that will expose this.  But this can not be so
> readily handled with third party software.

Debian and Ubuntu (at least) certainly don't rebuild the world on every
toolchain bump, we allow things to rebuild organically as new package
versions are uploaded for other reasons.

If there's a simple/sane programmatic way for us to find everything that
would be affected by (4), so we can rebuild it (and declare a package
relationship between the new glibc and the old versions of packages that
it's now known to break), that's cool, but if it's just tripping over
breakages in the dark for a few years until it's all rebuilt, I'm not
sure that's an acceptable option for us.

... Adam


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