0

Say you are using Go 1.13 and set up a project initialized for Go Modules.

$ mkdir my-project
$ cd my-project
$ git mod init github.com/bmuschko/my-project

Instead of using the default Google proxy to download dependencies, you set GoCenter or a different proxy.

$ export GOPROXY=https://gocenter.io

Once you download dependencies, it doesn't seem that Go keeps track of the originating proxy. In the end, there's no way to know or verify that a dependency came from the Google proxy, a custom proxy or directly from the source code repository. In theory, the checksums could be different depending on the originating proxy if you switch between them even if you pull the same version.

$ go get github.com/spf13/cobra

Does Go store this information somewhere in the cache? I couldn't find this information. Any advice would be appreciated.

Benjamin Muschko
  • 32,442
  • 9
  • 61
  • 82
  • "In theory, the checksums could be different depending on the originating proxy if you switch between them even if you pull the same version." Why and how? – Volker Jan 21 '20 at 04:51
  • "Once you download dependencies, it doesn't seem that Go keeps track of the originating proxy." That is true but it does record the checksum in go.sum. Does it really matter if the proxy changes as long as the checksum doesn't? – Peter Jan 21 '20 at 09:31
  • @Volker The checksum could be different simply by changing the source code very slightly and uploading it to a different or even the same repository with the same semantic version. Easy to reproduce...create a tag e.g. v1.2.3 for a module on GitHub, change the code and overwrite the existing tag. – Benjamin Muschko Jan 22 '20 at 15:07
  • @Peter My assumption is that a proxy stores the source code for a remote repository upon its first resolution. Once it has been resolved, the proxy doesn't have to reach out anymore and simply uses the "copy". Say you'd be able to modify the source code stored in the proxy then I think you could theoretically introduce malicious changes. Maybe that's a non-issue because the checksum is compared via the central checksum database? – Benjamin Muschko Jan 22 '20 at 15:11
  • 1
    [Yes, there is a database](https://sum.golang.org/) and that is independent of the module proxy. But more importantly, the checksum is written to go.sum (which should be checked in), so if a proxy suddenly serves different code Go will notice and tell you. You have to rely on the database only when installing a module for the first time. – Peter Jan 22 '20 at 16:01
  • I admit I have no idea what type of problem you are trying to solve. The whole reason of the checksum is to change if the code changes underhand and remembering which proxy served the code does not help here. – Volker Jan 22 '20 at 16:06
  • 1
    I think for enterprises, the origination does matter even if the checksum remains constant. If a pipeline is pulling directly against github or a goproxy (that has clean up policies), then the repeatability is questionable. Users can remove tags from GitHub. – Ankush Chadha Jan 22 '20 at 21:00

1 Answers1

0

The originating proxy should not matter and is not recorded: if you have downloaded the module from anywhere, then the bytes in your module cache should match the checksum found in either your go.sum file or the global checksum database.

(The go command fetches checksums for any new module dependencies from the database before downloading the module or adding the checksum to your go.sum file.)

bcmills
  • 4,391
  • 24
  • 34