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 > > <mgo...@gentoo.org> Posted: 2018-01-xx Revision: 1 News-Item-Format: > > 2.0 Display-If-Installed: <sys-apps/portage-2.3.21 > > > > 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