On 28/09/2022 23.23, John Helmert III wrote:
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.

It's not really about authentication, you always have to trust upstream to some degree (unless you audit every line of code). But I believe that code distributed via official channels is viewed by more eyes and significantly more secure.

EGO_SUM entries are directly fetched from the official distribution channels of Golang. Hence, there is a higher chance that malicious code in one of those is detected faster, simply because they are consumed by more entities. Compared to the dependency tarball that is just used by Gentoo. In contrast to the official sources, "nobody" is looking at the code inside the tarball.

For proxied packages, where the dependency tarball is published by the proxied maintainer, the tarball also allows another entity to inject code into the final result of the package. And compared to a few small patches in FILESDIR, such a dependency tarball requires more effort to review. This further weakens security in comparison to EGO_SUM.

- Flow

Attachment: OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to