[gentoo-dev] adding app-crypt/gentoo-keys to @system

[gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 275 bytes --]

As the title says, I think this should be done.

First sync is impossible to verify without keys (webrsync)
app-crypt/gentoo-keys has no dependencies, which help avoid some bloat
in the base install.

Let the bikeshedding begin.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Michael Orlitzky]

On 2/19/19 10:23 PM, Matthew Thode wrote:
> As the title says, I think this should be done.
> 
> First sync is impossible to verify without keys (webrsync)
> app-crypt/gentoo-keys has no dependencies, which help avoid some bloat
> in the base install.
> 
> Let the bikeshedding begin.
> 

I don't have app-crypt/gentoo-keys installed. I seem to be doing okay
without it.

In any case, on principle, we shouldn't add anything else to @system. No
one agrees on how we should treat @system packages as far as
dependencies go, and the whole idea is a stinky pile of dirty laundry
that we should work to make explicit instead.

What problem would this solve? (Is adding gentoo-keys to @system the
least bad way to solve it?)

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

On 19-02-19 23:04:26, Michael Orlitzky wrote:
> On 2/19/19 10:23 PM, Matthew Thode wrote:
> > As the title says, I think this should be done.
> > 
> > First sync is impossible to verify without keys (webrsync)
> > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat
> > in the base install.
> > 
> > Let the bikeshedding begin.
> > 
> 
> I don't have app-crypt/gentoo-keys installed. I seem to be doing okay
> without it.
> 
> In any case, on principle, we shouldn't add anything else to @system. No
> one agrees on how we should treat @system packages as far as
> dependencies go, and the whole idea is a stinky pile of dirty laundry
> that we should work to make explicit instead.
> 
> What problem would this solve? (Is adding gentoo-keys to @system the
> least bad way to solve it?)
> 

It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
portage tarballs.  This is useful for the initial sync (as called out in
our manual).  Otherwise using emerge-webrsync could be mitm'd or
otherwise messed with.

As far how we treat deps of @system packages, since this does not have
any deps that should help check that box for anyone worried.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Michael Orlitzky]

On 2/19/19 11:21 PM, Matthew Thode wrote:
>>
>> What problem would this solve? (Is adding gentoo-keys to @system the
>> least bad way to solve it?)
>>
> 
> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> portage tarballs.  This is useful for the initial sync (as called out in
> our manual).  Otherwise using emerge-webrsync could be mitm'd or
> otherwise messed with.

Ok, then I agree with the goal if not the solution. This is a
portage-specific thing, namely

  FEATURES=webrsync-gpg

that should be enabled by default on a stage3. (Making new users go out
of their way to add basic security is daft.) Portage already has
USE=rsync-verify, and I think we could either

  a) expand the meaning of that flag to include enabling webrsync-gpg
     by default, and to pull in gentoo-keys; or

  b) add another (default-on) flag like USE=webrsync-verify to do it

That flag would be enabled by default, so gentoo-keys would be pulled in
as part of @system without actually being *in* the @system. Something
along those lines would achieve the same goal in a cleaner way.


> As far how we treat deps of @system packages, since this does not have
> any deps that should help check that box for anyone worried.

I meant the other way around. Once gentoo-keys is in @system, packages
will (inconsistently) omit gentoo-keys from (R)DEPEND. There's no real
policy or consensus on the matter, and it makes it a real PITA if we
ever want to remove things from @system, because lots of packages will
break in unpredictable ways.

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On 19-02-20 00:00:04, Michael Orlitzky wrote:
> On 2/19/19 11:21 PM, Matthew Thode wrote:
> >>
> >> What problem would this solve? (Is adding gentoo-keys to @system the
> >> least bad way to solve it?)
> >>
> > 
> > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> > portage tarballs.  This is useful for the initial sync (as called out in
> > our manual).  Otherwise using emerge-webrsync could be mitm'd or
> > otherwise messed with.
> 
> Ok, then I agree with the goal if not the solution. This is a
> portage-specific thing, namely
> 
>   FEATURES=webrsync-gpg
> 
> that should be enabled by default on a stage3. (Making new users go out
> of their way to add basic security is daft.) Portage already has
> USE=rsync-verify, and I think we could either
> 
>   a) expand the meaning of that flag to include enabling webrsync-gpg
>      by default, and to pull in gentoo-keys; or
> 
>   b) add another (default-on) flag like USE=webrsync-verify to do it
> 
> That flag would be enabled by default, so gentoo-keys would be pulled in
> as part of @system without actually being *in* the @system. Something
> along those lines would achieve the same goal in a cleaner way.
> 
> 

This worksforme (optional, default enabled dep of portage with a default
feature flag change).

> > As far how we treat deps of @system packages, since this does not have
> > any deps that should help check that box for anyone worried.
> 
> I meant the other way around. Once gentoo-keys is in @system, packages
> will (inconsistently) omit gentoo-keys from (R)DEPEND. There's no real
> policy or consensus on the matter, and it makes it a real PITA if we
> ever want to remove things from @system, because lots of packages will
> break in unpredictable ways.
> 

Ah, ya, that makes sense.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Brian Dolbec]

On Tue, 19 Feb 2019 23:03:51 -0600
Matthew Thode <prometheanfire@gentoo.org> wrote:

