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.
