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

[Michał Górny]

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@g.o> 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