> On 19-02-20 00:00:04, Michael Orlitzky wrote:
> > On 2/19/19 11:21 PM, Matthew Thode wrote:  
> > >>
> > >> What problem would this solve? (Is adding gentoo-keys to @system
> > >> the least bad way to solve it?)
> > >>  
> > > 
> > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> > > portage tarballs.  This is useful for the initial sync (as called
> > > out in our manual).  Otherwise using emerge-webrsync could be
> > > mitm'd or otherwise messed with.  
> > 
> > Ok, then I agree with the goal if not the solution. This is a
> > portage-specific thing, namely
> > 
> >   FEATURES=webrsync-gpg
> > 
> > that should be enabled by default on a stage3. (Making new users go
> > out of their way to add basic security is daft.) Portage already has
> > USE=rsync-verify, and I think we could either
> > 
> >   a) expand the meaning of that flag to include enabling
> > webrsync-gpg by default, and to pull in gentoo-keys; or
> > 
> >   b) add another (default-on) flag like USE=webrsync-verify to do it
> > 
> > That flag would be enabled by default, so gentoo-keys would be
> > pulled in as part of @system without actually being *in* the
> > @system. Something along those lines would achieve the same goal in
> > a cleaner way.
> > 
> >   
> 
> This worksforme (optional, default enabled dep of portage with a
> default feature flag change).
> 
> > > As far how we treat deps of @system packages, since this does not
> > > have any deps that should help check that box for anyone
> > > worried.  
> > 
> > I meant the other way around. Once gentoo-keys is in @system,
> > packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
> > There's no real policy or consensus on the matter, and it makes it
> > a real PITA if we ever want to remove things from @system, because
> > lots of packages will break in unpredictable ways.
> >   
> 
> Ah, ya, that makes sense.
> 

One of the things that releng has bantered about the last few years is
making a stage4 with these extra non @system pkgs.  The stage4 would
allow all the extra pkgs needed for new installs without adding to
@system.   The system set could possibly be trimmed a little more then
too.  Then knowledgeable users could work with minimal stage3's when it
suits their purpose while new users doing installs get the advantage of
the additional pre-installed pkgs.

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 2860 bytes --]

On 19-02-19 22:05:02, Brian Dolbec wrote:
> On Tue, 19 Feb 2019 23:03:51 -0600
> Matthew Thode <prometheanfire@gentoo.org> wrote:
> 
> > On 19-02-20 00:00:04, Michael Orlitzky wrote:
> > > On 2/19/19 11:21 PM, Matthew Thode wrote:  
> > > >>
> > > >> What problem would this solve? (Is adding gentoo-keys to @system
> > > >> the least bad way to solve it?)
> > > >>  
> > > > 
> > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> > > > portage tarballs.  This is useful for the initial sync (as called
> > > > out in our manual).  Otherwise using emerge-webrsync could be
> > > > mitm'd or otherwise messed with.  
> > > 
> > > Ok, then I agree with the goal if not the solution. This is a
> > > portage-specific thing, namely
> > > 
> > >   FEATURES=webrsync-gpg
> > > 
> > > that should be enabled by default on a stage3. (Making new users go
> > > out of their way to add basic security is daft.) Portage already has
> > > USE=rsync-verify, and I think we could either
> > > 
> > >   a) expand the meaning of that flag to include enabling
> > > webrsync-gpg by default, and to pull in gentoo-keys; or
> > > 
> > >   b) add another (default-on) flag like USE=webrsync-verify to do it
> > > 
> > > That flag would be enabled by default, so gentoo-keys would be
> > > pulled in as part of @system without actually being *in* the
> > > @system. Something along those lines would achieve the same goal in
> > > a cleaner way.
> > > 
> > >   
> > 
> > This worksforme (optional, default enabled dep of portage with a
> > default feature flag change).
> > 
> > > > As far how we treat deps of @system packages, since this does not
> > > > have any deps that should help check that box for anyone
> > > > worried.  
> > > 
> > > I meant the other way around. Once gentoo-keys is in @system,
> > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
> > > There's no real policy or consensus on the matter, and it makes it
> > > a real PITA if we ever want to remove things from @system, because
> > > lots of packages will break in unpredictable ways.
> > >   
> > 
> > Ah, ya, that makes sense.
> > 
> 
> One of the things that releng has bantered about the last few years is
> making a stage4 with these extra non @system pkgs.  The stage4 would
> allow all the extra pkgs needed for new installs without adding to
> @system.   The system set could possibly be trimmed a little more then
> too.  Then knowledgeable users could work with minimal stage3's when it
> suits their purpose while new users doing installs get the advantage of
> the additional pre-installed pkgs.
> 

ya, I'm currently using a systemd stage4 for openstack stuff, will update
it (as I made it in the first place) https://review.openstack.org/608102

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 3048 bytes --]

