Hey, On Friday, 30 September 2022 02:36:05 CEST William Hubbs wrote: > I don't know for certain about a vendor tarball, but I do know there > are instances where a vendor tarball wouldn't work. > app-containers/containerd is a good example of this, That is why the > vendor tarball idea was dropped. It is indeed not possible to verify vendor tarballs[1]. The proposed solution Go people had would also require network access.
> Upstream doesn't need to provide a tarball, just an up-to-date > "vendor" directory at the top level of the project. Two examples that > do this are docker and kubernetes. Upstreams doing this sounds like a mess, because then they'd have to maintain multiple source trees in their repositories, if I understand what you mean. An alternative to vendor tarballs is modcache tarballs. These are absolutely massive (~20 times larger IIRC), though, they are verifiable. opinion: I see no way around it. Vendor tarballs are the way to go. For trivial cases, this can likely be EGO_SUM, but it scales exceedingly poorly, to the point of the trivial case being a very small percentage of Go packages. I proposed authenticated automation on Gentoo infrastructure as a solution to this, and implemented (a slow and unreliable) proof of concept (posted previously). The obvious question of "how will proxy maintainers deal with this" is also relatively simple: giving them authorization for a subset of packages that they'd need to work on. This is an obvious increase in the barrier of entry for fresh proxy maintainers, but it's still likely less than needing maintainers to rework ebuilds to use vendor tarballs on dev.g.o. [1]: https://github.com/golang/go/issues/27348 -- Arsen Arsenović
signature.asc
Description: This is a digitally signed message part.
