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 
> >> impact on security (a dubious tarball someone put somewhere, especially 
> >> when proxy-maint)
> > 
> > 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.
> > 
> > 
> >> - require additional effort when developing ebuilds
> > 
> > This "additional effort" is pretty subjective. Making a dependency tarball
> > isn't a lot of work, especially with the script that I posted in this 
> > thread.
> > 
> 
> 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.
 
 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

Attachment: signature.asc
Description: PGP signature

Reply via email to