On 19-02-19 22:05:02, Brian Dolbec wrote:
> On Tue, 19 Feb 2019 23:03:51 -0600
> Matthew Thode <prometheanfire@gentoo.org> wrote:
> 
> > On 19-02-20 00:00:04, Michael Orlitzky wrote:
> > > On 2/19/19 11:21 PM, Matthew Thode wrote:  
> > > >>
> > > >> What problem would this solve? (Is adding gentoo-keys to @system
> > > >> the least bad way to solve it?)
> > > >>  
> > > > 
> > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> > > > portage tarballs.  This is useful for the initial sync (as called
> > > > out in our manual).  Otherwise using emerge-webrsync could be
> > > > mitm'd or otherwise messed with.  
> > > 
> > > Ok, then I agree with the goal if not the solution. This is a
> > > portage-specific thing, namely
> > > 
> > >   FEATURES=webrsync-gpg
> > > 
> > > that should be enabled by default on a stage3. (Making new users go
> > > out of their way to add basic security is daft.) Portage already has
> > > USE=rsync-verify, and I think we could either
> > > 
> > >   a) expand the meaning of that flag to include enabling
> > > webrsync-gpg by default, and to pull in gentoo-keys; or
> > > 
> > >   b) add another (default-on) flag like USE=webrsync-verify to do it
> > > 
> > > That flag would be enabled by default, so gentoo-keys would be
> > > pulled in as part of @system without actually being *in* the
> > > @system. Something along those lines would achieve the same goal in
> > > a cleaner way.
> > > 
> > >   
> > 
> > This worksforme (optional, default enabled dep of portage with a
> > default feature flag change).
> > 
> > > > As far how we treat deps of @system packages, since this does not
> > > > have any deps that should help check that box for anyone
> > > > worried.  
> > > 
> > > I meant the other way around. Once gentoo-keys is in @system,
> > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
> > > There's no real policy or consensus on the matter, and it makes it
> > > a real PITA if we ever want to remove things from @system, because
> > > lots of packages will break in unpredictable ways.
> > >   
> > 
> > Ah, ya, that makes sense.
> > 
> 
> One of the things that releng has bantered about the last few years is
> making a stage4 with these extra non @system pkgs.  The stage4 would
> allow all the extra pkgs needed for new installs without adding to
> @system.   The system set could possibly be trimmed a little more then
> too.  Then knowledgeable users could work with minimal stage3's when it
> suits their purpose while new users doing installs get the advantage of
> the additional pre-installed pkgs.
> 

Ok, after setting that up portage wants to update pgp keys, which fail
because keyservers suck.  It doesn't look like we can change the
keyservers or disable the update entirely but we can set the retries to
0 (which better disable it...).  Robbat2 had a patch to allow disabling
the update but it doesn't look like it was applied.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Rich Freeman]

On Fri, Feb 22, 2019 at 9:58 PM Matthew Thode <prometheanfire@gentoo.org> wrote:
>
> Ok, after setting that up portage wants to update pgp keys, which fail
> because keyservers suck.  It doesn't look like we can change the
> keyservers or disable the update entirely but we can set the retries to
> 0 (which better disable it...).  Robbat2 had a patch to allow disabling
> the update but it doesn't look like it was applied.

I assume that it proceeds after some timeout?  Or does it completely
bail?  IMO failing successful makes more sense though it is less
secure.

It definitely makes sense to attempt a keyserver update since that is
going to be the mechanism to catch key revocations.  It also will make
life easier on users using an older stage3 that happens to have
expired keys.  Well, assuming the keyserver works...

-- 
Rich

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

On 19-02-22 22:19:54, Rich Freeman wrote:
> On Fri, Feb 22, 2019 at 9:58 PM Matthew Thode <prometheanfire@gentoo.org> wrote:
> >
> > Ok, after setting that up portage wants to update pgp keys, which fail
> > because keyservers suck.  It doesn't look like we can change the
> > keyservers or disable the update entirely but we can set the retries to
> > 0 (which better disable it...).  Robbat2 had a patch to allow disabling
> > the update but it doesn't look like it was applied.
> 
> I assume that it proceeds after some timeout?  Or does it completely
> bail?  IMO failing successful makes more sense though it is less
> secure.
> 
> It definitely makes sense to attempt a keyserver update since that is
> going to be the mechanism to catch key revocations.  It also will make
> life easier on users using an older stage3 that happens to have
> expired keys.  Well, assuming the keyserver works...
> 

Na, times out the build (1.5 hour gate time...).  It retried nine
times...  I agree that updating is best, but nine times?

http://logs.openstack.org/02/608102/12/check/openstack-ansible-functional-gentoo-17-0-systemd/f866472/logs/host/lxc-cache-prep-commands.log.txt.gz

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3482 bytes --]

