From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=DMARC_NONE,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=4.0.0 Received: from tesla.newpaltz.edu (tesla.newpaltz.edu [137.140.1.102]) by chiba.3jane.net (Postfix) with ESMTP id EFE402015DD4 for ; Sun, 17 Feb 2002 23:14:50 -0600 (CST) Received: from res57-81.resnet.newpaltz.edu (res57-81.resnet.newpaltz.edu [137.140.57.81]) by tesla.newpaltz.edu (8.9.3/8.9.3) with ESMTP id AAA19140 for ; Mon, 18 Feb 2002 00:12:59 -0500 (EST) Subject: Re: [gentoo-dev] RE: Portage package security model... From: "Bruce A. Locke" To: gentoo-dev@gentoo.org In-Reply-To: <20020218034908.0D8551EB0E@alderan.ohlmeier.de> References: <1013908809.1459.59.camel@damascus.packetknife.com> <20020218034908.0D8551EB0E@alderan.ohlmeier.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Feb 2002 00:13:33 -0500 Message-Id: <1014009213.8927.33.camel@kodiak.chronospace.org> Mime-Version: 1.0 Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: a4ac1876-ec84-40df-8937-714507a75400 X-Archives-Hash: 52cd5814a9b5971c2660f3992201dcd5 On Sun, 2002-02-17 at 22:56, Nils Ohlmeier wrote: > Maybe the developers are more busy with other things, but its never to early > to think about security. If this matter is important to you then please feel free to work on adding such functionality to portage. I would like to see a prototype of said system. :) Just a tip though: any such system should be easy to use for the developer and end user, and happen pretty much automatically for developers. I'm personally not going to be very friendly towards any system that requires me to do gnupg commands manually and worry about keys every time I want to check in a package, etc. And only the most paranoid users are going to go through the trouble of manually verifying each package (meaning it wouldn't be used by most users). It may sound lazy but considering upstream packages are not signed, most developers don't even know each other in real life, and you are implicitly trusting anyone who has the key and cvs access (any true paranoid would see what I'm talking about). Unless the system is simple and transparent for developers and end users its (disclaimer: in my view and my view alone) a pain that gives people a false sense of security about software they are downloading from the internet. There is also the issue of keys... who holds them, etc. The signing of packages could create political side effects and formalities. We have quite a few developers with CVS access. This means we are going to be sharing keys on multiple machines or have to go through a pain in the arse every time we want to check a package in. Such a system may force the solid formation of "teams" and encourage a more unfriendly BSD-style core development model. As a gentoo developer I like being able to work many different aspects of gentoo whenever I feel like it. And if a find an annoying bug I wish to fix, I like being able to fix it, rather then spending time asking whichever "team" is in charge of said package and having to ask for permission or whatever. (ok, I'm exagurating, but I've heard too many horror stories from the history of the *BSDs) If we decide to avoid a team based structure, then we are going to have to worry about individual keys. Most packages, although sometimes marked as having a maintainer, do not really have maintainers set in stone. Most of the packages are freely modified by any developer who has a real reason to make changes to said packages. Although there are exceptions, portage does have maintainers due to its importance and the fact its a gentoo creation (we are the upstream maintainers). Also if you as a developer are aware that someone is working on a package or has a pet project, its considered good etiquite to ask them first (chances are they are already working on the issue anyways). So that means we would either have to assign maintainers with keys to specific packages and have changes cleared through them, or have the system check every possible key against the package to see if the package has a valid signature from 1 of 30 or so developers (I'm guessing about that number). Another alternative is a global key. One key shared among all developers... IMHO, there isn't much point of signing after that... if the key is leaked (accounts hacked, etc) we'd have to get in touch with all developers, reissue keys, and resign all packages after verifying them all. Just my two cents on the issue, feel free to flame or just call me paranoid, crazy, etc ;) Personally, I liked the open (more carefree?) attitude towards the beginning of the project and I'd hate to see that go away because of its increased popularity :) -- Bruce A. Locke blocke@shivan.org "Those that would give up a necessary freedom for temporary safety deserve neither freedom nor safety." -- Ben Franklin