[News item review] Portage rsync tree verification

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[News item review] Portage rsync tree verification

Michał Górny-5
Hi,

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 <[hidden email]>
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.

The verification is implemented using app-portage/gemato. Currently,
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 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, manual verification
is required before the first use.

On new Gentoo installations including portage-2.3.22, the 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 | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification

Duncan-42
Michał Górny posted on Thu, 25 Jan 2018 11:04:27 +0100 as excerpted:

> Hi,
>
> This one would be committed once new sys-apps/portage release is wrapped
> up and hits ~arch.
>
> ---
> Title: Portage rsync tree verification

Might want to put a paragraph in there saying git sync users can ignore,
or how they can get gpg signature verification as well if its possible.
(Sufficient to just link it if it's more involved than a single
paragraph, since this is primarily for rsync users.)

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification

Kristian Fiskerstrand-2
In reply to this post by Michał Górny-5
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
> <[hidden email]> 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.

>
> 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.

> 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?

> 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)

>
> On new Gentoo installations including portage-2.3.22, the

stage3s?

> 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/ ---
>

--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification

Michał Górny-5
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
> > <[hidden email]> 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 | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Michał Górny-5
In reply to this post by Michał Górny-5
Here's the updated version:

---
Title: Portage rsync tree verification
Author: Michał Górny <[hidden email]>
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 cryptographic
verification of the Gentoo rsync repository distributed over rsync
by default. This aims to prevent malicious third parties from altering
the contents of the ebuild repository received by our users.

This does not affect users syncing using git and other methods.
Appropriate verification mechanisms for them will be provided
in the future.

The verification is implemented via using app-portage/gemato. Currently,
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' USE flag on 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 information from the binary keyring 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, manual verification is required before the first use.

On Gentoo installations created using installation media that included
portage-2.3.22, the keys will already be covered by the installation
media 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 | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Aaron W. Swenson-2
On 2018-01-25 13:35, Michał Górny wrote:
> Display-If-Installed: <sys-apps/portage-2.3.21

Don't we want to tell people using >=2.3.22 this same information?

I know we don’t have expires, yet. How about making it
<sys-apps/portage-2.3.30?