On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote:
> On 19-02-19 22:05:02, Brian Dolbec wrote:
> > On Tue, 19 Feb 2019 23:03:51 -0600
> > Matthew Thode <prometheanfire@gentoo.org> wrote:
> > 
> > > On 19-02-20 00:00:04, Michael Orlitzky wrote:
> > > > On 2/19/19 11:21 PM, Matthew Thode wrote:  
> > > > > > 
> > > > > > What problem would this solve? (Is adding gentoo-keys to @system
> > > > > > the least bad way to solve it?)
> > > > > >  
> > > > > 
> > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> > > > > portage tarballs.  This is useful for the initial sync (as called
> > > > > out in our manual).  Otherwise using emerge-webrsync could be
> > > > > mitm'd or otherwise messed with.  
> > > > 
> > > > Ok, then I agree with the goal if not the solution. This is a
> > > > portage-specific thing, namely
> > > > 
> > > >   FEATURES=webrsync-gpg
> > > > 
> > > > that should be enabled by default on a stage3. (Making new users go
> > > > out of their way to add basic security is daft.) Portage already has
> > > > USE=rsync-verify, and I think we could either
> > > > 
> > > >   a) expand the meaning of that flag to include enabling
> > > > webrsync-gpg by default, and to pull in gentoo-keys; or
> > > > 
> > > >   b) add another (default-on) flag like USE=webrsync-verify to do it
> > > > 
> > > > That flag would be enabled by default, so gentoo-keys would be
> > > > pulled in as part of @system without actually being *in* the
> > > > @system. Something along those lines would achieve the same goal in
> > > > a cleaner way.
> > > > 
> > > >   
> > > 
> > > This worksforme (optional, default enabled dep of portage with a
> > > default feature flag change).
> > > 
> > > > > As far how we treat deps of @system packages, since this does not
> > > > > have any deps that should help check that box for anyone
> > > > > worried.  
> > > > 
> > > > I meant the other way around. Once gentoo-keys is in @system,
> > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
> > > > There's no real policy or consensus on the matter, and it makes it
> > > > a real PITA if we ever want to remove things from @system, because
> > > > lots of packages will break in unpredictable ways.
> > > >   
> > > 
> > > Ah, ya, that makes sense.
> > > 
> > 
> > One of the things that releng has bantered about the last few years is
> > making a stage4 with these extra non @system pkgs.  The stage4 would
> > allow all the extra pkgs needed for new installs without adding to
> > @system.   The system set could possibly be trimmed a little more then
> > too.  Then knowledgeable users could work with minimal stage3's when it
> > suits their purpose while new users doing installs get the advantage of
> > the additional pre-installed pkgs.
> > 
> 
> Ok, after setting that up portage wants to update pgp keys, which fail
> because keyservers suck.  It doesn't look like we can change the
> keyservers or disable the update entirely but we can set the retries to
> 0 (which better disable it...).  Robbat2 had a patch to allow disabling
> the update but it doesn't look like it was applied.
> 

Disabling that means entirely killing the verification as it'd happily
use a revoked key.

Keyservers were supposed not to suck anymore.  Are you sure it's not
misconfigured network?  Maybe it's got broken-but-pretended IPv6?

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 3909 bytes --]

On 19-02-23 08:17:18, Michał Górny wrote:
> On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote:
> > On 19-02-19 22:05:02, Brian Dolbec wrote:
> > > On Tue, 19 Feb 2019 23:03:51 -0600
> > > Matthew Thode <prometheanfire@gentoo.org> wrote:
> > > 
> > > > On 19-02-20 00:00:04, Michael Orlitzky wrote:
> > > > > On 2/19/19 11:21 PM, Matthew Thode wrote:  
> > > > > > > 
> > > > > > > What problem would this solve? (Is adding gentoo-keys to @system
> > > > > > > the least bad way to solve it?)
> > > > > > >  
> > > > > > 
> > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> > > > > > portage tarballs.  This is useful for the initial sync (as called
> > > > > > out in our manual).  Otherwise using emerge-webrsync could be
> > > > > > mitm'd or otherwise messed with.  
> > > > > 
> > > > > Ok, then I agree with the goal if not the solution. This is a
> > > > > portage-specific thing, namely
> > > > > 
> > > > >   FEATURES=webrsync-gpg
> > > > > 
> > > > > that should be enabled by default on a stage3. (Making new users go
> > > > > out of their way to add basic security is daft.) Portage already has
> > > > > USE=rsync-verify, and I think we could either
> > > > > 
> > > > >   a) expand the meaning of that flag to include enabling
> > > > > webrsync-gpg by default, and to pull in gentoo-keys; or
> > > > > 
> > > > >   b) add another (default-on) flag like USE=webrsync-verify to do it
> > > > > 
> > > > > That flag would be enabled by default, so gentoo-keys would be
> > > > > pulled in as part of @system without actually being *in* the
> > > > > @system. Something along those lines would achieve the same goal in
> > > > > a cleaner way.
> > > > > 
> > > > >   
> > > > 
> > > > This worksforme (optional, default enabled dep of portage with a
> > > > default feature flag change).
> > > > 
> > > > > > As far how we treat deps of @system packages, since this does not
> > > > > > have any deps that should help check that box for anyone
> > > > > > worried.  
> > > > > 
> > > > > I meant the other way around. Once gentoo-keys is in @system,
> > > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
> > > > > There's no real policy or consensus on the matter, and it makes it
> > > > > a real PITA if we ever want to remove things from @system, because
> > > > > lots of packages will break in unpredictable ways.
> > > > >   
> > > > 
> > > > Ah, ya, that makes sense.
> > > > 
> > > 
> > > One of the things that releng has bantered about the last few years is
> > > making a stage4 with these extra non @system pkgs.  The stage4 would
> > > allow all the extra pkgs needed for new installs without adding to
> > > @system.   The system set could possibly be trimmed a little more then
> > > too.  Then knowledgeable users could work with minimal stage3's when it
> > > suits their purpose while new users doing installs get the advantage of
> > > the additional pre-installed pkgs.
> > > 
> > 
> > Ok, after setting that up portage wants to update pgp keys, which fail
> > because keyservers suck.  It doesn't look like we can change the
> > keyservers or disable the update entirely but we can set the retries to
> > 0 (which better disable it...).  Robbat2 had a patch to allow disabling
> > the update but it doesn't look like it was applied.
> > 
> 
> Disabling that means entirely killing the verification as it'd happily
> use a revoked key.
> 
> Keyservers were supposed not to suck anymore.  Are you sure it's not
> misconfigured network?  Maybe it's got broken-but-pretended IPv6?
> 

