1 |
(replying to the first post here as I believe this post is relevant to |
2 |
most, if not all, subthreads) |
3 |
|
4 |
I've prepared a PoC of an automated solution for vendoring[1] a while |
5 |
back (around the start of this whole discussion) that would place trust |
6 |
on the infrastructure (though potentially verifiable). |
7 |
|
8 |
My concept provides two solutions: |
9 |
1) go mod vendor - not verifiable by users (as vendor tars don't include |
10 |
enough information for checksumming - see also [2]) |
11 |
2) modcache - significantly larger but verifiable on the client (against |
12 |
existing go.sum). These archives really go up to gigabytes in size as |
13 |
opposed to a few megs of vendored tarballs. |
14 |
|
15 |
Please note that [1] is on a small server, possibly broken, pretty slow, |
16 |
and not fit for production yet. Ping me on IRC if you encounter issues |
17 |
so that I can "unjam" it. |
18 |
|
19 |
Also note that this thing doesn't attempt much to figure out how to |
20 |
convert a ${PV} or any other format versions, and essentially leaves |
21 |
that up to the GOPROXY (with very little extra work, see: [3]). |
22 |
|
23 |
The proposed solution here is that the developer passes something like |
24 |
https://go.gentoo.org/vendor/...@${PV} -> vendor.tar into $SRC_URI, |
25 |
which would get initiated with a call to ``pkgdev manifest'' or such |
26 |
(possibly authenticated via IP or keys or something, to prevent abuse), |
27 |
and be done with it. |
28 |
|
29 |
The biggest downside I've seen so far (excluding further developing the |
30 |
solution) is that some Go programs don't respect the restrictions of the |
31 |
Go module system, and thus fail to fetch. |
32 |
|
33 |
[1]: https://vengor.aarsen.me/ |
34 |
[2]: https://github.com/golang/go/issues/27348 |
35 |
[3]: https://git.sr.ht/~arsen/vengor/tree/ab1ae7b275ab492d4806de88cfbf67e7b97c1ade/item/vengor/__init__.py#L101-127 |
36 |
|
37 |
-- |
38 |
Arsen Arsenović |