From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13084 invoked from network); 10 Nov 2004 13:46:59 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 10 Nov 2004 13:46:59 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CRsoN-0002lq-9L for arch-gentoo-security@lists.gentoo.org; Wed, 10 Nov 2004 13:46:59 +0000 Received: (qmail 30392 invoked by uid 89); 10 Nov 2004 13:46:38 +0000 Mailing-List: contact gentoo-security-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-security@gentoo.org Received: (qmail 29029 invoked from network); 10 Nov 2004 13:46:38 +0000 From: Antoine Martin To: Anthony Metcalf Cc: gentoo-security@lists.gentoo.org In-Reply-To: <20041110133121.00007f3c@Halloween> References: <20041110020620.F1ADE2B3DB@smtp.istop.com> <20041109233509.A19723@netdirect.ca> <200411101400.39645.jstubbs@work-at.co.jp> <1100091284.10299.19.camel@cobra> <20041110125531.GA13071@aeon.user.lan.at> <1100093186.10299.27.camel@cobra> <20041110133121.00007f3c@Halloween> Content-Type: text/plain Date: Wed, 10 Nov 2004 14:03:07 +0000 Message-Id: <1100095387.10299.33.camel@cobra> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1-1mdk Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-security] Re: Out of air X-Archives-Salt: d6a80695-6ec3-4a76-b9be-20c9692a71f4 X-Archives-Hash: 33fbaea592ab4ed38ce9a582ad0bdcdc On Wed, 2004-11-10 at 13:31 +0000, Anthony Metcalf wrote: > On Wed, 10 Nov 2004 13:26:26 +0000 > Antoine Martin wrote: > > > Sure, I agree with you. This is would not solve *all* problems. > > > > But it would solve the problem that this thread started on, which is to > > trust all the hops between your box and the gentoo servers. Which is a > > greater risk than a compromised gentoo server. > > The point, as many people have said, is that the "simple solution" is not as simple as it looks. The changes necessary to allow having up to date hashes of all the files, the file contining the hashes signed, and the checking of the file, and the hashes, *before* any remote info is run, would add significat develpoment time, prolonging the time for the *better* solution. Not to mention the processing would add a lot of overhead. I think this was mentioned before, but the few who would like to check these signatures would probably not mind having out of date hashes, and having to resync if they need to emerge that particular package - assuming it got changed just when they last synced. Or am I missing something? > Like to guess how long it would take to compile a list of hashes for the 100,000+ files in portage on my 450MHz server? I think someone already tried it on this list, a few minutes IIRC. > Yes there is a problem, yes there is a fix, the fix is on it's way, be patient. No disrespect, but if it has taken more than 1.5 years already - and I have not seen any release schedule, why not at least consider a temporary fix? -- gentoo-security@gentoo.org mailing list