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