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 1JhOXY-0005Fw-S7 for garchives@archives.gentoo.org; Thu, 03 Apr 2008 12:27:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1C492E0AD5; Thu, 3 Apr 2008 12:27:35 +0000 (UTC) Received: from mailhub-lb2.unibe.ch (mailhub-lb2.unibe.ch [130.92.0.83]) by pigeon.gentoo.org (Postfix) with ESMTP id C8774E0AD5 for ; Thu, 3 Apr 2008 12:27:34 +0000 (UTC) Received: from localhost (scanhub-lb1.unibe.ch [130.92.5.65]) by mailhub-lb2.unibe.ch (Postfix) with ESMTP id F0D9AC4382 for ; Thu, 3 Apr 2008 14:27:33 +0200 (CEST) X-Virus-checked: by University of Bern Received: from mailhub-lb2.unibe.ch ([130.92.0.83]) by localhost (scanhub-lb1.unibe.ch [130.92.5.65]) (amavisd-new, port 10024) with LMTP id X6zHp+lNcj8O for ; Thu, 3 Apr 2008 14:27:33 +0200 (CEST) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub-lb2.unibe.ch (Postfix) with ESMTP id 4E7F8C4124 for ; Thu, 3 Apr 2008 14:27:33 +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 m33CRWko021134 for ; Thu, 3 Apr 2008 14:27:32 +0200 (MEST) Message-ID: <47F4CD96.3070409@dev.gentooexperimental.org> Date: Thu, 03 Apr 2008 14:29:10 +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> In-Reply-To: <20080403132326.19595c4b@snowcone> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 4ad5e03d-97b5-4575-806b-b8ae28d3e068 X-Archives-Hash: b4e1b7f476e6f719bcd92e1207e76bd5 Ciaran McCreesh wrote: > On Thu, 03 Apr 2008 13:17:51 +0100 > Mike Auty wrote: > >> Ciaran McCreesh wrote: >> | Signing offers no protection against a malicious developer. >> >> I had envisaged a system whereby when the tree was synced, as was some >> kind of master signed list of all acceptable dev-keys. Every package >> would also be signed, and would only be installed when signed. As >> soon as a dev becomes a liability their key is removed from the >> list/revoked. ~ On next sync any packages or package upgrades signed >> after the time of revocation would not be installed. There would be >> a window of vulnerability, but no bigger than with revoking a dev's >> access to the tree. Do you think this would offer suitable >> protection for users from a malicious dev or not? >> > > 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? > And if you are worrying about malicious developers, you need to worry > about malicious infra people too. An infra member throwing his toys out > of the pram can do much more lasting damage than someone who can get > some global scope nastiness into an ebuild for an hour or two... > That has nothing to do with the discussion ... and I don't see how infra could manipulate the signatures in a useful way apart from adding keys or removing some from the official keyring ... This they could do at the moment by manipulating the cvs to rsync copy process, but I'm not aware of something like that happening. So you might want to have a marginal trust in people and not accuse them of things they might do in the future ... -- gentoo-dev@lists.gentoo.org mailing list