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

[R0b0t1]

On Sat, Jan 27, 2018 at 8:27 AM, Michał Górny  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  wrote:
>> > W dniu czw, 25.01.2018 o godzinie 21∶37 +, 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 
>> > > > Posted: 2018-01-xx
>> > > > Revision: 1
>> > > > News-Item-Format: 2.0
>> > > > Display-If-Installed: > > >
>> > > 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

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

[Michał Górny]

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  wrote:
> > W dniu czw, 25.01.2018 o godzinie 21∶37 +, 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 
> > > > Posted: 2018-01-xx
> > > > Revision: 1
> > > > News-Item-Format: 2.0
> > > > Display-If-Installed:  > > 
> > > 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

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

[Alon Bar-Lev]

On 26 January 2018 at 00:21, Robin H. Johnson  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

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

[Robin H. Johnson]

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   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

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

[Alon Bar-Lev]

Hi,

On 25 January 2018 at 14:35, Michał Górny  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.



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

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

[R0b0t1]

On Thu, Jan 25, 2018 at 3:45 PM, Michał Górny  wrote:
> W dniu czw, 25.01.2018 o godzinie 21∶37 +, 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 
>> > Posted: 2018-01-xx
>> > Revision: 1
>> > News-Item-Format: 2.0
>> > Display-If-Installed: >
>> 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
>
>

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

[Michał Górny]

W dniu czw, 25.01.2018 o godzinie 21∶37 +, 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 
> > Posted: 2018-01-xx
> > Revision: 1
> > News-Item-Format: 2.0
> > Display-If-Installed:  
> 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

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

[Robin H. Johnson]

On Thu, Jan 25, 2018 at 01:35:17PM +0100, Michał Górny wrote:
> 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 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   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

[Ulrich Mueller]

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


pgpCx6DDEeinP.pgp
Description: PGP signature

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

[Aaron W. Swenson]

On 2018-01-25 13:35, Michał Górny wrote:
> Display-If-Installed: =2.3.22 this same information?

I know we don’t have expires, yet. How about making it


signature.asc
Description: Digital signature

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

[Michał Górny]

Here's the updated version:

---
Title: Portage rsync tree verification
Author: Michał Górny 
Posted: 2018-01-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: https://www.gentoo.org/downloads/signatures/
---

-- 
Best regards,
Michał Górny