[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: goproxy notes
Re: goproxy notes
Fri, 27 Aug 2021 09:56:30 -0500
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
raingloom <firstname.lastname@example.org> writes:
> do we depend on this? if yes, it might be a good idea to disable the
> proxy in the importer.
> sorry, i don't have time to look into it myself right now, so i'm
> dumping it here.
Thanks a lot for bringing this up.
The Go importer has a flag for specifying the proxy server to check
(Google's is used by default), but this is only used to fetch
preliminary information about a module, i.e. =go.mod=, the repo's URL,
and what the proxy thinks is the latest version. The VCS type, VCS URL,
and actual source code are fetched from the module's defined source
(i.e. github, etc.).
It would have been much easier on everyone involved with writing the Go
importer to just fetch the package from the proxy, but we had the
foresight to realize it would cause this exact issue: centralization on
a single service owned by a single company. Since we did not do that, a
brief scan of our Go packages suggests that all of them are fetching
source from their respective repositories, and not a proxy server.
As I understand it, Guix builds cannot reach out to the network, so
there is no risk of leaking metadata to Google via invocation of Go
commands. Further, our current Go build system does not even use modules
(this needs to change).
I think this addresses all the points in this blog post. Overall, I
think Guix is very well positioned because of how we generate Go
packages, how our build system works, and how Guix emphasises
- goproxy notes, raingloom, 2021/08/24
- Re: goproxy notes,
Katherine Cox-Buday <=