On 19-02-23 08:17:18, Michał Górny wrote: > On Fri, 2019-02-22 at 20:58 -0600, Matthew Thode wrote: > > On 19-02-19 22:05:02, Brian Dolbec wrote: > > > On Tue, 19 Feb 2019 23:03:51 -0600 > > > Matthew Thode <prometheanf...@gentoo.org> wrote: > > > > > > > On 19-02-20 00:00:04, Michael Orlitzky wrote: > > > > > On 2/19/19 11:21 PM, Matthew Thode wrote: > > > > > > > > > > > > > > What problem would this solve? (Is adding gentoo-keys to @system > > > > > > > the least bad way to solve it?) > > > > > > > > > > > > > > > > > > > It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify > > > > > > portage tarballs. This is useful for the initial sync (as called > > > > > > out in our manual). Otherwise using emerge-webrsync could be > > > > > > mitm'd or otherwise messed with. > > > > > > > > > > Ok, then I agree with the goal if not the solution. This is a > > > > > portage-specific thing, namely > > > > > > > > > > FEATURES=webrsync-gpg > > > > > > > > > > that should be enabled by default on a stage3. (Making new users go > > > > > out of their way to add basic security is daft.) Portage already has > > > > > USE=rsync-verify, and I think we could either > > > > > > > > > > a) expand the meaning of that flag to include enabling > > > > > webrsync-gpg by default, and to pull in gentoo-keys; or > > > > > > > > > > b) add another (default-on) flag like USE=webrsync-verify to do it > > > > > > > > > > That flag would be enabled by default, so gentoo-keys would be > > > > > pulled in as part of @system without actually being *in* the > > > > > @system. Something along those lines would achieve the same goal in > > > > > a cleaner way. > > > > > > > > > > > > > > > > > > This worksforme (optional, default enabled dep of portage with a > > > > default feature flag change). > > > > > > > > > > As far how we treat deps of @system packages, since this does not > > > > > > have any deps that should help check that box for anyone > > > > > > worried. > > > > > > > > > > I meant the other way around. Once gentoo-keys is in @system, > > > > > packages will (inconsistently) omit gentoo-keys from (R)DEPEND. > > > > > There's no real policy or consensus on the matter, and it makes it > > > > > a real PITA if we ever want to remove things from @system, because > > > > > lots of packages will break in unpredictable ways. > > > > > > > > > > > > > Ah, ya, that makes sense. > > > > > > > > > > One of the things that releng has bantered about the last few years is > > > making a stage4 with these extra non @system pkgs. The stage4 would > > > allow all the extra pkgs needed for new installs without adding to > > > @system. The system set could possibly be trimmed a little more then > > > too. Then knowledgeable users could work with minimal stage3's when it > > > suits their purpose while new users doing installs get the advantage of > > > the additional pre-installed pkgs. > > > > > > > Ok, after setting that up portage wants to update pgp keys, which fail > > because keyservers suck. It doesn't look like we can change the > > keyservers or disable the update entirely but we can set the retries to > > 0 (which better disable it...). Robbat2 had a patch to allow disabling > > the update but it doesn't look like it was applied. > > > > Disabling that means entirely killing the verification as it'd happily > use a revoked key. > > Keyservers were supposed not to suck anymore. Are you sure it's not > misconfigured network? Maybe it's got broken-but-pretended IPv6? >
How about we allow a setting for controling which keyserver to refresh from. SKS has had problems, fedora has been better (and a coworker says MIT is ok too). Aparently they have a max key size set or something to work around keyserver 'brokenness'. Something similiar to this would be nice, but for keyservers. https://gist.github.com/robbat2/551fc8ea56408ee48e99909f9c26c13e -- Matthew Thode (prometheanfire)
signature.asc
Description: PGP signature