Just telling what I see.  I've had working ipv6 for a LONG time, perhaps
it's broken on their end (this mail is probably delivered via v6, last
one was).  If the functionality worked I wouldn't be asking about it
here.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[desultory]

On 02/23/19 02:17, Michał Górny wrote:
> On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote:
>> On 19-02-19 22:05:02, Brian Dolbec wrote:
>>> On Tue, 19 Feb 2019 23:03:51 -0600
>>> Matthew Thode <prometheanfire@gentoo.org> wrote:
>>>
>>>> On 19-02-20 00:00:04, Michael Orlitzky wrote:
>>>>> On 2/19/19 11:21 PM, Matthew Thode wrote:  
>>>>>>>
>>>>>>> What problem would this solve? (Is adding gentoo-keys to @system
>>>>>>> the least bad way to solve it?)
>>>>>>>  
>>>>>>
>>>>>> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
>>>>>> portage tarballs.  This is useful for the initial sync (as called
>>>>>> out in our manual).  Otherwise using emerge-webrsync could be
>>>>>> mitm'd or otherwise messed with.  
>>>>>
>>>>> Ok, then I agree with the goal if not the solution. This is a
>>>>> portage-specific thing, namely
>>>>>
>>>>>   FEATURES=webrsync-gpg
>>>>>
>>>>> that should be enabled by default on a stage3. (Making new users go
>>>>> out of their way to add basic security is daft.) Portage already has
>>>>> USE=rsync-verify, and I think we could either
>>>>>
>>>>>   a) expand the meaning of that flag to include enabling
>>>>> webrsync-gpg by default, and to pull in gentoo-keys; or
>>>>>
>>>>>   b) add another (default-on) flag like USE=webrsync-verify to do it
>>>>>
>>>>> That flag would be enabled by default, so gentoo-keys would be
>>>>> pulled in as part of @system without actually being *in* the
>>>>> @system. Something along those lines would achieve the same goal in
>>>>> a cleaner way.
>>>>>
>>>>>   
>>>>
>>>> This worksforme (optional, default enabled dep of portage with a
>>>> default feature flag change).
>>>>
>>>>>> As far how we treat deps of @system packages, since this does not
>>>>>> have any deps that should help check that box for anyone
>>>>>> worried.  
>>>>>
>>>>> I meant the other way around. Once gentoo-keys is in @system,
>>>>> packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
>>>>> There's no real policy or consensus on the matter, and it makes it
>>>>> a real PITA if we ever want to remove things from @system, because
>>>>> lots of packages will break in unpredictable ways.
>>>>>   
>>>>
>>>> Ah, ya, that makes sense.
>>>>
>>>
>>> One of the things that releng has bantered about the last few years is
>>> making a stage4 with these extra non @system pkgs.  The stage4 would
>>> allow all the extra pkgs needed for new installs without adding to
>>> @system.   The system set could possibly be trimmed a little more then
>>> too.  Then knowledgeable users could work with minimal stage3's when it
>>> suits their purpose while new users doing installs get the advantage of
>>> the additional pre-installed pkgs.
>>>
>>
>> Ok, after setting that up portage wants to update pgp keys, which fail
>> because keyservers suck.  It doesn't look like we can change the
>> keyservers or disable the update entirely but we can set the retries to
>> 0 (which better disable it...).  Robbat2 had a patch to allow disabling
>> the update but it doesn't look like it was applied.
>>
> 
> Disabling that means entirely killing the verification as it'd happily
> use a revoked key.
> 
> Keyservers were supposed not to suck anymore.  Are you sure it's not
> misconfigured network?  Maybe it's got broken-but-pretended IPv6?
> 
Given the ongoing volume of issues with this same area that have been
reported on the forums (and elsewhere), including by people whom I know
to be competent network administrators, it seems distinctly unlikely
that all of the issues come down to networking configuration errors.
Especially as the posited networking issues appear to affect nothing else.

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 4703 bytes --]

