| 1 |
On Wed, Sep 28, 2022 at 06:31:39PM +0200, Ulrich Mueller wrote: |
| 2 |
> >>>>> On Wed, 28 Sep 2022, Florian Schmaus wrote: |
| 3 |
> |
| 4 |
> > I would like to continue discussing whether we should entirely |
| 5 |
> > deprecate EGO_SUM without the desire to offend anyone. |
| 6 |
|
| 7 |
Don't worry, I am not offended. I just haven't found a simple way to do |
| 8 |
this. Sure, I will continue the discussion. |
| 9 |
|
| 10 |
> > We now have a pending GitHub PR that bumps restic to 0.14 [1]. Restic |
| 11 |
> > is a very popular backup software written in Go. The PR drops EGO_SUM |
| 12 |
> > in favor of a vendor tarball created by the proxied maintainer. |
| 13 |
> > However, I am unaware of any tool that lets you practically audit the |
| 14 |
> > 35 MiB source contained in the tarball. And even if such a tool |
| 15 |
> > exists, this would mean another manual step is required, which is, |
| 16 |
> > potentially, skipped most of the time, weakening our user's security. |
| 17 |
> > This is because I believe neither our tooling, e.g., go-mod.eclass, |
| 18 |
> > nor any Golang tooling, does authenticate the contents of the vendor |
| 19 |
> > tarball against upstream's go.sum. But please correct me if I am |
| 20 |
> > wrong. |
| 21 |
|
| 22 |
I don't know for certain about a vendor tarball, but I do know there are |
| 23 |
instances where a vendor tarball wouldn't work. |
| 24 |
app-containers/containerd is a good example of this, That is why the |
| 25 |
vendor tarball idea was dropped. |
| 26 |
|
| 27 |
Go modules are verified by go tooling. That is why I went with a |
| 28 |
dependency tarball. |
| 29 |
|
| 30 |
> > I wonder if we can reach consensus around un-depreacting EGO_SUM, but |
| 31 |
> > discouraging its usage in certain situations. That is, provide EGO_SUM |
| 32 |
> > as option but disallow its use if |
| 33 |
> > 1.) *upstream* provides a vendor tarball |
| 34 |
|
| 35 |
Upstream doesn't need to provide a tarball, just an up-to-date "vendor" |
| 36 |
directory at the top level of the project. Two examples that do this are |
| 37 |
docker and kubernetes. |
| 38 |
|
| 39 |
If the "vendor" directory is in the project, EGO_SUM should not be used. |
| 40 |
This is already documented in the eclass. |
| 41 |
|
| 42 |
> > 2.) the number of EGO_SUM entries exceeds 1000 and a Gentoo developer |
| 43 |
> > maintains the package |
| 44 |
> > 3.) the number of EGO_SUM entries exceeds 1500 and a proxied |
| 45 |
> > maintainer maintains the package |
| 46 |
> |
| 47 |
> These numbers seem quite large, compared to the mean number of 3.4 |
| 48 |
> distfiles for packages in the Gentoo repository. (The median and the |
| 49 |
> 99-percentile are 1 and 22, respectively.) |
| 50 |
|
| 51 |
There is no way from within portage to tell whether a proxied maintainer |
| 52 |
or a developer maintains the package, and I don't think we should care. |
| 53 |
We don't want different qa standards for packages in the tree based on |
| 54 |
who maintains them. |
| 55 |
|
| 56 |
I think we should settle on one limit. I could check for that limit inside |
| 57 |
the eclass and make the ebuild process die if the limit is not observed. |
| 58 |
|
| 59 |
The concern, as I understand it, is about the sizes of the ebuilds and |
| 60 |
manifests for go software. Since the number of distfiles was mentioned, |
| 61 |
I will add it here and show it in my example numbers below. |
| 62 |
|
| 63 |
To stay with your example, restic has a 300k manifest, multiple 30k+ |
| 64 |
ebuilds and897 distfiles. |
| 65 |
|
| 66 |
I'm thinking the limit would have to be much lower. Say, around 256 |
| 67 |
entries in EGO_SUM_SRC_URI. |
| 68 |
|
| 69 |
William |
Archives