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