On Sat, 2019-02-23 at 15:39 -0500, desultory wrote:
> On 02/23/19 02:17, Michał Górny wrote:
> > On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote:
> > > On 19-02-19 22:05:02, Brian Dolbec wrote:
> > > > On Tue, 19 Feb 2019 23:03:51 -0600
> > > > Matthew Thode <prometheanfire@gentoo.org> wrote:
> > > > 
> > > > > On 19-02-20 00:00:04, Michael Orlitzky wrote:
> > > > > > On 2/19/19 11:21 PM, Matthew Thode wrote:  
> > > > > > > > 
> > > > > > > > What problem would this solve? (Is adding gentoo-keys to @system
> > > > > > > > the least bad way to solve it?)
> > > > > > > >  
> > > > > > > 
> > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> > > > > > > portage tarballs.  This is useful for the initial sync (as called
> > > > > > > out in our manual).  Otherwise using emerge-webrsync could be
> > > > > > > mitm'd or otherwise messed with.  
> > > > > > 
> > > > > > Ok, then I agree with the goal if not the solution. This is a
> > > > > > portage-specific thing, namely
> > > > > > 
> > > > > >   FEATURES=webrsync-gpg
> > > > > > 
> > > > > > that should be enabled by default on a stage3. (Making new users go
> > > > > > out of their way to add basic security is daft.) Portage already has
> > > > > > USE=rsync-verify, and I think we could either
> > > > > > 
> > > > > >   a) expand the meaning of that flag to include enabling
> > > > > > webrsync-gpg by default, and to pull in gentoo-keys; or
> > > > > > 
> > > > > >   b) add another (default-on) flag like USE=webrsync-verify to do it
> > > > > > 
> > > > > > That flag would be enabled by default, so gentoo-keys would be
> > > > > > pulled in as part of @system without actually being *in* the
> > > > > > @system. Something along those lines would achieve the same goal in
> > > > > > a cleaner way.
> > > > > > 
> > > > > >   
> > > > > 
> > > > > This worksforme (optional, default enabled dep of portage with a
> > > > > default feature flag change).
> > > > > 
> > > > > > > As far how we treat deps of @system packages, since this does not
> > > > > > > have any deps that should help check that box for anyone
> > > > > > > worried.  
> > > > > > 
> > > > > > I meant the other way around. Once gentoo-keys is in @system,
> > > > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
> > > > > > There's no real policy or consensus on the matter, and it makes it
> > > > > > a real PITA if we ever want to remove things from @system, because
> > > > > > lots of packages will break in unpredictable ways.
> > > > > >   
> > > > > 
> > > > > Ah, ya, that makes sense.
> > > > > 
> > > > 
> > > > One of the things that releng has bantered about the last few years is
> > > > making a stage4 with these extra non @system pkgs.  The stage4 would
> > > > allow all the extra pkgs needed for new installs without adding to
> > > > @system.   The system set could possibly be trimmed a little more then
> > > > too.  Then knowledgeable users could work with minimal stage3's when it
> > > > suits their purpose while new users doing installs get the advantage of
> > > > the additional pre-installed pkgs.
> > > > 
> > > 
> > > Ok, after setting that up portage wants to update pgp keys, which fail
> > > because keyservers suck.  It doesn't look like we can change the
> > > keyservers or disable the update entirely but we can set the retries to
> > > 0 (which better disable it...).  Robbat2 had a patch to allow disabling
> > > the update but it doesn't look like it was applied.
> > > 
> > 
> > Disabling that means entirely killing the verification as it'd happily
> > use a revoked key.
> > 
> > Keyservers were supposed not to suck anymore.  Are you sure it's not
> > misconfigured network?  Maybe it's got broken-but-pretended IPv6?
> > 
> 
> Given the ongoing volume of issues with this same area that have been
> reported on the forums (and elsewhere), including by people whom I know
> to be competent network administrators, it seems distinctly unlikely
> that all of the issues come down to networking configuration errors.
> Especially as the posited networking issues appear to affect nothing else.
> 

Yet instead of actually reporting bugs, talking to keyserver people
and providing information that could help resolve the issue... let me
guess, forum people instead share workarounds on how to kill security
in their Gentoo and complain between themselves.  Months later, someone
passes the complaints over to the ml as a side remark in some semi-
related thread, of course without caring to actually provide any helpful
data.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[desultory]

On 02/23/19 16:16, Michał Górny wrote:
> On Sat, 2019-02-23 at 15:39 -0500, desultory wrote:
>> On 02/23/19 02:17, Michał Górny wrote:
>>> On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote:
>>>> On 19-02-19 22:05:02, Brian Dolbec wrote:
>>>>> On Tue, 19 Feb 2019 23:03:51 -0600
>>>>> Matthew Thode <prometheanfire@gentoo.org> wrote:
>>>>>
>>>>>> On 19-02-20 00:00:04, Michael Orlitzky wrote:
>>>>>>> On 2/19/19 11:21 PM, Matthew Thode wrote:  
>>>>>>>>>
>>>>>>>>> What problem would this solve? (Is adding gentoo-keys to @system
>>>>>>>>> the least bad way to solve it?)
>>>>>>>>>  
>>>>>>>>
>>>>>>>> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
>>>>>>>> portage tarballs.  This is useful for the initial sync (as called
>>>>>>>> out in our manual).  Otherwise using emerge-webrsync could be
>>>>>>>> mitm'd or otherwise messed with.  
>>>>>>>
>>>>>>> Ok, then I agree with the goal if not the solution. This is a
>>>>>>> portage-specific thing, namely
>>>>>>>
>>>>>>>   FEATURES=webrsync-gpg
>>>>>>>
>>>>>>> that should be enabled by default on a stage3. (Making new users go
>>>>>>> out of their way to add basic security is daft.) Portage already has
>>>>>>> USE=rsync-verify, and I think we could either
>>>>>>>
>>>>>>>   a) expand the meaning of that flag to include enabling
>>>>>>> webrsync-gpg by default, and to pull in gentoo-keys; or
>>>>>>>
>>>>>>>   b) add another (default-on) flag like USE=webrsync-verify to do it
>>>>>>>
>>>>>>> That flag would be enabled by default, so gentoo-keys would be
>>>>>>> pulled in as part of @system without actually being *in* the
>>>>>>> @system. Something along those lines would achieve the same goal in
>>>>>>> a cleaner way.
>>>>>>>
>>>>>>>   
>>>>>>
>>>>>> This worksforme (optional, default enabled dep of portage with a
>>>>>> default feature flag change).
>>>>>>
>>>>>>>> As far how we treat deps of @system packages, since this does not
>>>>>>>> have any deps that should help check that box for anyone
>>>>>>>> worried.  
>>>>>>>
>>>>>>> I meant the other way around. Once gentoo-keys is in @system,
>>>>>>> packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
>>>>>>> There's no real policy or consensus on the matter, and it makes it
>>>>>>> a real PITA if we ever want to remove things from @system, because
>>>>>>> lots of packages will break in unpredictable ways.
>>>>>>>   
>>>>>>
>>>>>> Ah, ya, that makes sense.
>>>>>>
>>>>>
>>>>> One of the things that releng has bantered about the last few years is
>>>>> making a stage4 with these extra non @system pkgs.  The stage4 would
>>>>> allow all the extra pkgs needed for new installs without adding to
>>>>> @system.   The system set could possibly be trimmed a little more then
>>>>> too.  Then knowledgeable users could work with minimal stage3's when it
>>>>> suits their purpose while new users doing installs get the advantage of
>>>>> the additional pre-installed pkgs.
>>>>>
>>>>
>>>> Ok, after setting that up portage wants to update pgp keys, which fail
>>>> because keyservers suck.  It doesn't look like we can change the
>>>> keyservers or disable the update entirely but we can set the retries to
>>>> 0 (which better disable it...).  Robbat2 had a patch to allow disabling
>>>> the update but it doesn't look like it was applied.
>>>>
>>>
>>> Disabling that means entirely killing the verification as it'd happily
>>> use a revoked key.
>>>
>>> Keyservers were supposed not to suck anymore.  Are you sure it's not
>>> misconfigured network?  Maybe it's got broken-but-pretended IPv6?
>>>
>>
>> Given the ongoing volume of issues with this same area that have been
>> reported on the forums (and elsewhere), including by people whom I know
>> to be competent network administrators, it seems distinctly unlikely
>> that all of the issues come down to networking configuration errors.
>> Especially as the posited networking issues appear to affect nothing else.
>>
> 
> Yet instead of actually reporting bugs, talking to keyserver people
> and providing information that could help resolve the issue... let me
> guess, forum people instead share workarounds on how to kill security
> in their Gentoo and complain between themselves.  Months later, someone
> passes the complaints over to the ml as a side remark in some semi-
> related thread, of course without caring to actually provide any helpful
> data.
> 
Last I checked, forcing users to file bug reports was, at best,
impractical; encouraging them to has been as much as we can
realistically do. Not that such bugs have not been filed, as you well know.

