From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E52331396D9 for ; Fri, 27 Oct 2017 06:22:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4B090E0C11; Fri, 27 Oct 2017 06:22:44 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F3DF3E0C03 for ; Fri, 27 Oct 2017 06:22:43 +0000 (UTC) Received: from [10.98.181.12] (public-gprs383564.centertel.pl [37.47.129.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id E9F4E33BE68; Fri, 27 Oct 2017 06:22:40 +0000 (UTC) Date: Fri, 27 Oct 2017 08:22:35 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [gentoo-dev] [RFC] GLEP 74: Full-tree verification using Manifest files To: gentoo-dev@lists.gentoo.org,Roy Bamford From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= Message-ID: X-Archives-Salt: 34ecba3a-e80c-4b1c-a1b0-8d0ab6dbbcc3 X-Archives-Hash: 5fe3a6f685b9a645abe1c23c1be85811 Dnia 26 pa=C5=BAdziernika 2017 23:58:53 CEST, Roy Bamford napisa=C5=82(a): >On 2017=2E10=2E26 21:12, Micha=C5=82 G=C3=B3rny wrote: >> Hi, everyone=2E >>=20 >> After a week of hard work, I'd like to request your comments >> on the draft of GLEP 74=2E This GLEP aims to replace the old >> tree-signing >> GLEPs 58 and 60 with a superior implementation and more complete >> specification=2E >>=20 >> The original tree-signing GLEPs were accepted a few years back but >> they >> have never been implemented=2E This specification, on the other hand, >> comes with a working reference implementation for the verification >> algorithm=2E I expect to finish the update/generation part in a few >> days, >> then work on additional optimizations (threading, incremental >> verification, incremental updates)=2E >>=20 >> ReST: https://dev=2Egentoo=2Eorg/~mgorny/tmp/glep-0074=2Erst >> HTML: https://dev=2Egentoo=2Eorg/~mgorny/tmp/glep-0074=2Ehtml >> impl: https://github=2Ecom/mgorny/gemato/ >>=20 >> Full text following for inline comments=2E >>=20 >[snip lots of hard work] >>=20 >> --=20 >> Best regards, >> Micha=C5=82 G=C3=B3rny >>=20 >>=20 >>=20 > >Micha=C5=82, > >Thank you for the hard work=2E > >This GLEP implies that users need to have the entire repository to >validate >and authenticate, if I understand it correctly=2E > >For example=20 >PORTAGE_RSYNC_EXTRA_OPTS=3D"--exclude=3D" >wil still work but the resulting tree could not be authenticaed=2E as >the top level signature would fail=2E=20 > >The manifests would still work correctly because they only apply to >the directory containing them=2E Pruning the repository at=20 >rsync time will therefore remove the manifents and the files that they >cover=2E > >Is that understanding correct? =20 Yes=2E We can't technically distinguish intentional package removal by use= r from malicious third party stripping them=2E This is something that a pac= kage manager extension might handle but it doesn't belong in the spec=2E --=20 Best regards, Micha=C5=82 G=C3=B3rny (by phone)