From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13364 invoked by alias); 17 Aug 2004 23:36:10 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 13352 invoked from network); 17 Aug 2004 23:36:09 -0000 Received: from unknown (HELO av8-2-sn2.hy.skanova.net) (81.228.8.111) by sourceware.org with SMTP; 17 Aug 2004 23:36:09 -0000 Received: by av8-2-sn2.hy.skanova.net (Postfix, from userid 502) id 0DD3037E62; Wed, 18 Aug 2004 01:36:02 +0200 (CEST) Received: from smtp2-1-sn2.hy.skanova.net (smtp2-1-sn2.hy.skanova.net [81.228.8.177]) by av8-2-sn2.hy.skanova.net (Postfix) with ESMTP id F208637E47; Wed, 18 Aug 2004 01:36:01 +0200 (CEST) Received: from [212.181.162.155] (h155n1fls24o1048.bredband.comhem.se [212.181.162.155]) by smtp2-1-sn2.hy.skanova.net (Postfix) with ESMTP id 5C91C37E42; Wed, 18 Aug 2004 01:36:04 +0200 (CEST) X-Sender: u22611592@m1.226.comhem.se Message-Id: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Aug 2004 23:42:00 -0000 To: Eric McDonald From: Hans Ronne Subject: Re: Major bug and what to do about it (long) Cc: xconq7@sources.redhat.com X-SW-Source: 2004/txt/msg00941.txt.bz2 >> The exploits are an interface problem. By eliminating the cause of the >> problem (the ability to attempt bogus actions) you fix all possible >> exploits in one stroke. > >I don't think that killing the patient is a good way to cure the >diesease. Can we please just keep existing functionality while >fixing the problems with it, instead of ripping out functionality >as a way of fixing the problems? I don't consider the ability to attempt bogus actions a functionality but a bug, and I think we both agree on that. What I am suggesting is a solution that will fix these problems forever. Just like putting wrapx on the accessor macros fixed all the wrapping bugs. >Properly dealing with bogus actions does not (or should not) >entail removing two actions. I am not suggesting that. I am suggesting that a fire-at action without a valid target should be converted into (default into) a fire-into action. See point 3 on my agenda. >Hans, I think a lot of our disagreement stems from which working >definition of 'fire-into' we are using. By 'fire-into' do you mean >fire and hit the first unit in the stack or a randomly (possibly >weighted by size) chosen unit from the stack? Or, do you mean that >there is a real possibility that nothing is hit even if there is a >stack of units in the cell? I have been arguing thinking that you >are working from the former definition, but have been urging that >we adopt the latter one. As I stated previously (point 4 in my agenda), I would like to change how fire-into works. I don't like the current situation where you get a free shot at all units in the stack for just one acp. What I would like to have is an action where you fire at the cell, one unit is picked as the target, and you either hit or miss that unit. The logic behind this would be that the shell has to land somewhere in the cell, and only one unit can sit where it lands. So yes, it would certainly be possible to do a fire-into action and not hit a single unit. I don't think that this a necessary preconditon for fixing the other bugs, though. I favour a step-by-step procedure. Hans