[GH-ISSUE #5176] consider bumping the go version in go.mod to latest 1.24 release?

gitea-mirror commented

2026-05-05 14:33:50 -06:00

Owner

Copy link

Originally created by @caphrim007 on GitHub (Feb 12, 2026).
Original GitHub issue: https://github.com/fatedier/frp/issues/5176

Bug Description

hi. i was hoping you might consider bumping the version of go in the go.mod file to 1.24.13. the reason it came to my attention was due to this CVE in lesser Go versions that was pointed out to me.

https://nvd.nist.gov/vuln/detail/CVE-2025-68121

i have no reason to believe that frp itself is vulnerable to anything here, i'm more interested in deflecting the spooks who think every vulnerability means unacceptable risk.

i considered that this was a patch release (1.24.0 to 1.24.13) and that, while it is a significant jump in versions, is a jump that isn't unreasonable considering Go's history of non-breaking changes for patch releases.

i skimmed the commits between the two tags, provided link below.

https://github.com/golang/go/compare/go1.24.0...go1.24.13

the only thing that primarily stood out to me was an emphasis on TLS resumption/chain checks and x509 rules; in both cases things becoming more consistent or, for lack of a better term, "strict".

there isn't code specifically in frp that would cause a problem, but only possibly in a person's usage of frp and the inputs they provide.

for instance, if previously valid certs provided to frp were now not valid due to improved domain name, or SAN verification, this might be seen by the user as a failure of frp.

I was looking at pkg/transport/tls.go and its usage of pool := x509.NewCertPool() and pool.AppendCertsFromPEM(caCrt). I think certainly previously "correct" certs here might now be rejected by Go's standard lib. I don't know that this is a concern in practice.

anyways. wanted to bring this up and include some due-diligence in case it helps make the case for doing a bump.

thanks for reading and considering.

frpc Version

0.67.0

frps Version

0.67.0

System Architecture

linux/amd64

Configurations

Logs

No response

Steps to reproduce

...

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @caphrim007 on GitHub (Feb 12, 2026). Original GitHub issue: https://github.com/fatedier/frp/issues/5176 ### Bug Description hi. i was hoping you might consider bumping the version of go in the go.mod file to 1.24.13. the reason it came to my attention was due to this CVE in lesser Go versions that was pointed out to me. * https://nvd.nist.gov/vuln/detail/CVE-2025-68121 i have no reason to believe that frp itself is vulnerable to anything here, i'm more interested in deflecting the spooks who think every vulnerability means unacceptable risk. i considered that this was a patch release (1.24.0 to 1.24.13) and that, while it is a significant jump in versions, is a jump that isn't unreasonable considering Go's history of non-breaking changes for patch releases. i skimmed the commits between the two tags, provided link below. * https://github.com/golang/go/compare/go1.24.0...go1.24.13 the only thing that primarily stood out to me was an emphasis on TLS resumption/chain checks and x509 rules; in both cases things becoming more consistent or, for lack of a better term, "strict". there isn't code specifically in frp that would cause a problem, but only possibly in a person's usage of frp and the inputs they provide. for instance, if previously valid certs provided to frp were now not valid due to improved domain name, or SAN verification, this might be seen by the user as a failure of frp. I was looking at `pkg/transport/tls.go` and its usage of `pool := x509.NewCertPool()` and `pool.AppendCertsFromPEM(caCrt)`. I think certainly previously "correct" certs here might now be rejected by Go's standard lib. I don't know that this is a concern in practice. anyways. wanted to bring this up and include some due-diligence in case it helps make the case for doing a bump. thanks for reading and considering. ### frpc Version 0.67.0 ### frps Version 0.67.0 ### System Architecture linux/amd64 ### Configurations NA ### Logs _No response_ ### Steps to reproduce 1. 2. 3. ... ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [x] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror closed this issue

2026-05-05 14:33:51 -06:00

gitea-mirror commented

2026-05-05 14:33:53 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Feb 13, 2026):

Thanks for the report. Our release binaries are built in CI using the latest patch release for the configured Go minor version (e.g., 1.24.x). The go version in go.mod is meant to indicate the minimum supported Go version from a compatibility/feature perspective, not the exact toolchain used for releases. Therefore we don’t plan to bump go.mod just to reflect a specific patch level.

@fatedier commented on GitHub (Feb 13, 2026): Thanks for the report. Our release binaries are built in CI using the latest patch release for the configured Go minor version (e.g., 1.24.x). The go version in go.mod is meant to indicate the minimum supported Go version from a compatibility/feature perspective, not the exact toolchain used for releases. Therefore we don’t plan to bump go.mod just to reflect a specific patch level.

gitea-mirror commented

2026-05-05 14:33:53 -06:00

Author

Owner

Copy link

@caphrim007 commented on GitHub (Feb 13, 2026):

thanks for the clarification. i didnt think to look at the ci workflows here, but can verify that the this request would be resolved upon the next release of frp. cheers!

@caphrim007 commented on GitHub (Feb 13, 2026): thanks for the clarification. i didnt think to look at the ci workflows here, but can verify that the this request would be resolved upon the next release of frp. cheers!

No Branch/Tag specified