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

Replies

Subject Author
Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system "Michał Górny" <mgorny@g.o>