Summary: | QA Notice: Security risk with xorg-6.8.0-r2 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kathy Wills <kathywills> |
Component: | [OLD] Unspecified | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | hardened |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Kathy Wills
2004-10-12 01:57:04 UTC
No, it's not used. Because of the structure of X and its fun ELF module loader, it can't resolve all the symbols at build time. See bug #49038, especially comments #71 and #72, for what happened last time we tried something similar. You could try 6.8.0-r2 (masked), which has a "nonow" patch that should allow USE="dlloader" to work without crashing on undefined symbols (bug #64618) if you're using hardened gcc specs. dlloader is kind of the direction hardened X is moving in. poor X is going to be hit by this bug a few times. I have a bug open which just make it a simple QA notice vs one that would have the end user running around like a headless chicken not knowing what todo. hopefully dev-portage will merge it before stable .51 I am using xorg-6.8.0-r2. Notice the title of this bug report. I'm not using hardened gcc. See my emerge info. Good to know it. The above still holds true. And actually emerge info doesn't show whether you're using hardened gcc anymore as far as I know, because the specs files are switchable. If that is the case, why didn't the patch you mentioned take care of it? That patch is only applied on USE="hardened dlloader". Also, it doesn't fix this "bug," it works around another one where undefined symbols won't allow you to start X. I'm not the expert on it, but I think what it's actually doing is sort of the reverse of what you're requesting -- explicitly allowing the dlloader to _not_ resolve the symbols at build time. ajax, maybe you can correct me on that. By applied, I actually mean its effect is used. The patch is always applied, but it's not really activated without the USEs above. |