From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B40F2158094 for ; Fri, 30 Sep 2022 00:36:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C76F6E0E00; Fri, 30 Sep 2022 00:36:08 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7D015E07D8 for ; Fri, 30 Sep 2022 00:36:08 +0000 (UTC) Received: (nullmailer pid 24974 invoked by uid 1000); Fri, 30 Sep 2022 00:36:05 -0000 Date: Thu, 29 Sep 2022 19:36:05 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Proposal to undeprecate EGO_SUM Message-ID: Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <20220613074411.341909-1-flow@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Ysfz2b+I4Qzd2SSk" Content-Disposition: inline In-Reply-To: X-Archives-Salt: 2095501a-8075-4025-892f-695d7df3a36c X-Archives-Hash: 00260da562efe67fda3a0a98e67d6d24 --Ysfz2b+I4Qzd2SSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote: > >>>>> On Wed, 28 Sep 2022, Florian Schmaus wrote: >=20 > > I would like to continue discussing whether we should entirely > > deprecate EGO_SUM without the desire to offend anyone. Don't worry, I am not offended. I just haven't found a simple way to do this. Sure, I will continue the discussion. > > We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic > > is a very popular backup software written in Go. The PR drops EGO_SUM > > in favor of a vendor tarball created by the proxied maintainer. > > However, I am unaware of any tool that lets you practically audit the > > 35 MiB source contained in the tarball. And even if such a tool > > exists, this would mean another manual step is required, which is, > > potentially, skipped most of the time, weakening our user's security. > > This is because I believe neither our tooling, e.g., go-mod.eclass, > > nor any Golang tooling, does authenticate the contents of the vendor > > tarball against upstream's go.sum. But please correct me if I am > > wrong. I don't know for certain about a vendor tarball, but I do know there are instances where a vendor tarball wouldn't work. app-containers/containerd is a good example of this, That is why the vendor tarball idea was dropped. Go modules are verified by go tooling. That is why I went with a dependency tarball. > > I wonder if we can reach consensus around un-depreacting EGO_SUM, but > > discouraging its usage in certain situations. That is, provide EGO_SUM > > as option but disallow its use if > > 1.) *upstream* provides a vendor tarball Upstream doesn't need to provide a tarball, just an up-to-date "vendor" directory at the top level of the project. Two examples that do this are docker and kubernetes. If the "vendor" directory is in the project, EGO_SUM should not be used. This is already documented in the eclass. > > 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer > > maintains the package > > 3.) the number of EGO_SUM entries exceeds 1500 and a proxied > > maintainer maintains the package >=20 > These numbers seem quite large, compared to the mean number of 3.4 > distfiles for packages in the Gentoo repository. (The median and the > 99-percentile are 1 and 22, respectively.) There is no way from within portage to tell whether a proxied maintainer or a developer maintains the package, and I don't think we should care. We don't want different qa standards for packages in the tree based on who maintains them. I think we should settle on one limit. I could check for that limit inside the eclass and make the ebuild process die if the limit is not observed. The concern, as I understand it, is about the sizes of the ebuilds and manifests for go software. Since the number of distfiles was mentioned, I will add it here and show it in my example numbers below. To stay with your example, restic has a 300k manifest, multiple 30k+ ebuilds and897 distfiles. I'm thinking the limit would have to be much lower. Say, around 256 entries in EGO_SUM_SRC_URI. William --Ysfz2b+I4Qzd2SSk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iFwEABECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCYzY58AAKCRBuVBb0MMRl OFB5AKCPeQcwSHGWA5+Lgsux5yKAJpYhugCYr++bjIh4BFr3QHg87KYEMhvSRQ== =6xeX -----END PGP SIGNATURE----- --Ysfz2b+I4Qzd2SSk--