| 1 |
I would like to continue discussing whether we should entirely deprecate |
| 2 |
EGO_SUM without the desire to offend anyone. |
| 3 |
|
| 4 |
We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic is |
| 5 |
a very popular backup software written in Go. The PR drops EGO_SUM in |
| 6 |
favor of a vendor tarball created by the proxied maintainer. However, I |
| 7 |
am unaware of any tool that lets you practically audit the 35 MiB source |
| 8 |
contained in the tarball. And even if such a tool exists, this would |
| 9 |
mean another manual step is required, which is, potentially, skipped |
| 10 |
most of the time, weakening our user's security. This is because I |
| 11 |
believe neither our tooling, e.g., go-mod.eclass, nor any Golang |
| 12 |
tooling, does authenticate the contents of the vendor tarball against |
| 13 |
upstream's go.sum. But please correct me if I am wrong. |
| 14 |
|
| 15 |
I wonder if we can reach consensus around un-depreacting EGO_SUM, but |
| 16 |
discouraging its usage in certain situations. That is, provide EGO_SUM |
| 17 |
as option but disallow its use if |
| 18 |
1.) *upstream* provides a vendor tarball |
| 19 |
2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer |
| 20 |
maintains the package |
| 21 |
3.) the number of EGO_SUM entries exceeds 1500 and a proxied maintainer |
| 22 |
maintains the package |
| 23 |
|
| 24 |
In case of 3, I would encourage proxy maintainers to create and provide |
| 25 |
the vendor tarball. |
| 26 |
|
| 27 |
The suggested EGO_SUM limits result from a histogram that I created |
| 28 |
analyzing ::gentoo at 2022-01-01, i.e., a few months before EGO_SUM was |
| 29 |
deprecated. |
| 30 |
|
| 31 |
- Flow |
| 32 |
|
| 33 |
1: https://github.com/gentoo/gentoo/pull/27050 |
Archives