While updating my xorg I get a qa security risk notice. I have LDFLAGS="-Wl,-O1,-z,now" in my /etc/make.conf. It is not being used with this ebuild. Reproducible: Always Steps to Reproduce: 1.emerge xorg 2. 3. Actual Results: fixing man page symlink: UI_get0_user_data.3.gz fixing man page symlink: positionCDKGraph.3.gz fixing man page symlink: addch.3x.gz fixing man page symlink: hosts.allow.5.gz fixing man page symlink: gimprc.5.gz fixing man page symlink: hosts.deny.5.gz fixing man page symlink: reject.8.gz fixing man page symlink: sendmail.8.gz fixing man page symlink: disable.8.gz QA Notice: Security risk /usr/X11R6/bin/Xorg. Please consider relinking with 'append-ldflags -Wl,-z,now' to fix. >>> Completed installing into /var/tmp/portage/xorg-x11-6.8.0-r2/image/ Expected Results: The linking should have been done with the ldflags so that there would not be a security risk. Portage 2.0.51_rc9 (gcc34-x86-2004.2, gcc-3.4.2, glibc-2.3.4.20041006-r0, 2.6.8-gentoo-r8 i686) ================================================================= System uname: 2.6.8-gentoo-r8 i686 Pentium III (Coppermine) Gentoo Base System version 1.5.3 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -mtune=i686 -O2 -funroll-loops -pipe -fno-unit-at-a-time" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -mtune=i686 -O2 -funroll-loops -pipe -fno-unit-at-a-time" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distlocks sandbox" GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://mirror.clarkson.edu/pub/distributions/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm arts avi berkdb bitmap-fonts cdr crypt cups doc encodeesd f77 foomaticdb gdbm gif gimp gimp-print gphoto2 gtk gtk2 imlib java jpeg kde ldap libg++ libwww mad mikmod motif mpeg ncurses nls nptl nptlonly oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xml2xmms xprint xv zlib"
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.