| 1 |
On 2/19/19 11:21 PM, Matthew Thode wrote: |
| 2 |
>> |
| 3 |
>> What problem would this solve? (Is adding gentoo-keys to @system the |
| 4 |
>> least bad way to solve it?) |
| 5 |
>> |
| 6 |
> |
| 7 |
> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify |
| 8 |
> portage tarballs. This is useful for the initial sync (as called out in |
| 9 |
> our manual). Otherwise using emerge-webrsync could be mitm'd or |
| 10 |
> otherwise messed with. |
| 11 |
|
| 12 |
Ok, then I agree with the goal if not the solution. This is a |
| 13 |
portage-specific thing, namely |
| 14 |
|
| 15 |
FEATURES=webrsync-gpg |
| 16 |
|
| 17 |
that should be enabled by default on a stage3. (Making new users go out |
| 18 |
of their way to add basic security is daft.) Portage already has |
| 19 |
USE=rsync-verify, and I think we could either |
| 20 |
|
| 21 |
a) expand the meaning of that flag to include enabling webrsync-gpg |
| 22 |
by default, and to pull in gentoo-keys; or |
| 23 |
|
| 24 |
b) add another (default-on) flag like USE=webrsync-verify to do it |
| 25 |
|
| 26 |
That flag would be enabled by default, so gentoo-keys would be pulled in |
| 27 |
as part of @system without actually being *in* the @system. Something |
| 28 |
along those lines would achieve the same goal in a cleaner way. |
| 29 |
|
| 30 |
|
| 31 |
> As far how we treat deps of @system packages, since this does not have |
| 32 |
> any deps that should help check that box for anyone worried. |
| 33 |
|
| 34 |
I meant the other way around. Once gentoo-keys is in @system, packages |
| 35 |
will (inconsistently) omit gentoo-keys from (R)DEPEND. There's no real |
| 36 |
policy or consensus on the matter, and it makes it a real PITA if we |
| 37 |
ever want to remove things from @system, because lots of packages will |
| 38 |
break in unpredictable ways. |
Archives