|
Bugzilla – Full Text Bug Listing |
| Summary: | libs / apps build against glibc don't require glibc with fortify patch | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Dirk Mueller <dmueller> |
| Component: | Basesystem | Assignee: | Thorsten Kukuk <kukuk> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | lnussel, security-team |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Dirk Mueller
2005-12-06 13:26:01 UTC
They require it. But RPM is not able to differenciate for it. so? do we use a rpm based distribution or not? Yes, we use. And this also means we have to live with the limitations of a RPM based distribution. Develop and implement a SuSE/Novell package manager, and we can fix that. this either requires a patch to find-requires, or proper versioning in glibc. afaik the fortify stuff was backported from glibc 2.4, so they should've been tagged with a GLIBC_2.3.4_FORTIFY instead of plain GLIBC(2.3.4), which didn't really change the last few distro releases. This is nonsense. There was nothing backported from glibc 2.4 and the symbol versions are correct. This is a pure limitation of RPM and how symbol versions are handled depending on the used gcc and kernel header version. glibc symbol versioning *is* broken starting from 9.2. All glibcs since 9.1 have symbol version GLIBC_2.3.4 but the set of symbols referring to that version is different. That means you can happily run 10.0 binaries on 9.1 and they'll crash at runtime. The linker will not refuse to start them. See ~lnussel/Export/glibc for GLIBC_2.3.4 symbols on the different distros. As a side effect of the broken versioning a distribution upgrade 9.1 (SLES9!) -> 10.0+ (SLES10) becomes risky as the need for updating glibc first is not recorded in package meta data. That's not rpm's fault. There is nothing we can do about that for 10.0 anymore but for SLES10 it may not be too late yet. (In reply to comment #6) > glibc symbol versioning *is* broken starting from 9.2. All glibcs since 9.1 > have symbol version GLIBC_2.3.4 but the set of symbols referring to that > version is different. That means you can happily run 10.0 binaries on 9.1 and > they'll crash at runtime. The linker will not refuse to start them. > > See ~lnussel/Export/glibc for GLIBC_2.3.4 symbols on the different distros. Correct. glibc does not add any new symbols with that version since that date. > As a side effect of the broken versioning a distribution upgrade 9.1 (SLES9!) > -> 10.0+ (SLES10) becomes risky as the need for updating glibc first is not > recorded in package meta data. That's not rpm's fault. > > There is nothing we can do about that for 10.0 anymore but for SLES10 it may > not be too late yet. Ok, I will remove the FORTIFY patch from security team. This patch is the reason for that. The fortify patch is not the reason for that, because the _chk symbols are there anyway. our patch was only a change 4.1 -> 4.0 gcc requirement in a header... it did not affect the included symbols in glibc at all nor did it change glibc binaries. somone introduced the fortify symbols without bumping the symbol version. That's wrong. Look at the changelog. glibc development practice obviously defeats the purpose of symbol versioning. Fedora users got bitten by it a year ago already: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=141063 |