As for "talking to keyserver people", for one thing most users do not
even know how to find the right parties to contact, and even when they
do or are directed to them reporting "you had downtime, please fix it"
seems distinctly pointless if the administrators are paying any
attention at all to their services, and rather moreso if they aren't.

Workarounds are about as much as one can do when they cannot access
otherwise required services to perform updates. The best available
approach left to users is keeping the workarounds in place for the
minimum amount of time to do the work that they need to get done.

I had thought that directly replying to the maintainer without side
commentary did not count as "a side remark in some semi-related thread".
As for the timing and context, I have recently been (incorrectly) told
that the forums project is "isolationist" and thus have decided to make
an effort to dispel such false claims by more actively participating in
other media, despite forums being my primary area of responsibility; and
did not (and still do not) see a need to compile a list of reports when,
presumably, your search engine of choice would suffice to find them by
the dozen. Further, you are CC:ed on and have commented on related and
as yet unresolved bugs, so this should hardly be new information to you.

So, please, do kindly leave handwaving, strawmen, and appeals to
ridicule out of technical discussion, they serve no useful purpose.

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]

On 19-02-23 08:17:18, Michał Górny wrote:
> On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote:
> > On 19-02-19 22:05:02, Brian Dolbec wrote:
> > > On Tue, 19 Feb 2019 23:03:51 -0600
> > > Matthew Thode <prometheanfire@gentoo.org> wrote:
> > > 
> > > > On 19-02-20 00:00:04, Michael Orlitzky wrote:
> > > > > On 2/19/19 11:21 PM, Matthew Thode wrote:  
> > > > > > > 
> > > > > > > What problem would this solve? (Is adding gentoo-keys to @system
> > > > > > > the least bad way to solve it?)
> > > > > > >  
> > > > > > 
> > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> > > > > > portage tarballs.  This is useful for the initial sync (as called
> > > > > > out in our manual).  Otherwise using emerge-webrsync could be
> > > > > > mitm'd or otherwise messed with.  
> > > > > 
> > > > > Ok, then I agree with the goal if not the solution. This is a
> > > > > portage-specific thing, namely
> > > > > 
> > > > >   FEATURES=webrsync-gpg
> > > > > 
> > > > > that should be enabled by default on a stage3. (Making new users go
> > > > > out of their way to add basic security is daft.) Portage already has
> > > > > USE=rsync-verify, and I think we could either
> > > > > 
> > > > >   a) expand the meaning of that flag to include enabling
> > > > > webrsync-gpg by default, and to pull in gentoo-keys; or
> > > > > 
> > > > >   b) add another (default-on) flag like USE=webrsync-verify to do it
> > > > > 
> > > > > That flag would be enabled by default, so gentoo-keys would be
> > > > > pulled in as part of @system without actually being *in* the
> > > > > @system. Something along those lines would achieve the same goal in
> > > > > a cleaner way.
> > > > > 
> > > > >   
> > > > 
> > > > This worksforme (optional, default enabled dep of portage with a
> > > > default feature flag change).
> > > > 
> > > > > > As far how we treat deps of @system packages, since this does not
> > > > > > have any deps that should help check that box for anyone
> > > > > > worried.  
> > > > > 
> > > > > I meant the other way around. Once gentoo-keys is in @system,
> > > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
> > > > > There's no real policy or consensus on the matter, and it makes it
> > > > > a real PITA if we ever want to remove things from @system, because
> > > > > lots of packages will break in unpredictable ways.
> > > > >   
> > > > 
> > > > Ah, ya, that makes sense.
> > > > 
> > > 
> > > One of the things that releng has bantered about the last few years is
> > > making a stage4 with these extra non @system pkgs.  The stage4 would
> > > allow all the extra pkgs needed for new installs without adding to
> > > @system.   The system set could possibly be trimmed a little more then
> > > too.  Then knowledgeable users could work with minimal stage3's when it
> > > suits their purpose while new users doing installs get the advantage of
> > > the additional pre-installed pkgs.
> > > 
> > 
> > Ok, after setting that up portage wants to update pgp keys, which fail
> > because keyservers suck.  It doesn't look like we can change the
> > keyservers or disable the update entirely but we can set the retries to
> > 0 (which better disable it...).  Robbat2 had a patch to allow disabling
> > the update but it doesn't look like it was applied.
> > 
> 
> Disabling that means entirely killing the verification as it'd happily
> use a revoked key.
> 
> Keyservers were supposed not to suck anymore.  Are you sure it's not
> misconfigured network?  Maybe it's got broken-but-pretended IPv6?
> 