signature.asc (386 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Ulrich Mueller-2
In reply to this post by Michał Górny-5
>>>>> On Thu, 25 Jan 2018, Michał Górny wrote:

> Here's the updated version:
> ---

> Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
> verification of the Gentoo rsync repository distributed over rsync
> by default.

Looks like there's one "rsync" too much in that sentence.

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Robin H. Johnson-2
In reply to this post by Michał Górny-5
On Thu, Jan 25, 2018 at 01:35:17PM +0100, Michał Górny wrote:
> Title: Portage rsync tree verification
> Author: Michał Górny <[hidden email]>
> Posted: 2018-01-xx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: <sys-apps/portage-2.3.21
Drop Display-If-Installed, they need to always see this until they know
it was bootstrapped.

> Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
> verification of the Gentoo rsync repository distributed over rsync
> by default.
Seems very wordy, suggested cleanup:
|| Starting with sys-apps/portage-2.3.22, Portage will verify the Gentoo
|| repository after rsync by default.

> This aims to prevent malicious third parties from altering
> the contents of the ebuild repository received by our users.
>
> This does not affect users syncing using git and other methods.
> Appropriate verification mechanisms for them will be provided
> in the future.
Note that emerge-webrsync has verification via FEATURES=webrsync-gpg?

Rewrite:
|| The new verification is intended for users who syncing via rsync.
|| Users who sync by emerge-webrsync should see [linkref].
|| Verification mechanisms for other methods of sync will be provided in
|| future.


> On Gentoo installations created using installation media that included
> portage-2.3.22, the keys will already be covered by the installation
> media 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
Either we should use real key here, or specifically note this is a fake
key output on purpose.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification

M. J. Everitt
In reply to this post by Kristian Fiskerstrand-2


On 25/01/18 11:01, Kristian Fiskerstrand wrote:
> On 01/25/2018 11:04 AM, Michał Górny wrote:
>
>> 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.
>
>
<nitpick>
"implemented with gemato" ?
</nitpick>


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Michał Górny-5
In reply to this post by Robin H. Johnson-2
W dniu czw, 25.01.2018 o godzinie 21∶37 +0000, użytkownik Robin H.
Johnson napisał:

> On Thu, Jan 25, 2018 at 01:35:17PM +0100, Michał Górny wrote:
> > Title: Portage rsync tree verification
> > Author: Michał Górny <[hidden email]>
> > Posted: 2018-01-xx
> > Revision: 1
> > News-Item-Format: 2.0
> > Display-If-Installed: <sys-apps/portage-2.3.21
>
> Drop Display-If-Installed, they need to always see this until they know
> it was bootstrapped.

Well, the idea was that if someone starts with stage that has >2.3.21,
then he has bootstrapped via verifying the stage signature.

> > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
> > verification of the Gentoo rsync repository distributed over rsync
> > by default.
>
> Seems very wordy, suggested cleanup:
> > > Starting with sys-apps/portage-2.3.22, Portage will verify the Gentoo
> > > repository after rsync by default.
> > This aims to prevent malicious third parties from altering
> > the contents of the ebuild repository received by our users.
> >
> > This does not affect users syncing using git and other methods.
> > Appropriate verification mechanisms for them will be provided
> > in the future.
>
> Note that emerge-webrsync has verification via FEATURES=webrsync-gpg?

I'm sorry, I have never used that. Does it cover full key maintenance
or rely on user to do the gpg work?

>
> Rewrite:
> > > The new verification is intended for users who syncing via rsync.
> > > Users who sync by emerge-webrsync should see [linkref].
> > > Verification mechanisms for other methods of sync will be provided in
> > > future.
>
>
> > On Gentoo installations created using installation media that included
> > portage-2.3.22, the keys will already be covered by the installation
> > media 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
>
> Either we should use real key here, or specifically note this is a fake
> key output on purpose.

Well, I've assumed most people would be able to figure out that it would
be quite a coincidence to see such a key id. I wanted to avoid putting
the real id so that people would actually check that HTTPS site instead
of relying on the security of news item delivery.

Will send an updated version tomorrow.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

R0b0t1
On Thu, Jan 25, 2018 at 3:45 PM, Michał Górny <[hidden email]> wrote:

> W dniu czw, 25.01.2018 o godzinie 21∶37 +0000, użytkownik Robin H.
> Johnson napisał:
>> On Thu, Jan 25, 2018 at 01:35:17PM +0100, Michał Górny wrote:
>> > Title: Portage rsync tree verification
>> > Author: Michał Górny <[hidden email]>
>> > Posted: 2018-01-xx
>> > Revision: 1
>> > News-Item-Format: 2.0
>> > Display-If-Installed: <sys-apps/portage-2.3.21
>>
>> Drop Display-If-Installed, they need to always see this until they know
>> it was bootstrapped.
>
> Well, the idea was that if someone starts with stage that has >2.3.21,
> then he has bootstrapped via verifying the stage signature.
>
>> > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
>> > verification of the Gentoo rsync repository distributed over rsync
>> > by default.
>>
>> Seems very wordy, suggested cleanup:
>> > > Starting with sys-apps/portage-2.3.22, Portage will verify the Gentoo
>> > > repository after rsync by default.
>> > This aims to prevent malicious third parties from altering
>> > the contents of the ebuild repository received by our users.
>> >
>> > This does not affect users syncing using git and other methods.
>> > Appropriate verification mechanisms for them will be provided
>> > in the future.
>>
>> Note that emerge-webrsync has verification via FEATURES=webrsync-gpg?
>
> I'm sorry, I have never used that. Does it cover full key maintenance
> or rely on user to do the gpg work?
>

It used to be necessary to set up a GnuPG home for portage and pull
the keys in, but now users can emerge app-crypt/gentoo-keys and set
PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release".

>>
>> Rewrite:
>> > > The new verification is intended for users who syncing via rsync.
>> > > Users who sync by emerge-webrsync should see [linkref].
>> > > Verification mechanisms for other methods of sync will be provided in
>> > > future.
>>
>>
>> > On Gentoo installations created using installation media that included
>> > portage-2.3.22, the keys will already be covered by the installation
>> > media 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
>>
>> Either we should use real key here, or specifically note this is a fake
>> key output on purpose.
>
> Well, I've assumed most people would be able to figure out that it would
> be quite a coincidence to see such a key id. I wanted to avoid putting
> the real id so that people would actually check that HTTPS site instead
> of relying on the security of news item delivery.
>
> Will send an updated version tomorrow.
>
> --
> Best regards,
> Michał Górny
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Alon Bar-Lev-2
In reply to this post by Michał Górny-5
Hi,

On 25 January 2018 at 14:35, Michał Górny <[hidden email]> wrote:
>
> Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
> verification of the Gentoo rsync repository distributed over rsync
> by default. This aims to prevent malicious third parties from altering
> the contents of the ebuild repository received by our users.

<snip>

I did not looked into the detailed implementation, however, please
make sure integrity check handles the same cases we have applied to
emerge-webrsync in the past, including:
1. Fast forward only in time, this is required to avoid hacker to
redirect into older portage to install vulnerabilities that were
approved at that time.
2. Content integrity, especially removal, as far as I understand, the
mechanism will not enable to detect authorized removal of content.

Regards,
Alon

Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Robin H. Johnson-2
On Thu, Jan 25, 2018 at 11:55:58PM +0200, Alon Bar-Lev wrote:
> I did not looked into the detailed implementation, however, please
> make sure integrity check handles the same cases we have applied to
> emerge-webrsync in the past, including:
Gemato is the implementation of GLEP74/MetaManifest, which DOES
explicitly address both of these concerns.

> 1. Fast forward only in time, this is required to avoid hacker to
> redirect into older portage to install vulnerabilities that were
> approved at that time.
Replay attacks per #1 are addressed via TIMESTAMP field in MetaManifest.

> 2. Content integrity, especially removal, as far as I understand, the
> mechanism will not enable to detect authorized removal of content.
I think you meant 'unauthorized' rather than 'authorized' here.
It will detect files that are expected to exist but are missing.

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Alon Bar-Lev-2
On 26 January 2018 at 00:21, Robin H. Johnson <[hidden email]> wrote:
> On Thu, Jan 25, 2018 at 11:55:58PM +0200, Alon Bar-Lev wrote:
>> I did not looked into the detailed implementation, however, please
>> make sure integrity check handles the same cases we have applied to
>> emerge-webrsync in the past, including:
> Gemato is the implementation of GLEP74/MetaManifest, which DOES
> explicitly address both of these concerns.

Good!
Thanks.

>
>> 1. Fast forward only in time, this is required to avoid hacker to
>> redirect into older portage to install vulnerabilities that were
>> approved at that time.
> Replay attacks per #1 are addressed via TIMESTAMP field in MetaManifest.

Interesting, I tried again to understand how it is working without
performing rsync to a temporary directory, compare the timestamp and
reject if unexpected.
Are we doing multiple rsync for the metadata?
Long since I used this insecure rsync...

For me it seems like webrsync and/or squashfs are much easier/faster
to apply integrity into than rsync... :)

