GitHub-release tag (v1.2) vs. Go module version of github.com/elazarl/goproxy (like v0.0.0-202412xxx)

[rgoltz]

Summary of the Issue
I'd like to understand the correlation between the release-tag (e.g. v1.2) here at GitHub and the go module version of github.com/elazarl/goproxy (e.g. v0.0.0-20241224112848-b717bebf1f4e). Some vulnerability-databases/vulnerability-vendors now expecting a version like v1.2.0 while checking go.mod/go.sum files.

Additional Information/Context
Some vulnerability-databases reporting (most likely falsely) the version v0.0.0-20240726154733-8b0c20506380 as affected by the fixed/old vulnerability CVE-2023-37788 / GHSA-4r8x-2p26-976p. Following the GitHub Advisory Database (Link), let's fixed in version v0.0.0-20230731152917-f99041a5c027 (and subsequent pseudoversions) - Screenshot from GitHub Advisory Database:

Now, some SBOM based vulnerability-databases checking for a version v1.2.0 (which the scanner expect to solve the CVE).
Screenshot from SBOM report (here from AWS) . They now expact a version called v1.2.0:

Reproduction Steps
If I'm running the command go get github.com/elazarl/goproxy@latest, I'm getting:

go: downloading github.com/elazarl/goproxy v0.0.0-20241224112848-b717bebf1f4e
go: upgraded github.com/elazarl/goproxy v0.0.0-20240726154733-8b0c20506380 => v0.0.0-20241224112848-b717bebf1f4e
go: upgraded golang.org/x/net v0.32.0 => v0.33.0

So, latest is (as expected while checking pkg.go.dev/github.com/elazarl/goproxy) version v0.0.0-20241224112848-b717bebf1f4e:

Questions

• Could you please provide some details and background regarding release-tag vs. go module version?
• Which pseudoversion v0.0.0-202412... would cover the github code-status of release tag v1.2?
• In terms of go.mod/go.sum file the versioning / nomenclature of versions is still v0.0.0-202... for now, right?

Thanks a lot :-)

[ErikPelli]

The cause of the specified CVE was an old x/net package previously specified in the Go modules files: https://github.com/elazarl/goproxy/security/dependabot/3

Now in the master branch we've updated it, so this problem is not present neither in v1.2 nor in the pseudoversion.

The v1.2 tag is the first stable release after a while and contains all the updates of the last years in an official release.
It represents the code after this commit: https://github.com/elazarl/goproxy/tree/0cbc932633993fe1911bff5bb63c3115ac95522f.
Now we plan to periodically release stable releases like this one, after a while tha no one reports issues witth the features/fixes merged in the master branch.

The pseudoversion contains additional fixes released in the last week (we also added a linter, btw).
You can safely use it and, in case, report any issue you find.

What do you think? From your experience the versioning should be handled differently? Should I add this explaination in the readme?

[ErikPelli]

And for the question 3., yes, the latest available version is the v0.0-......., it represents the latest commit in the master branch.
If you have any other questions, please let me know!

[ErikPelli]

Added a section to the readme to explain this, by the way

[rgoltz]

Hi @ErikPelli - Thanks a lot for your useful PR and the detailed information - That helped a lot (you was faster than me with closing this issue). Today, I can the command again:

go get github.com/elazarl/goproxy@latest
go: upgraded github.com/elazarl/goproxy v0.0.0-20240726154733-8b0c20506380 => v1.2.5

Now, it's start using the offical (GitHub)-release-tags. Also the https://pkg.go.dev/github.com/elazarl/goproxy?tab=versions started using the offical release-versions:

So, goproxy now using real release-tags and a release-changelog ❤️ - Great!

[ErikPelli]

Hi @rgoltz, since your issue I started to publish new versions for each commit, to comply with the semantic version standard.
If it's going to continue this well since it's going now, we'll never return to versions like v2024-0.000- etc., because they cause confusion (after all, you have opened an issue related to that).
When this is going to happen, I'll remove the current section from the readme and just keep this normal looking versions!

What do you think?

[ErikPelli]

In the last days I had some time to dedicate to this project, because I'm not finding clients to collaborate with as a freelancer... 🫠

By the way, if you are using this library in one of your projects or in your company, you can submit us a case study, as explained in the readme: it's absolutely not mandatory but it's always good to know how people are using our public work!

[rgoltz]

Sounds great (using the semantic versions + having a 2nd update of README)! - Once everything is done, I think we can also close this old (open) issue here: #394

[ErikPelli]

Sounds great (using the semantic versions + having a 2nd update of README)! - Once everything is done, I think we can also close this old (open) issue here: #394

Yeah, we're still evaluating it (as you see, our release section is now full of releases).
Once we officially implement it, we will close this old issue too!