How about we allow a setting for controling which keyserver to refresh
from.  SKS has had problems, fedora has been better (and a coworker says
MIT is ok too).  Aparently they have a max key size set or something to
work around keyserver 'brokenness'.

Something similiar to this would be nice, but for keyservers.

https://gist.github.com/robbat2/551fc8ea56408ee48e99909f9c26c13e

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Thomas Deutschmann]

[-- Attachment #1.1: Type: text/plain, Size: 1251 bytes --]

Hi,

On 2019-02-25 17:09, Matthew Thode wrote:
> How about we allow a setting for controling which keyserver to refresh
> from.  SKS has had problems, fedora has been better (and a coworker says
> MIT is ok too).  Aparently they have a max key size set or something to
> work around keyserver 'brokenness'.
> 
> Something similiar to this would be nice, but for keyservers.
> 
> https://gist.github.com/robbat2/551fc8ea56408ee48e99909f9c26c13e

I am still not sure which problem you are trying to solve:

If you provide a way to disable key updates, you can also disable
verification in general: Our threat model allows for compromised keys
(just because you can't prevent that), so it is _essential_ that you
verify that the key is still valid as part of _each_ validation.

Fedora's keyserver are part of the normal SKS network.

Yes, gnupg doesn't handle keyserver failures very well. I.e. no real
timeout and switch to another server. But we enabled WKD a long time ago
which fixed most problems for me because this will avoid normal
keyservers in general. So I am wondering which problems do you have...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 712 bytes --]

On Tue, 2019-02-19 at 21:23 -0600, Matthew Thode wrote:
> As the title says, I think this should be done.
> 
> First sync is impossible to verify without keys (webrsync)
> app-crypt/gentoo-keys has no dependencies, which help avoid some bloat
> in the base install.
> 

This is the wrong place to add it, and the wrong package.

If Portage (still) needs it for whatever, then it should be a dependency
of Portage.

However, app-crypt/openpgp-keys-gentoo-release should be entirely
sufficient, and it works without all the voodoo dependencies and 'run
programs as root' logic of gkeys.  If there's anything in Portage left
not using it, it should be ported.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1216 bytes --]

On 19-02-20 08:35:10, Michał Górny wrote:
> On Tue, 2019-02-19 at 21:23 -0600, Matthew Thode wrote:
> > As the title says, I think this should be done.
> > 
> > First sync is impossible to verify without keys (webrsync)
> > app-crypt/gentoo-keys has no dependencies, which help avoid some bloat
> > in the base install.
> > 
> 
> This is the wrong place to add it, and the wrong package.
> 
> If Portage (still) needs it for whatever, then it should be a dependency
> of Portage.
> 
> However, app-crypt/openpgp-keys-gentoo-release should be entirely
> sufficient, and it works without all the voodoo dependencies and 'run
> programs as root' logic of gkeys.  If there's anything in Portage left
> not using it, it should be ported.
> 

FEATURES="webrsync-gpg" emerge-webrsync fails to work with just the file.

PORTAGE_GPG_DIR="/var/lib/gentoo/gkeys/keyrings/gentoo/release" FEATURES="webrsync-gpg" emerge-webrsync
works

PORTAGE_GPG_DIR="/usr/share/openpgp-keys/" FEATURES="webrsync-gpg" emerge-webrsync
emerge-webrsync: error: signature verification failed
(same for the file).

Maybe some of the interior portage stuff should be fixed then?

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

On 19-02-19 21:23:33, Matthew Thode wrote:
> As the title says, I think this should be done.
> 
> First sync is impossible to verify without keys (webrsync)
> app-crypt/gentoo-keys has no dependencies, which help avoid some bloat
> in the base install.
> 
> Let the bikeshedding begin.
> 

Looks like it's a docs problem.  https://bugs.gentoo.org/671816

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]