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

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

Reply via email to