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]
Patch for ebuild.sh
Created attachment 38917 [details, diff]
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
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)
readelf -v | head -n1
GNU readelf 18.104.22.168.1.1 20040303
With GNU readelf 22.214.171.124.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]
Update. This should work with all known revisions of binutils now.
Created attachment 40828 [details, 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:
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