search

jfrog / gocenter

The Github README for JFrog Go-center. Use this for reporting issues
https://gocenter.io
Apache License 2.0
164 stars 23 forks source link

How can a single commit have more than one pseudo-versions? #53

Closed RainbowMango closed 4 years ago

RainbowMango commented 4 years ago

From the following output, I have some questions:

[root@ecs-d8b6 ~]# curl https://gocenter.io/github.com/golang/glog/@v/list
v0.0.0-20140115174030-d1c4472bf2ef 2019-01-23T07:27:26Z
v0.0.0-20141105023935-44145f04b68c 2019-01-23T07:04:39Z
v0.0.0-20150731225221-fca8c8854093 2019-01-23T07:24:50Z
v0.0.0-20160126235308-23def4e6c14b 2019-01-23T06:59:53Z
v0.0.0-20170312005925-23def4e6c14b 2019-12-13T11:50:06Z
v0.0.0-20170312005925-543a34c32e4d 2019-01-24T03:30:18Z
v0.0.0-20180824191149-f5055e6f21ce 2020-06-04T04:29:58Z
v1.0.0-20160126235308-23def4e6c14b 2019-12-10T01:55:28Z

The latest commit happened on 27 Jan 2016, the short commit id is 23def4e6c, why gocenter.io keeps two pseudo versions with different times?

v0.0.0-20160126235308-23def4e6c14b 2019-01-23T06:59:53Z
v0.0.0-20170312005925-23def4e6c14b 2019-12-13T11:50:06Z
elioengcomp commented 4 years ago

Hi @RainbowMango ,

Thank you for reaching out to us.

Before Go 1.13 there was no validation on the pseudo-version components, being possible for a single commit hash to be present on multiple pseudo-versions. This would usually happen when users created or changed pseudo-versions manually instead of relying on the Go client to do it for them.

Since GoCenter is Go version agnostic, it will cache and serve those pseudo versions when users request them from the center to promote the reproducibility of builds and interoperability between module proxies. The logic we try to follow here is that if it worked when users where resolving dependencies from source, it should work as well if they resolve from GoCenter.

Let us know if you have additional question.

RainbowMango commented 4 years ago

Thanks for your quick response. I'm familiar with the proxy.golang.org, but not with GoCenter, so I still confused.

This would usually happen when users created or changed pseudo-versions manually instead of relying on the Go client to do it for them.

Do you mean the pseudo-versions are created by users? If yes, could you please show an example? I also wonder how GoCenter cache the packages.

Another question: Take github.com/golang/glog@v0.0.0-20170312005925-23def4e6c14b for example, seems GoCenter already cached it, but can not pass the GOSUMDB verify. I guess that because the GOSUMDB(sum.golang.org) doesn't record this version. Am I right? Will you remove this kind of package?

[root@ecs-d8b6 temp]# go get -v github.com/golang/glog@v0.0.0-20170312005925-23def4e6c14b 
go: downloading github.com/golang/glog v0.0.0-20170312005925-23def4e6c14b
go get github.com/golang/glog@v0.0.0-20170312005925-23def4e6c14b: github.com/golang/glog@v0.0.0-20170312005925-23def4e6c14b: verifying module: github.com/golang/glog@v0.0.0-20170312005925-23def4e6c14b: reading https://gocenter.io/sumdb/sum.golang.org/lookup/github.com/golang/glog@v0.0.0-20170312005925-23def4e6c14b: 404 Not Found
elioengcomp commented 4 years ago

Do you mean the pseudo-versions are created by users? If yes, could you please show an example?

Users should not create pseudo-versions by themselves and should aways rely on the Go client to translate a commit hash or a branch name to the actual pseudo-version. However, before Go 1.13, there was no logic built in the Go client to validate the pseudo-version components, making it possible for users to simply change the commit hash part of a pseudo-version while leaving the other components untouched and still get a working pseudo-version. That is why it was possible to get multiple working pseudo-versions for the same commit hash. This changed on Go 1.13 when a validation logic was introduced to make sure the version and date components of a pseudo-version are compatible with the commit hash part.

I also wonder how GoCenter cache the packages.

Can you provide more details about what specifically you would like to know about how GoCenter cache the packages.

Take github.com/golang/glog@v0.0.0-20170312005925-23def4e6c14b for example, seems GoCenter already cached it, but can not pass the GOSUMDB verify. I guess that because the GOSUMDB(sum.golang.org) doesn't record this version. Am I right? Will you remove this kind of package?

Yes, you are right. The checksum server was introduced after Go 1.13 and is not backwards compatible. If users want to rely on the checksum server, they will need to either move to the actual correct pseudo-version or disable the checksum server check step for that specific module.

We will not remove those packages. Remember that there is nothing wrong with them as long as you are using Go 1.12. GoCenter is version agnostic and is meant to promote reproducible builds. In order to achieve that all versions need to be immutable and always available. Also, users should not be force to update their dependencies or move to a newer Go version because the server did a non backwards compatible change. They should have the control over when it is safe for them to make this type of changes.

RainbowMango commented 4 years ago

Thank you for your patience, I think I've got my answer now.

Remember that there is nothing wrong with them as long as you are using Go 1.12. They should have the control over when it is safe for them to make this type of changes.

After we started use Go1.12+ we should change the dependencies to a version that can be verified by GOSUMDB.

Thanks again, and I'm going to close the issue now.

elioengcomp commented 4 years ago

You are more than welcome. Feel free to reach out again if you have additional questions.