1 |
On Sat, 2019-02-23 at 15:39 -0500, desultory wrote: |
2 |
> On 02/23/19 02:17, Michał Górny wrote: |
3 |
> > On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote: |
4 |
> > > On 19-02-19 22:05:02, Brian Dolbec wrote: |
5 |
> > > > On Tue, 19 Feb 2019 23:03:51 -0600 |
6 |
> > > > Matthew Thode <prometheanfire@g.o> wrote: |
7 |
> > > > |
8 |
> > > > > On 19-02-20 00:00:04, Michael Orlitzky wrote: |
9 |
> > > > > > On 2/19/19 11:21 PM, Matthew Thode wrote: |
10 |
> > > > > > > > |
11 |
> > > > > > > > What problem would this solve? (Is adding gentoo-keys to @system |
12 |
> > > > > > > > the least bad way to solve it?) |
13 |
> > > > > > > > |
14 |
> > > > > > > |
15 |
> > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify |
16 |
> > > > > > > portage tarballs. This is useful for the initial sync (as called |
17 |
> > > > > > > out in our manual). Otherwise using emerge-webrsync could be |
18 |
> > > > > > > mitm'd or otherwise messed with. |
19 |
> > > > > > |
20 |
> > > > > > Ok, then I agree with the goal if not the solution. This is a |
21 |
> > > > > > portage-specific thing, namely |
22 |
> > > > > > |
23 |
> > > > > > FEATURES=webrsync-gpg |
24 |
> > > > > > |
25 |
> > > > > > that should be enabled by default on a stage3. (Making new users go |
26 |
> > > > > > out of their way to add basic security is daft.) Portage already has |
27 |
> > > > > > USE=rsync-verify, and I think we could either |
28 |
> > > > > > |
29 |
> > > > > > a) expand the meaning of that flag to include enabling |
30 |
> > > > > > webrsync-gpg by default, and to pull in gentoo-keys; or |
31 |
> > > > > > |
32 |
> > > > > > b) add another (default-on) flag like USE=webrsync-verify to do it |
33 |
> > > > > > |
34 |
> > > > > > That flag would be enabled by default, so gentoo-keys would be |
35 |
> > > > > > pulled in as part of @system without actually being *in* the |
36 |
> > > > > > @system. Something along those lines would achieve the same goal in |
37 |
> > > > > > a cleaner way. |
38 |
> > > > > > |
39 |
> > > > > > |
40 |
> > > > > |
41 |
> > > > > This worksforme (optional, default enabled dep of portage with a |
42 |
> > > > > default feature flag change). |
43 |
> > > > > |
44 |
> > > > > > > As far how we treat deps of @system packages, since this does not |
45 |
> > > > > > > have any deps that should help check that box for anyone |
46 |
> > > > > > > worried. |
47 |
> > > > > > |
48 |
> > > > > > I meant the other way around. Once gentoo-keys is in @system, |
49 |
> > > > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. |
50 |
> > > > > > There's no real policy or consensus on the matter, and it makes it |
51 |
> > > > > > a real PITA if we ever want to remove things from @system, because |
52 |
> > > > > > lots of packages will break in unpredictable ways. |
53 |
> > > > > > |
54 |
> > > > > |
55 |
> > > > > Ah, ya, that makes sense. |
56 |
> > > > > |
57 |
> > > > |
58 |
> > > > One of the things that releng has bantered about the last few years is |
59 |
> > > > making a stage4 with these extra non @system pkgs. The stage4 would |
60 |
> > > > allow all the extra pkgs needed for new installs without adding to |
61 |
> > > > @system. The system set could possibly be trimmed a little more then |
62 |
> > > > too. Then knowledgeable users could work with minimal stage3's when it |
63 |
> > > > suits their purpose while new users doing installs get the advantage of |
64 |
> > > > the additional pre-installed pkgs. |
65 |
> > > > |
66 |
> > > |
67 |
> > > Ok, after setting that up portage wants to update pgp keys, which fail |
68 |
> > > because keyservers suck. It doesn't look like we can change the |
69 |
> > > keyservers or disable the update entirely but we can set the retries to |
70 |
> > > 0 (which better disable it...). Robbat2 had a patch to allow disabling |
71 |
> > > the update but it doesn't look like it was applied. |
72 |
> > > |
73 |
> > |
74 |
> > Disabling that means entirely killing the verification as it'd happily |
75 |
> > use a revoked key. |
76 |
> > |
77 |
> > Keyservers were supposed not to suck anymore. Are you sure it's not |
78 |
> > misconfigured network? Maybe it's got broken-but-pretended IPv6? |
79 |
> > |
80 |
> |
81 |
> Given the ongoing volume of issues with this same area that have been |
82 |
> reported on the forums (and elsewhere), including by people whom I know |
83 |
> to be competent network administrators, it seems distinctly unlikely |
84 |
> that all of the issues come down to networking configuration errors. |
85 |
> Especially as the posited networking issues appear to affect nothing else. |
86 |
> |
87 |
|
88 |
Yet instead of actually reporting bugs, talking to keyserver people |
89 |
and providing information that could help resolve the issue... let me |
90 |
guess, forum people instead share workarounds on how to kill security |
91 |
in their Gentoo and complain between themselves. Months later, someone |
92 |
passes the complaints over to the ml as a side remark in some semi- |
93 |
related thread, of course without caring to actually provide any helpful |
94 |
data. |
95 |
|
96 |
-- |
97 |
Best regards, |
98 |
Michał Górny |