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 1CFA11382C5 for ; Thu, 25 Jan 2018 12:30:55 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EFA8EE09CA; Thu, 25 Jan 2018 12:30:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 8A7C4E098F for ; Thu, 25 Jan 2018 12:30:49 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (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 D348E335C2C; Thu, 25 Jan 2018 12:30:47 +0000 (UTC) Message-ID: <1516883444.1833.8.camel@gentoo.org> Subject: Re: [gentoo-dev] [News item review] Portage rsync tree verification From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Thu, 25 Jan 2018 13:30:44 +0100 In-Reply-To: <4b01cbd2-ce27-a701-46b8-472b32b9ef4e@gentoo.org> References: <1516874667.1833.4.camel@gentoo.org> <4b01cbd2-ce27-a701-46b8-472b32b9ef4e@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 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-Transfer-Encoding: 8bit X-Archives-Salt: 2e35228d-ae01-4e22-a9bc-71f5185f2b6c X-Archives-Hash: 67e55747a17a48d96858a4f96384c7a7 W dniu czw, 25.01.2018 o godzinie 12∶01 +0100, użytkownik Kristian Fiskerstrand napisał: > On 01/25/2018 11:04 AM, Michał Górny wrote: > > Hi, > > > > Thanks for your work on this! > > > This one would be committed once new sys-apps/portage release is > > wrapped up and hits ~arch. > > > > --- Title: Portage rsync tree verification Author: Michał Górny > > Posted: 2018-01-xx Revision: 1 News-Item-Format: > > 2.0 Display-If-Installed: > > > Starting with sys-apps/portage-2.3.22, Portage enables strong > > cryptographic verification of the Gentoo rsync tree by default. This > > aims to prevent malicious third parties from altering the contents of > > the ebuild repository received by our users. > > Just for sake of it, would remove "strong" here, as it is a description > and not PR document. Should we be consistent with referencing, so e.g > the Gentoo ebuild repository as distributed through rsync, or something? > Atm we seem to be using different terms all of the place, so should try > to harmonize a bit. Done. > > > > > The verification is implemented using app-portage/gemato. Currently, > > ... "implemented in", as opposed to "using"? its implemented using > various cryptographic primitives, but gemato is the implementation > itself of sorts. It was supposed to mean that Portage currently uses gemato to do the verification. 'via using' maybe? > > > the whole repository is verified after syncing. On systems with slow > > hard drives, this could take around 2 minutes. If you wish to > > disable it, you can disable the 'rsync-verify' flag on > > USE flag? Done. > > > sys-apps/portage or set 'sync-rsync-verify-metamanifest = no' in your > > repos.conf. > > > > Please note that the verification currently does not prevent Portage > > from using the repository after syncing. If 'emerge --sync' fails, do > > not install any packages and retry syncing. In case of prolonged or > > frequent verification failures, please make sure to report a bug > > including the failing mirror addresses (found in emerge.log). > > > > The verification uses keys provided by the app-crypt/gentoo-keys > > package. The keys are refreshed from the keyserver before every use > > in order to check for revocation. The post-sync verification ensures > > that the key package is verified itself. However, manua > > verification is required before the first use. > > Maybe some wording around binary keyring? e.g the verification uses > information from the binary keyring provided by app-crypt/gentoo-keys? > In particular the reference to "key package" might be misread (and the > keyring consists of multiple public keyblocks, that includes much more > information than the cryptographic keys per se) Done. > > > > > On new Gentoo installations including portage-2.3.22, the > > stage3s? Nah. I need to think how to word it properly. It's about installations that are created from new stages. > > > verification of the keys will be covered by verifying the > > installation media and repository snapshot signatures. On existing > > installations, you need to manually compare the primary key > > fingerprint (reported by gemato on every sync) against the official > > Gentoo keys [1]. An example gemato output is: > > > > INFO:root:Valid OpenPGP signature found: INFO:root:- primary key: > > 1234567890ABCDEF1234567890ABCDEF12345678 INFO:root:- subkey: > > FEDCBA0987654321FEDCBA0987654321FEDCBA09 > > > > The primary key printed must match 'Gentoo Portage Snapshot Signing > > Key' on the site. Please make sure to also check the certificate > > used for the secure connection to the site! > > > > [1]:https://www.gentoo.org/downloads/signatures/ --- > > > > -- Best regards, Michał Górny