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)
signature.asc
Description: PGP signature