Regards,
Alon

Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v3)

Michał Górny-5
In reply to this post by Michał Górny-5
Next round:

Title: Portage rsync tree verification
Author: Michał Górny <[hidden email]>
Posted: 2018-01-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-apps/portage

Starting with sys-apps/portage-2.3.22, Portage will verify the Gentoo
repository after rsync by default.

The new verification is intended for users who syncing via rsync.
Verification mechanisms for other methods of sync will be provided
in future.

This does not affect users syncing using git and other methods.
Appropriate verification mechanisms for them will be provided
in the future.

The verification is implemented via using app-portage/gemato. Currently,
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' USE flag on 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 information from the binary keyring 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, manual verification is required before the first use.

On Gentoo installations created using installation media that included
portage-2.3.22, the keys will already be covered by the installation
media 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

Please note that the above snippet does not include the real key id
on purpose. The primary key actually printed by gemato must match
the 'Gentoo Portage Snapshot Signing Key' on the website. 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 | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

Michał Górny-5
In reply to this post by R0b0t1
W dniu czw, 25.01.2018 o godzinie 15∶55 -0600, użytkownik R0b0t1
napisał:

> On Thu, Jan 25, 2018 at 3:45 PM, Michał Górny <[hidden email]> wrote:
> > W dniu czw, 25.01.2018 o godzinie 21∶37 +0000, użytkownik Robin H.
> > Johnson napisał:
> > > On Thu, Jan 25, 2018 at 01:35:17PM +0100, Michał Górny wrote:
> > > > Title: Portage rsync tree verification
> > > > Author: Michał Górny <[hidden email]>
> > > > Posted: 2018-01-xx
> > > > Revision: 1
> > > > News-Item-Format: 2.0
> > > > Display-If-Installed: <sys-apps/portage-2.3.21
> > >
> > > Drop Display-If-Installed, they need to always see this until they know
> > > it was bootstrapped.
> >
> > Well, the idea was that if someone starts with stage that has >2.3.21,
> > then he has bootstrapped via verifying the stage signature.
> >
> > > > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
> > > > verification of the Gentoo rsync repository distributed over rsync
> > > > by default.
> > >
> > > Seems very wordy, suggested cleanup:
> > > > > Starting with sys-apps/portage-2.3.22, Portage will verify the Gentoo
> > > > > repository after rsync by default.
> > > >
> > > > This aims to prevent malicious third parties from altering
> > > > the contents of the ebuild repository received by our users.
> > > >
> > > > This does not affect users syncing using git and other methods.
> > > > Appropriate verification mechanisms for them will be provided
> > > > in the future.
> > >
> > > Note that emerge-webrsync has verification via FEATURES=webrsync-gpg?
> >
> > I'm sorry, I have never used that. Does it cover full key maintenance
> > or rely on user to do the gpg work?
> >
>
> It used to be necessary to set up a GnuPG home for portage and pull
> the keys in, but now users can emerge app-crypt/gentoo-keys and set
> PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release".
>

