proxy.golang.org: remove cached module

[mfridman]

Please remove github.com/golang-jwt/jwt module from Go module proxy cache.

I understand the recommendation is to tag a newer version, but this would effectively force the project into a v2+ and SIV which would like to avoid.

What is the URL of the page with the issue?

https://github.com/golang-jwt/jwt

Screenshot

What did you do?

The goal was to clone a repo, remove the existing tags and start with a fresh import path and thus a clean v0 and v1 without SIV.

[seankhliao]

I think this should be covered by retract

cc @katiehockman @heschi @hyangah

[oxisto]

I think this should be covered by retract

cc @katiehockman @heschi @hyangah

There are several issues preventing us from using retract.

1. Unless I have done something majorly wrong, having a retract statement in a go.mod did not compile in Go <= 1.15 (see https://github.com/golang-jwt/jwt/pull/23/checks). We are taking over the maintenance of one of the bigger jwt libraries in the Go ecosystem (http://github.com/dgrijalva/jwt-go) from the original author under this new import name - because the author is inactive and suggested migrating - and want/need to support some older Go versions as well
2. The project (as taken over from the original author) does not have a go.mod file, but has a v3.x.x+incompatible release scheme. Our original plan was to fix that issue by re-releasing with go modules support as v0 / v1 under this new import name, without any breaking changes to the v3.x.x+incompatible, so that we have a drop-in replacement for people without API changes. We would have then moved to a v2-SIV-style version afterwards with breaking changes, once enough people made the move over to the new maintained version of the library.

These two releases currently block us from re-releasing as v0.x.x or v1.x.x, forcing us to stick with the v3.x.x+incompatible release scheme at least for one version with a major security fix (CVE-2020-26160, fixed by golang-jwt/jwt#6) and then moving to a new v4-SIV-style. This is something we wanted to avoid initially. Especially because it seems that building without go modules will be deprecated / removed soonish (according to https://blog.golang.org/go116-module-changes), so we wanted to make go modules available as soon as possible - even if it means re-starting the release cycle.

I hope this explanation makes it a little more clearer where we are coming from and why this is important to us.

[mfridman]

Closing this issue. We'll continue with the recommended suggesting from the proxy FAQ:

Whenever possible, the mirror aims to cache content in order to avoid breaking builds for people that depend on your package, so this bad release may still be available in the mirror even if it is not available at the origin. The same situation applies if you delete your entire repository. We suggest creating a new version and encouraging people to use that one instead.

cc @oxisto Any concerns? The goal of this ticket was solely to get those versions removed from the proxy, and this isn't likely to happen.

[oxisto]

Closing this issue. We'll continue with the recommended suggesting from the proxy FAQ:

Whenever possible, the mirror aims to cache content in order to avoid breaking builds for people that depend on your package, so this bad release may still be available in the mirror even if it is not available at the origin. The same situation applies if you delete your entire repository. We suggest creating a new version and encouraging people to use that one instead.

cc @oxisto Any concerns? The goal of this ticket was solely to get those versions removed from the proxy, and this isn't likely to happen.

Yup, lets go with plan "b". We can close this then