How to handle different package version between golang plugin and tyk gateway

Support Installation and Deployment
,
1

Hi, I’m having a trouble building golang plugins using tykio/tyk-plugin-compiler:v5.2.1 and docker.tyk.io/tyk-gateway/tyk-gateway:v5.2.1-amd64 docker images. One of my imported package uses gopkg.in/square/go-jose.v2 v2.6.0 while tyk uses gopkg.in/square/go-jose.v2 v2.3.1 and it shows the following error:

tyk-gateway-tyk-gateway-1          | time="Oct 15 15:49:16" level=error msg="Could not load Go-plugin" error="plugin.Open(\"/opt/tyk-gateway/middleware/GolangPlugins_v5.2.1_linux_amd64.so\"): plugin was built with a different version of package gopkg.in/square/go-jose.v2/cipher (previous failure)" mwPath=/opt/tyk-gateway/middleware/GolangPlugins.so mwSymbolName=Auth

It runs normally when I removed the conflicting package. Some things that I tried:

  • Manually change the tag to v2.3.1, it automatically reverts back to v2.6.0 when doing go mod tidy

  • Add replace on plugin’s go module replace gopkg.in/square/go-jose.v2 v2.6.0 => gopkg.in/square/go-jose.v2 v2.3.1, but it still shows the same error

  • Clone Tyk gateway v5.2.1 repo GitHub - TykTechnologies/tyk at release-5.2.1 and use the code as the container source (also tried removing the image: internal/tyk-gateway command on docker-compose.yml so it builds from local Dockerfile), but it shows a fatal error fatal error: runtime: no plugin module data. similar error also occured when I’m using v4.x gateway with v5.x plugin compiler.

As for the 3rd point, I’m not sure whether I’m building the container correctly or not, because by default, when running docker-compose up it shows a log saying v4.3.0 Tyk API Gateway v4.3.0. When I remove this line image: internal/tyk-gateway, it shows the correct version but it still behave the same way.

Is there any alternative that I could try or is there any mistakes that I did when building the container?

Thanks

2

I have posed this question internally and the reply is that dependencies without go.mod are known to cause conflict for plugins.

There was a quick check to verify this. The workaround to produce a compatible build seems to be by using go-jose/go-jose. Test/go jose by titpetric · Pull Request #5638 · TykTechnologies/tyk · GitHub

Let us know if this works.

3

Hi @Olu

I’ve tried the workaround you have suggested, but the issue still happens in our case. Also I can’t add “GitHub - square/go-jose: An implementation of JOSE standards (JWE, JWS, JWT) in Go v2.6.1+incompatible” because it’s automatically removed when we run “go mod tidy”

Do you have other suggestions to fix this issue? Thank you.

4

If this happens then you may not be using the library in code. In the PR example, a jose.Encrypter is specified

5

This could happen to different packages. Myself am facing troubles with github.com/xeipuuv/gojsonpointer. Don’t we have a better approach?

6

Using such dependencies is a known cause of build incompatibility issues. We have a separate updated import for it, it seems GitHub - go-openapi/jsonpointer: fork of gojsonpointer with support for structs.

Hope this helps.