In that case I'd rather not announce it until it is integrated properly.

--
Best regards,
Michał Górny


Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v3)

M. J. Everitt
In reply to this post by Michał Górny-5
On 27/01/18 14:26, Michał Górny wrote [excerpted]:
> The verification is implemented via using app-portage/gemato. Currently,
> the whole repository is verified after syncing.
>
I would drop either 'via' or 'using' - they both are the same
verb/meaning and one is hence redundant.
Just my 2c as a native English speaker :)

MJE


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v3)

Duncan-42
In reply to this post by Michał Górny-5
Michał Górny posted on Sat, 27 Jan 2018 15:26:44 +0100 as excerpted:

> The new verification is intended for users who syncing via rsync.
> Verification mechanisms for other methods of sync will be provided in
> future.


s/in future/in the future/

Thanks for adding that paragraph.  It perfectly addresses the question I
had about the original. =:^)

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v3)

Nils Freydank-2
In reply to this post by Michał Górny-5
Am Samstag, 27. Januar 2018, 15:26:44 CET schrieb Michał Górny:
> [...]
>
> The new verification is intended for users who syncing via rsync.
> Verification mechanisms for other methods of sync will be provided
> in future.
s/who syncing/who are syncing/

("who sync via rsync" would sound a bit odd, but should work aswell.)

--
GPG fingerprint: '766B 8122 1342 6912 3401 492A 8B54 D7A3 FF3C DB17'
Holgersson

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [News item review] Portage rsync tree verification (v2)

R0b0t1
In reply to this post by Michał Górny-5
On Sat, Jan 27, 2018 at 8:27 AM, Michał Górny <[hidden email]> wrote:

> W dniu czw, 25.01.2018 o godzinie 15∶55 -0600, użytkownik R0b0t1
> napisał:
>> On Thu, Jan 25, 2018 at 3:45 PM, Michał Górny <[hidden email]> wrote:
>> > W dniu czw, 25.01.2018 o godzinie 21∶37 +0000, użytkownik Robin H.
>> > Johnson napisał:
>> > > On Thu, Jan 25, 2018 at 01:35:17PM +0100, Michał Górny wrote:
>> > > > Title: Portage rsync tree verification
>> > > > Author: Michał Górny <[hidden email]>
>> > > > Posted: 2018-01-xx
>> > > > Revision: 1
>> > > > News-Item-Format: 2.0
>> > > > Display-If-Installed: <sys-apps/portage-2.3.21
>> > >
>> > > Drop Display-If-Installed, they need to always see this until they know
>> > > it was bootstrapped.
>> >
>> > Well, the idea was that if someone starts with stage that has >2.3.21,
>> > then he has bootstrapped via verifying the stage signature.
>> >
>> > > > Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
>> > > > verification of the Gentoo rsync repository distributed over rsync
>> > > > by default.
>> > >
>> > > Seems very wordy, suggested cleanup:
>> > > > > Starting with sys-apps/portage-2.3.22, Portage will verify the Gentoo
>> > > > > repository after rsync by default.
>> > > >
>> > > > This aims to prevent malicious third parties from altering
>> > > > the contents of the ebuild repository received by our users.
>> > > >
>> > > > This does not affect users syncing using git and other methods.
>> > > > Appropriate verification mechanisms for them will be provided
>> > > > in the future.
>> > >
>> > > Note that emerge-webrsync has verification via FEATURES=webrsync-gpg?
>> >
>> > I'm sorry, I have never used that. Does it cover full key maintenance
>> > or rely on user to do the gpg work?
>> >
>>
>> It used to be necessary to set up a GnuPG home for portage and pull
>> the keys in, but now users can emerge app-crypt/gentoo-keys and set
>> PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release".
>>
>
> In that case I'd rather not announce it until it is integrated properly.
>

What is "properly?" It's referenced in the handbook.

Cheers,
     R0b0t1

12