As per user comments on distribution of security fixes http://lwn.net/Articles/99137/ This change will require all developers to make sure all objects have non-lazy runtime bindings.
Created attachment 38789 [details, diff] ebuild.sh.diff Patch for ebuild.sh
Created attachment 38917 [details, diff] ebuild.sh.diff Round #2 Changes: We ignore static executables now. We no longer incr the UNSAFE variable in order to give developers ample time to update ebuilds. I removed an extra block of code I had in the first patch which was only ment to be in my local copy.
i tried to apply the 'append-ldflags -Wl,-z,now' instruction, but the binary contains only the flag 'NOW', not 'BIND_NOW'. The ld man page says that's the same (i think ;) ), but (obvoiusly) the 'egrep "(FLAGS)(.*)BIND_NOW"' doesn't recognize it... Am I missing something or this could be spelled 'egrep "(FLAGS)(.*)NOW"' also? PS: gcc-3.3.4, libtool-1.5.2-r5
Christian, Could you please post the output of. readelf -d $binary
Created attachment 39116 [details] 'readelf -d' of suid binary: 'append-ldflags -Wl,-z,now' flags at 'FLAGS_1' position were made by the '-Wl,-z,now' gcc opt. '/usr/bin/ld', in my system, belongs to packages binutils, nasm, openldap, bin86 and glibc, in this install order (as for /var/log/emerge.log)
I'm using. readelf -v | head -n1 GNU readelf 2.15.90.0.1.1 20040303 With GNU readelf 2.14.90.0.8 20040114 it looks like we will have to use | egrep '\(FLAGS(.*)NOW' I'll update the patch later today.
Created attachment 39232 [details, diff] ebuild.sh.diff Update. This should work with all known revisions of binutils now.
2.0.51_pre21
Created attachment 40828 [details, diff] ebuild.sh.diff Attached is an update to the QA notice. It now shifts the notice from targeted at developers to users who are soon to be seeing the msg and opening bugs with respective maintainers who have missed it up to this point. Current portage release is sys-apps/portage-2.0.51_rc6
I thought according to this the developers were supposed to do something about this. What happens when the developer refuses to do anything about the problem as is the case with this bug: http://bugs.gentoo.org/show_bug.cgi?id=67205
donnie is not refusing todo anything about it. The facts are that xorg itself won't function properly with said flag. Xorg devs already know this and even coded special work arounds
Then can something be done to stop the qa message about xorg? Maybe I'm understanding things wrong when I read the ebuild.sh.diff that in a certain period of time it will be or can be marked as unsafe and will not build. Of course this has not happened yet, but I don't want it to happen.
just because the problem is known doesnt mean we can ignore it it serves as a remainder for now
Bug has been fixed and released in stable portages on or before 2.0.51-r2