On Wed, Sep 28, 2022 at 05:28:00PM +0200, Florian Schmaus wrote: > I would like to continue discussing whether we should entirely deprecate > EGO_SUM without the desire to offend anyone. > > 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 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 > 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
I'm not sure I agree on these limits, given the authenticity problem exists regardless of how many dependencies there are. > In case of 3, I would encourage proxy maintainers to create and provide > the vendor tarball. > > The suggested EGO_SUM limits result from a histogram that I created > analyzing ::gentoo at 2022-01-01, i.e., a few months before EGO_SUM was > deprecated. > > - Flow > > 1: https://github.com/gentoo/gentoo/pull/27050 >
signature.asc
Description: PGP signature
