Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/pkgsite: Old tag appearing as latest #46390

Closed
craicoverflow opened this issue May 26, 2021 · 5 comments
Closed

x/pkgsite: Old tag appearing as latest #46390

craicoverflow opened this issue May 26, 2021 · 5 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. pkgsite

Comments

@craicoverflow
Copy link

What is the URL of the page with the issue?

https://pkg.go.dev/github.com/redhat-developer/app-services-sdk-go

What is your user agent?

Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

Screenshot

image

What did you do?

What did you expect to see?

  • v0.1.2 should be the latest version.
  • apis and kafka packages should not be there

What did you see instead?

  • v0.1.1 is the latest version
  • apis and kafka packages listed as directories.

This likely happened because of these packages being deleted. This project is still in early development and thus we had to change the folder structure and delete somethings. Is there something that can be done to remove these?

@gopherbot gopherbot added this to the Unreleased milestone May 26, 2021
@craicoverflow craicoverflow changed the title x/pkgsite: x/pkgsite: Old tag appearing as latest May 26, 2021
@bcmills
Copy link
Contributor

bcmills commented May 27, 2021

It appears that someone moved or otherwise changed the tags in that repository.
Using a go command installed from https://golang.org/dl, I see:

$ export GOPROXY=direct

$ go1.16.4 get -d github.com/redhat-developer/app-services-sdk-go@v0.1.0
go: downloading github.com/redhat-developer/app-services-sdk-go v0.1.0
go get: github.com/redhat-developer/app-services-sdk-go@v0.1.0: verifying module: checksum mismatch
        downloaded: h1:CTtOQF56Byqzif+XOwD877tjSQygBxs3C/S4s5k/RX8=
        sum.golang.org: h1:HmEhUCF4ohSOghuC9YmYgx7QS4nMkRABmsbEcgx4zuA=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

$ go1.16.4 get -d github.com/redhat-developer/app-services-sdk-go@v0.1.1
go: downloading github.com/redhat-developer/app-services-sdk-go v0.1.1
go get: github.com/redhat-developer/app-services-sdk-go@v0.1.1: verifying module: checksum mismatch
        downloaded: h1:+2GtV3ouUy+Cnls+JZPRkk5Hlo9mUgQ+goXdInElyrM=
        sum.golang.org: h1:wa0XmeJ/5zS/rftq8N7UZyjQHgT1laAA/xXH99rtOC8=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

That suggests to me that whoever is using that repo is probably bypassing both the Go module proxy (https://proxy.golang.org) and the Go checksum server (https://sum.golang.org). Requests to the proxy and/or checksum server are what cause packages to be included in the index (https://index.golang.org), and the index is how pkg.go.dev finds out about new versions — if nobody tells the Go servers about new versions, then (by design!) they won't be indexed on pkg.go.dev.

I seem to recall that the Fedora fork of the go command intentionally bypasses the Go servers by default. Is it possible that the developers and users of github.com/redhat-developer are using the Fedora fork instead of an unmodified distribution of the Go toolchain and forgetting to enable the proxy and checksum server?

To avoid these kinds of problems, I recommend that you use Go binaries distributed and supported by the Go project (or built from unmodified source) to develop your module.

@jba
Copy link
Contributor

jba commented Jun 1, 2021

Regarding v0.1.2 specifically, we don't show it because it contains no Go code. It looks like you've moved all the packages into sub-modules. That's fine, but it means there's nothing for us to show. (We have to ignore module zips with no Go files, because nothing else in the pipeline does any checking. For example, the module proxy can (and probably does) contain zips of pure Javascript or Python or whatever.)

You could add a doc.go file to the top-level module that contains some documentation. That trivial package should be enough for us to display a page, with links to the sub-modules in the Directories section. Your doc.go file could hold information common to all the project's packages. For a similar case, see https://pkg.go.dev/cloud.google.com/go@v0.82.0#section-documentation, although that top-level module does have some other packages in it.

@jba jba self-assigned this Jun 1, 2021
@jba jba added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Jun 1, 2021
@jba jba modified the milestones: Unreleased, pkgsite/unplanned Jun 1, 2021
@craicoverflow
Copy link
Author

craicoverflow commented Jun 1, 2021

It appears that someone moved or otherwise changed the tags in that repository.
Using a go command installed from golang.org/dl, I see:

$ export GOPROXY=direct

$ go1.16.4 get -d github.com/redhat-developer/app-services-sdk-go@v0.1.0
go: downloading github.com/redhat-developer/app-services-sdk-go v0.1.0
go get: github.com/redhat-developer/app-services-sdk-go@v0.1.0: verifying module: checksum mismatch
        downloaded: h1:CTtOQF56Byqzif+XOwD877tjSQygBxs3C/S4s5k/RX8=
        sum.golang.org: h1:HmEhUCF4ohSOghuC9YmYgx7QS4nMkRABmsbEcgx4zuA=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

$ go1.16.4 get -d github.com/redhat-developer/app-services-sdk-go@v0.1.1
go: downloading github.com/redhat-developer/app-services-sdk-go v0.1.1
go get: github.com/redhat-developer/app-services-sdk-go@v0.1.1: verifying module: checksum mismatch
        downloaded: h1:+2GtV3ouUy+Cnls+JZPRkk5Hlo9mUgQ+goXdInElyrM=
        sum.golang.org: h1:wa0XmeJ/5zS/rftq8N7UZyjQHgT1laAA/xXH99rtOC8=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

That suggests to me that whoever is using that repo is probably bypassing both the Go module proxy (proxy.golang.org) and the Go checksum server (sum.golang.org). Requests to the proxy and/or checksum server are what cause packages to be included in the index (index.golang.org), and the index is how pkg.go.dev finds out about new versions — if nobody tells the Go servers about new versions, then (by design!) they won't be indexed on pkg.go.dev.

I seem to recall that the Fedora fork of the go command intentionally bypasses the Go servers by default. Is it possible that the developers and users of github.com/redhat-developer are using the Fedora fork instead of an unmodified distribution of the Go toolchain and forgetting to enable the proxy and checksum server?

To avoid these kinds of problems, I recommend that you use Go binaries distributed and supported by the Go project (or built from unmodified source) to develop your module.

Thanks for the info - I was using the Fedora fork and have changed it now!

@craicoverflow
Copy link
Author

Regarding v0.1.2 specifically, we don't show it because it contains no Go code. It looks like you've moved all the packages into sub-modules. That's fine, but it means there's nothing for us to show. (We have to ignore module zips with no Go files, because nothing else in the pipeline does any checking. For example, the module proxy can (and probably does) contain zips of pure Javascript or Python or whatever.)

You could add a doc.go file to the top-level module that contains some documentation. That trivial package should be enough for us to display a page, with links to the sub-modules in the Directories section. Your doc.go file could hold information common to all the project's packages. For a similar case, see pkg.go.dev/cloud.google.com/go@v0.82.0#section-documentation, although that top-level module does have some other packages in it.

Thanks! That makes sense.

@julieqiu
Copy link
Member

It doesn't seem like there's anything actionable on our end, so closing this issue.

@golang golang locked and limited conversation to collaborators Jun 15, 2022
@rsc rsc unassigned jba Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. pkgsite
Projects
None yet
Development

No branches or pull requests

5 participants