| 1 |
On Wed, 2022-09-28 at 17:28 +0200, Florian Schmaus wrote: |
| 2 |
> > I would like to continue discussing whether we should entirely > |
| 3 |
> > deprecate |
| 4 |
> > EGO_SUM without the desire to offend anyone. |
| 5 |
> > |
| 6 |
> > We now have a pending GitHub PR that bumps restic to 0.14 [1]. |
| 7 |
> > Restic > is |
| 8 |
> > a very popular backup software written in Go. The PR drops EGO_SUM |
| 9 |
> > in |
| 10 |
> > favor of a vendor tarball created by the proxied maintainer. |
| 11 |
> > However, > I |
| 12 |
> > am unaware of any tool that lets you practically audit the 35 MiB > |
| 13 |
> > source |
| 14 |
> > contained in the tarball. And even if such a tool exists, this |
| 15 |
> > would |
| 16 |
> > mean another manual step is required, which is, potentially, |
| 17 |
> > skipped |
| 18 |
> > most of the time, weakening our user's security. This is because I |
| 19 |
> > believe neither our tooling, e.g., go-mod.eclass, nor any Golang |
| 20 |
> > tooling, does authenticate the contents of the vendor tarball |
| 21 |
> > against |
| 22 |
> > upstream's go.sum. But please correct me if I am wrong. |
| 23 |
> > |
| 24 |
> > I wonder if we can reach consensus around un-depreacting EGO_SUM, |
| 25 |
> > but |
| 26 |
> > discouraging its usage in certain situations. That is, provide > |
| 27 |
> > EGO_SUM |
| 28 |
> > as option but disallow its use if |
| 29 |
> > 1.) *upstream* provides a vendor tarball |
| 30 |
> > 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo |
| 31 |
> > developer |
| 32 |
> > maintains the package |
| 33 |
> > 3.) the number of EGO_SUM entries exceeds 1500 and a proxied > |
| 34 |
> > maintainer |
| 35 |
> > maintains the package |
| 36 |
> > |
| 37 |
> > In case of 3, I would encourage proxy maintainers to create and > |
| 38 |
> > provide |
| 39 |
> > the vendor tarball. |
| 40 |
> > |
| 41 |
> > The suggested EGO_SUM limits result from a histogram that I created |
| 42 |
> > analyzing ::gentoo at 2022-01-01, i.e., a few months before EGO_SUM |
| 43 |
> > > was |
| 44 |
> > deprecated. |
| 45 |
|
| 46 |
I think those numbers are too large but overall I think bringing back |
| 47 |
EGO_SUM in limited form is a good move, because it allows packaging go |
| 48 |
ebuilds in an easy and audit-able way. |
| 49 |
If you have vendor tarball - it's completely opaque before you unpack. |
| 50 |
With EGO_SUM you could parse ebuilds using that and scan for vulnerable |
| 51 |
go modules. and ofc vendored source hosting is a problem |
| 52 |
|
| 53 |
From rust's team perspective ( we use CRATES, which is EGO_SUM |
| 54 |
inspiration, but _much_ more compact one) - I'd say take largest rust |
| 55 |
ebuild and allow as much as that or slightly more. |
| 56 |
x11-terms/alacritty is one of largest and CRATES number of lines is |
| 57 |
about 210 per 1 ebuild. |
| 58 |
|
| 59 |
So I'd say set maximum EGO_SUM size to 256 for ::gentoo, or maybe 512, |
| 60 |
remove limit for overlays completely. and introduce a hard die() in |
| 61 |
eclass if EGO_SUM is larger than that. |
| 62 |
not sure if you can detect repo name in eclass. |
| 63 |
In that case pkgcheck and CI could enforce that as fat warnings or |
| 64 |
errors. |
| 65 |
|
| 66 |
256/512 limitation will not impose limit on manifest directly, but if |
| 67 |
you have |
| 68 |
5 versions of max 256/512 EGO_SUM loc - it'll be more reasonable than |
| 69 |
5 versions of max 1500 EGO_SUM loc. |
| 70 |
|
| 71 |
rust/cargo ebuild will still produce more compact Manifest given same |
| 72 |
amount of lines though, so it's still not directly comparable. |
| 73 |
|
| 74 |
currently we have 3 versions of alacritty which uses 407 unique crates |
| 75 |
across 3 versions. Manifest size is about 120K, which is 20th largest |
| 76 |
in ::gentoo |
| 77 |
It's nothing compared to 2.5MB manifests we used to have in some of the |
| 78 |
largest go packages. |
| 79 |
|
| 80 |
> > |
| 81 |
> > - Flow |
| 82 |
> > |
| 83 |
> > 1: https://github.com/gentoo/gentoo/pull/27050 |
| 84 |
> > |
Archives