From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JhOmj-0006gK-G7 for garchives@archives.gentoo.org; Thu, 03 Apr 2008 12:43:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9D13FE0931; Thu, 3 Apr 2008 12:43:09 +0000 (UTC) Received: from mailhub-lb2.unibe.ch (mailhub-lb2.unibe.ch [130.92.0.83]) by pigeon.gentoo.org (Postfix) with ESMTP id 58A18E0931 for ; Thu, 3 Apr 2008 12:43:09 +0000 (UTC) Received: from localhost (scanhub-lb3.unibe.ch [130.92.5.67]) by mailhub-lb2.unibe.ch (Postfix) with ESMTP id E4870C444F for ; Thu, 3 Apr 2008 14:43:08 +0200 (CEST) X-Virus-checked: by University of Bern Received: from mailhub-lb2.unibe.ch ([130.92.0.83]) by localhost (scanhub-lb3.unibe.ch [130.92.5.67]) (amavisd-new, port 10024) with LMTP id Sfj4v1Bxq76e for ; Thu, 3 Apr 2008 14:43:08 +0200 (CEST) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub-lb2.unibe.ch (Postfix) with ESMTP id 369E9C42FE for ; Thu, 3 Apr 2008 14:43:08 +0200 (CEST) Received: from [130.92.65.87] (cubert [130.92.65.87]) by asterix.unibe.ch (8.13.6+Sun/8.13.6) with ESMTP id m33Ch7Cw022350 for ; Thu, 3 Apr 2008 14:43:07 +0200 (MEST) Message-ID: <47F4D13D.8010009@dev.gentooexperimental.org> Date: Thu, 03 Apr 2008 14:44:45 +0200 From: Patrick Lauer User-Agent: Thunderbird 2.0.0.12 (X11/20080304) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Monthly Gentoo Council Reminder for April References: <20080401092610.EEF7467349@smtp.gentoo.org> <47F3F098.1050508@gentoo.org> <47F3F860.6080200@gentoo.org> <47F3FA1C.7010407@gentoo.org> <47F4395A.3000509@gentoo.org> <47F4B9FC.2010907@gentoo.org> <47F4C0F8.7040906@gentoo.org> <20080403123921.3fc33a77@snowcone> <47F4C456.6080704@gentoo.org> <47F4C60B.8080605@gentoo.org> <20080403130151.12507f1a@snowcone> <47F4CAEF.2080106@gentoo.org> <20080403132326.19595c4b@snowcone> <47F4CD96.3070409@dev.gentooexperimental.org> <20080403133350.113f5696@snowcone> In-Reply-To: <20080403133350.113f5696@snowcone> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 46bee882-b9b1-43f2-b160-3fc3683f477d X-Archives-Hash: fa960b3c2f013abb0e88fa7259a1c7c4 Ciaran McCreesh wrote: > On Thu, 03 Apr 2008 14:29:10 +0200 > Patrick Lauer wrote: > >>> Nope. In fact, using such a system, there are ways of getting in >>> code that doesn't get triggered until someone's key gets >>> invalidated. >>> >> By this reasoning you shouldn't use passwords ... >> >> The idea is to limit the attack vectors and make simple attacks much >> harder. A sophisticated "hacker" could just rent a busload of angry >> serbians, kidnap 12 developers and force them to do some subtle >> changes in many places. But is that likely to happen? >> > > No no. The point is, there's no effective technological way of > preventing malicious developers from using the tree to screw over end > users. Signing isn't designed to and can't prevent that class of > attack (and nor can it protect against compromised end user systems). > What it *can* do is reduce the amount of damage done by a compromised > rsync server. > So then we should at first focus the discussion on a few things: - what classes of attackers are there - what defense mechanisms we can use - what the costs (complexity, time, extra code) of each defense is and then, from that design space, select the option(s) that have the best behaviour. If you get bored you can read the not-yet-GLEPs robbat2 has written with the help of a few others, which would cut out a large part of the discussion: http://viewcvs.gentoo.org/viewcvs.py/gentoo/users/robbat2/tree-signing-gleps/ That's exactly the thing under discussion -- the design of the system > necessitates trust in both the main repository and the end user system, > and signing does absolutely nothing to help there. No-one is suggesting > that anyone from infra is going to do anything to utterly screw over > Gentoo for petty personal reasons. > But if you don't trust anyone there is no reason why you would even try to interact with Gentoo. So at some point you will have to decide to arbitrarily trust a few entities, be it devs or servers or cryptographic keys ... -- gentoo-dev@lists.gentoo.org mailing list