On Sun, 2004-09-26 at 23:52, Duncan wrote: > What's this mean? What are the implications? How do I do that relinking > if I decide I need to? Can I fix it by enabling a feature in make.conf > or do I run a separate command? Either way, there's not enough info there > to actually DO it, nor do I even have enough info to rightly evaluate the > "security risk"! > > There's simply not enough there to be anything but a yet it's > labeled security risk. Someone's being *MEAN* with their teasing! =:^\ Sorry about that. This qa notice steams from an internal thread. It was intended for developers to see. I've got an open bug now to change the output of the qa notice. The append-ldflags is a function that comes from the flag-o-matic.eclass which is intended for the developer to use to add a string to the packages LDFLAGS. The user interface works just like the CFLAGS counterpart. So for example to make that message go away for crontab as a user you would do LDFLAGS="-Wl,-z,now" emerge virtual/cron The basic idea is rid our tree of setXid executables that have use lazy bindings. Lazy binding themselves present no immediate risk that's been documented. The behavior is just generally discouraged. To answer the question about can you add this to any files the answer is yes. For about a yaer or so now portage has accepted LDFLAGS via make.conf. Before you jump into a system-wide deployment of a linker flag be sure you understand what they do. The flag for one is known to slow down program startup. You wont really see it on a small executable but really big c++ app with alot of symbols that also loads alot of libraries you might. On the same token of slowdowns is the runtime speedup you gain because ld.so will already have looked up the entire symbol table. *mean* -solar -- Ned Ludd Gentoo (hardened,security,infrastructure,embedded,toolchain) Developer