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


Reply via email to