Gentoo Archives: gentoo-dev

From: desultory <desultory@g.o>
To: gentoo-dev@l.g.o, "Michał Górny" <mgorny@g.o>
Subject: Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system
Date: Sat, 23 Feb 2019 23:22:54
Message-Id: c37c169a-c0ac-bceb-b54c-ba4a50361afa@gentoo.org
In Reply to: Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system by "Michał Górny"
1 On 02/23/19 16:16, Michał Górny wrote:
2 > On Sat, 2019-02-23 at 15:39 -0500, desultory wrote:
3 >> On 02/23/19 02:17, Michał Górny wrote:
4 >>> On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote:
5 >>>> On 19-02-19 22:05:02, Brian Dolbec wrote:
6 >>>>> On Tue, 19 Feb 2019 23:03:51 -0600
7 >>>>> Matthew Thode <prometheanfire@g.o> wrote:
8 >>>>>
9 >>>>>> On 19-02-20 00:00:04, Michael Orlitzky wrote:
10 >>>>>>> On 2/19/19 11:21 PM, Matthew Thode wrote:
11 >>>>>>>>>
12 >>>>>>>>> What problem would this solve? (Is adding gentoo-keys to @system
13 >>>>>>>>> the least bad way to solve it?)
14 >>>>>>>>>
15 >>>>>>>>
16 >>>>>>>> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
17 >>>>>>>> portage tarballs. This is useful for the initial sync (as called
18 >>>>>>>> out in our manual). Otherwise using emerge-webrsync could be
19 >>>>>>>> mitm'd or otherwise messed with.
20 >>>>>>>
21 >>>>>>> Ok, then I agree with the goal if not the solution. This is a
22 >>>>>>> portage-specific thing, namely
23 >>>>>>>
24 >>>>>>> FEATURES=webrsync-gpg
25 >>>>>>>
26 >>>>>>> that should be enabled by default on a stage3. (Making new users go
27 >>>>>>> out of their way to add basic security is daft.) Portage already has
28 >>>>>>> USE=rsync-verify, and I think we could either
29 >>>>>>>
30 >>>>>>> a) expand the meaning of that flag to include enabling
31 >>>>>>> webrsync-gpg by default, and to pull in gentoo-keys; or
32 >>>>>>>
33 >>>>>>> b) add another (default-on) flag like USE=webrsync-verify to do it
34 >>>>>>>
35 >>>>>>> That flag would be enabled by default, so gentoo-keys would be
36 >>>>>>> pulled in as part of @system without actually being *in* the
37 >>>>>>> @system. Something along those lines would achieve the same goal in
38 >>>>>>> a cleaner way.
39 >>>>>>>
40 >>>>>>>
41 >>>>>>
42 >>>>>> This worksforme (optional, default enabled dep of portage with a
43 >>>>>> default feature flag change).
44 >>>>>>
45 >>>>>>>> As far how we treat deps of @system packages, since this does not
46 >>>>>>>> have any deps that should help check that box for anyone
47 >>>>>>>> worried.
48 >>>>>>>
49 >>>>>>> I meant the other way around. Once gentoo-keys is in @system,
50 >>>>>>> packages will (inconsistently) omit gentoo-keys from (R)DEPEND.
51 >>>>>>> There's no real policy or consensus on the matter, and it makes it
52 >>>>>>> a real PITA if we ever want to remove things from @system, because
53 >>>>>>> lots of packages will break in unpredictable ways.
54 >>>>>>>
55 >>>>>>
56 >>>>>> Ah, ya, that makes sense.
57 >>>>>>
58 >>>>>
59 >>>>> One of the things that releng has bantered about the last few years is
60 >>>>> making a stage4 with these extra non @system pkgs. The stage4 would
61 >>>>> allow all the extra pkgs needed for new installs without adding to
62 >>>>> @system. The system set could possibly be trimmed a little more then
63 >>>>> too. Then knowledgeable users could work with minimal stage3's when it
64 >>>>> suits their purpose while new users doing installs get the advantage of
65 >>>>> the additional pre-installed pkgs.
66 >>>>>
67 >>>>
68 >>>> Ok, after setting that up portage wants to update pgp keys, which fail
69 >>>> because keyservers suck. It doesn't look like we can change the
70 >>>> keyservers or disable the update entirely but we can set the retries to
71 >>>> 0 (which better disable it...). Robbat2 had a patch to allow disabling
72 >>>> the update but it doesn't look like it was applied.
73 >>>>
74 >>>
75 >>> Disabling that means entirely killing the verification as it'd happily
76 >>> use a revoked key.
77 >>>
78 >>> Keyservers were supposed not to suck anymore. Are you sure it's not
79 >>> misconfigured network? Maybe it's got broken-but-pretended IPv6?
80 >>>
81 >>
82 >> Given the ongoing volume of issues with this same area that have been
83 >> reported on the forums (and elsewhere), including by people whom I know
84 >> to be competent network administrators, it seems distinctly unlikely
85 >> that all of the issues come down to networking configuration errors.
86 >> Especially as the posited networking issues appear to affect nothing else.
87 >>
88 >
89 > Yet instead of actually reporting bugs, talking to keyserver people
90 > and providing information that could help resolve the issue... let me
91 > guess, forum people instead share workarounds on how to kill security
92 > in their Gentoo and complain between themselves. Months later, someone
93 > passes the complaints over to the ml as a side remark in some semi-
94 > related thread, of course without caring to actually provide any helpful
95 > data.
96 >
97 Last I checked, forcing users to file bug reports was, at best,
98 impractical; encouraging them to has been as much as we can
99 realistically do. Not that such bugs have not been filed, as you well know.
100
101 As for "talking to keyserver people", for one thing most users do not
102 even know how to find the right parties to contact, and even when they
103 do or are directed to them reporting "you had downtime, please fix it"
104 seems distinctly pointless if the administrators are paying any
105 attention at all to their services, and rather moreso if they aren't.
106
107 Workarounds are about as much as one can do when they cannot access
108 otherwise required services to perform updates. The best available
109 approach left to users is keeping the workarounds in place for the
110 minimum amount of time to do the work that they need to get done.
111
112 I had thought that directly replying to the maintainer without side
113 commentary did not count as "a side remark in some semi-related thread".
114 As for the timing and context, I have recently been (incorrectly) told
115 that the forums project is "isolationist" and thus have decided to make
116 an effort to dispel such false claims by more actively participating in
117 other media, despite forums being my primary area of responsibility; and
118 did not (and still do not) see a need to compile a list of reports when,
119 presumably, your search engine of choice would suffice to find them by
120 the dozen. Further, you are CC:ed on and have commented on related and
121 as yet unresolved bugs, so this should hardly be new information to you.
122
123 So, please, do kindly leave handwaving, strawmen, and appeals to
124 ridicule out of technical discussion, they serve no useful purpose.