1i5t5.duncan at cox
Oct 1, 2004, 8:35 PM
Post #14 of 14
Ned Ludd posted <1096599618.27475.712.camel [at] simpl>, excerpted below, on
Thu, 30 Sep 2004 23:00:18 -0400:
> On Sun, 2004-09-26 at 23:52, Duncan wrote:
[about portage .51's QA Notice: Security risk notice]
>> There's simply not enough there to be anything but a [tease] 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.
Thanks. Looking back, it's self-evident that the warning was designed for
developers, since that's what the other QA notices are. However, that
wasn't evident to me /before/ someone told me, and in any case, such a
user-visible label as worded is a bit of needlessly panicking the
populace, so even with the developer understanding, changing it is a good
> 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
> So for example to make that message go away for crontab as a user you
> would do LDFLAGS="-Wl,-z,now" emerge virtual/cron
OK. From the other posts and man gcc and man ld I'd figured out what was
involved there. I've looked at flag-o-matic for cflags so am familiar
with the idea there, but hadn't paid attention to ldflags and thus didn't
recognize the append-ldflags from there. Once I'd pieced together what
the rest did and that append-ldflags wasn't some sort of command I could
run from the command line or something, I decided it must be the portage
function (and guessed it was in an eclass but didn't bother to verify).
Nice to get verification of that and exactly where it is, now.
> 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.
OK, from various reading, I understand the (theoretical) worry about lazy
bindings on setXid executables. Thus, the level of threat is now known
and can be managed. This is a good thing! <g>
I don't know how the message is being changed, but having this sort of
info available about it would be nice and would have prevented alarming
the user (me). <g> Obviously, the message there can't be too verbose.
Perhaps a pointer to a QASECURITY.README file or a URL with the details?
All I want is to be an informed user, keeping in mind that from
a Gentoo dev perspective, their "user" is a sysadmin, and needs
such info, especially about security issues such as this, to properly do
IOW, this is basically the same request as I made some months ago about
changelogs entries denoting keyword removal. When I see an emerge -a with
a [ UD], I want to know /why/ I'm being asked to downgrade. Is it a
security issue or just some issue with functionality based on a USE flag I
don't even have turned on? Since making the request, at least amd64 which
I follow has been very good at providing this user/sysadmin that info, and
it's been that much easier to do my job /as/ that sysadmin.
So, I guess I owe both them and now you and the portage team a round of
thanks for being so responsive. Just another reason my Gentoo choice was
the RIGHT choice!
> 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.
Thanks for explaining that. I have it on for now, but may consider
turning it off for stuff like KDE when updates to it come out.
> *mean* -solar
Duncan - List replies preferred. No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
gentoo-dev [at] gentoo mailing list