Gentoo Archives: gentoo-dev

From: Florian Schmaus <flow@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Proposal to undeprecate EGO_SUM
Date: Wed, 28 Sep 2022 15:28:10
In Reply to: [gentoo-dev] Proposal to undeprecate EGO_SUM by Florian Schmaus
1 I would like to continue discussing whether we should entirely deprecate
2 EGO_SUM without the desire to offend anyone.
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.
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
24 In case of 3, I would encourage proxy maintainers to create and provide
25 the vendor tarball.
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.
31 - Flow
33 1:


Subject Author
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM Ulrich Mueller <ulm@g.o>
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM John Helmert III <ajak@g.o>
Re: [gentoo-dev] Proposal to undeprecate EGO_SUM Georgy Yakovlev <gyakovlev@g.o>