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

update golang to v1.23 #495

Merged
merged 1 commit into from
Dec 26, 2024
Merged

update golang to v1.23 #495

merged 1 commit into from
Dec 26, 2024

Conversation

stklcode
Copy link
Contributor

@stklcode stklcode commented Dec 26, 2024

golang 1.21 is EOL since August and 1.22 will follow around February. So let's jump to the latest supported version 1.23. (and run go mod tidy)

CI passes and quick manual tests don't show any regression.

@stklcode stklcode requested a review from a team as a code owner December 26, 2024 18:15
Copy link
Member

@zakird zakird left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks — makes a lot of sense to me.

@zakird zakird merged commit 79b2303 into zmap:main Dec 26, 2024
3 checks passed
@stklcode stklcode deleted the go123 branch December 26, 2024 18:23
@Seanstoppable
Copy link

We didn't seem to want to make this jump for zgrab2 in zmap/zgrab2#466

Does zdns not have the same issues, or do we not particularly care to maintain consistency across the projects?

@stklcode
Copy link
Contributor Author

stklcode commented Dec 26, 2024

Today 1.22 is available pre-packaged for almost any semi-modern OS of the last 8 years or so. 1.23 is also okay, guess that was not the case back in September, few days after the release. And if I got it right, it’s only about compiling from source.

Stalin 1.21 already fails most security scanners today as well as statically linked binaries do (did not run any deeper analysis on the actual impact - if any - just noticed the crit warning on my minimalistic 2.0.0-RC1 container build)

1.22 should not make much of a difference and could increase compatibility for projects including the code as a library - quite a fair point. Build process for binaries is a pretty weak argument though IMHO, this can be easily delegated to a build system, container or similar running a recent golang version.

@zakird
Copy link
Member

zakird commented Dec 26, 2024

I think it's fine to bump Zgrab to 1.23 too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants