From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40 invoked from network); 26 Sep 2004 17:25:19 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 26 Sep 2004 17:25:19 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CBclz-0006gR-58 for arch-gentoo-dev@lists.gentoo.org; Sun, 26 Sep 2004 17:25:19 +0000 Received: (qmail 14162 invoked by uid 89); 26 Sep 2004 17:25:18 +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 30970 invoked from network); 26 Sep 2004 17:25:18 +0000 Message-ID: <4156FB97.2020803@gentoo.org> Date: Sun, 26 Sep 2004 13:25:44 -0400 From: Kumba User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org References: <4151A04F.5090304@comcast.net> <200409251926.32676.blauwers@gentoo.org> <20040925185852.6352c326@enterprise.weeve.org> <41565E4B.6000808@comcast.net> <20040926101124.5d0f0dd2@enterprise.weeve.org> <4156F11C.4090809@comcast.net> In-Reply-To: <4156F11C.4090809@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Stack smash protected daemons [blah] X-Archives-Salt: 38a747aa-daa9-4f44-9db5-49888b77ed0d X-Archives-Hash: e7299a43d5fabb4d8191ff1d2f891287 This thread has been going on too long. The way I see it, there are two sides to this: Those who want SSP on by default, and those who don't. The question is, who has the better proposal? The answer is neither do. I'm an SSP user, having used it more or less since I first heard about it from solar. I use it on x86 and sparc64, and have had absolutely no problems with it. I don't use it on mips because mips is still a bit of an experimental arch. We've got three ABIs to deal with, and because SSP changes code generation just a little, there is always the possibility of something weird going on. That doesn't mean, however, that we'll never use it on mips. The problem inherent with SSP, however, is it doesn't get alot of attention. That is, few users truly know about it. This is largely why users don't actively use it, and why some are wary of using it. Even those that know of it sometimes don't know how it works (which is me to some extent). The solution, as I see it, is not to forcefully turn it on or turn it off automatically on a distro-wide scale, but rather to educate users about it, what it does, and why it can be beneficial. How this is done is really not my area, probably it deserves its own section in the Handbook, maybe we should drop a rather noticeable bit in the make.confs for archs it is fully tested on. I do believe SSP to be a good thing, and one that should be used whenever possible, but Gentoo is about choice. Turning on SSP by default goes against that choice, which is probably why some oppose SSP quite a bit. So rather than have this thread carry on about the pros and cons of SSP, how about someone cook up a unidiff against the make.conf's of know working archs (i.e., x86 & sparc64), and a unidiff against our docs that gives SSP the appropriate coverage and education it deserves. It probably doesn't fully address what either side wants, but it's something alot more productive than arguing about it. --Kumba -- "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond -- gentoo-dev@gentoo.org mailing list