From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8642 invoked from network); 2 Oct 2004 03:35:44 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 2 Oct 2004 03:35:44 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CDagR-00032D-UG for arch-gentoo-dev@lists.gentoo.org; Sat, 02 Oct 2004 03:35:44 +0000 Received: (qmail 24961 invoked by uid 89); 2 Oct 2004 03:35:43 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 29855 invoked from network); 2 Oct 2004 03:35:42 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Date: Fri, 01 Oct 2004 20:35:37 -0700 Organization: Sometimes Message-ID: References: <1096599618.27475.712.camel@simple> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-66-58.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news Subject: [gentoo-dev] Re: Portage 2.0.51 comments/questions X-Archives-Salt: 8622ecbe-d72f-451b-b7be-e4e6b2e9e12b X-Archives-Hash: 407bff92128a298977b0695412c0ee03 Ned Ludd posted <1096599618.27475.712.camel@simple>, 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 idea. > 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 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! 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). 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 their job. 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." -- Benjamin Franklin -- gentoo-dev@gentoo.org mailing list