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 76E3B15806E for ; Fri, 2 Jun 2023 18:07:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0306DE08DB; Fri, 2 Jun 2023 18:06:57 +0000 (UTC) Received: from smtp.gentoo.org (dev.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 B2902E088F for ; Fri, 2 Jun 2023 18:06:56 +0000 (UTC) Received: (nullmailer pid 13189 invoked by uid 1000); Fri, 02 Jun 2023 18:06:53 -0000 Date: Fri, 2 Jun 2023 13:06:53 -0500 From: William Hubbs To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] EGO_SUM Message-ID: Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <49ce8700-6c96-9360-51cf-2a989f666752@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="bhBGxIaYM1Q0WzHR" Content-Disposition: inline In-Reply-To: X-Archives-Salt: 2814c704-0e5b-4be8-9658-f05f71cd5177 X-Archives-Hash: 6d733b945d81688ec04ba3cac3b72681 --bhBGxIaYM1Q0WzHR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 02, 2023 at 10:13:55AM +0300, Joonas Niilola wrote: > On 1.6.2023 22.55, William Hubbs wrote: > >> > >> The EGO_SUM alternatives > >> - do not have the same level of trust and therefore have a negative=20 > >> impact on security (a dubious tarball someone put somewhere, especiall= y=20 > >> when proxy-maint) > >=20 > > For this, I would argue that vetting the tarball falls to the developer > > who is proxying. If you don't trust the proxy maintainer you > > are pushing for, it is easy to make a dependency tarball yourself and > > add it to your dev space. > >=20 > >=20 > >> - require additional effort when developing ebuilds > >=20 > > This "additional effort" is pretty subjective. Making a dependency tarb= all > > isn't a lot of work, especially with the script that I posted in this t= hread. > >=20 >=20 > In theory it's "easy", but in practice how'd you work? This would be > fine when a single developer is proxying a single maintainer, but when a > a stack of devs (project) are proxying hundreds of different people, it > becomes messy and unsustainable rather fast. =20 This comment is completely off topic for this thread, so start another thread for it if you want, but if hundreds of people are being proxied by proxy-maint, that seems to be a concern unrelated to this. It seems the fix for that is to advocate for some of these hundreds of people to become developers so they don't have to be proxied any more. > I do want to point out that any proxied maintainer can and should upload > the vendor tarballs to their own Github / Gitlab distfile-repos for the > time being, but allowing EGO_SUM to be used again would be the easiest > solution here in my opinion for everyone involved. I'm aware it's pushed > back due to technicalities. Like I said at another point in the thread, I want to get rid of EGO_SUM by moving most of the processing for it out of the eclass. I'm looking into that now. This will still run into the same problem as EGO_SUM if $A is still exported, but it should speed up ebuild processing. William --bhBGxIaYM1Q0WzHR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTVeuxEZo4uUHOkQAluVBb0MMRlOAUCZHovuAAKCRBuVBb0MMRl OHEOAKC6X47uPmFD5bpT7xDsBHTeqfhheACcDR2RrnTB4EyrDR3yhahTIxHRFC4= =JKcd -----END PGP SIGNATURE----- --bhBGxIaYM1Q0WzHR--