From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-86666-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0F315138334 for <garchives@archives.gentoo.org>; Sat, 23 Feb 2019 20:39:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BE56BE0997; Sat, 23 Feb 2019 20:39:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 53394E0992 for <gentoo-dev@lists.gentoo.org>; Sat, 23 Feb 2019 20:39:49 +0000 (UTC) Received: from [172.16.0.17] (cpe-72-227-68-175.maine.res.rr.com [72.227.68.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: desultory) by smtp.gentoo.org (Postfix) with ESMTPSA id 13995335DC3; Sat, 23 Feb 2019 20:39:47 +0000 (UTC) Subject: Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system To: gentoo-dev@lists.gentoo.org, =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= <mgorny@gentoo.org> References: <20190220032333.gxgcq2iqtd3zcgt2@gentoo.org> <3ba59280-4d42-bf10-6127-6269308fc902@gentoo.org> <20190220042115.tuj6arxd747ggzv3@gentoo.org> <3529cec0-9c22-cb17-5411-04a006279b98@gentoo.org> <20190220050350.tzggbrxg5wuowlzv@gentoo.org> <20190219220502.79bb3061@professor-x> <20190223025810.rvqq5hb4j44wj75p@gentoo.org> <1550906238.752.0.camel@gentoo.org> From: desultory <desultory@gentoo.org> Message-ID: <0ca0e73d-3d3c-669c-70e4-8b51a76f08d2@gentoo.org> Date: Sat, 23 Feb 2019 15:39:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: <1550906238.752.0.camel@gentoo.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Archives-Salt: 867ce394-1284-467d-8081-a412138386e7 X-Archives-Hash: 6f064ed8b4c5029ff92f3c38236fafa0 On 02/23/19 02:17, 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 <prometheanfire@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? > Given the ongoing volume of issues with this same area that have been reported on the forums (and elsewhere), including by people whom I know to be competent network administrators, it seems distinctly unlikely that all of the issues come down to networking configuration errors. Especially as the posited networking issues appear to affect nothing else.