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. |