Closed radeksimko closed 1 year ago
Hi @radeksimko,
I have intentionally not upgraded the dependency here for reasons discussed previously in https://github.com/zclconf/go-cty/pull/146.
There's also some more context on that for a similar decision over in HashiCorp HCL, where I was wearing my HashiCorp hat: https://github.com/hashicorp/hcl/pull/571
Unfortunately the nature of this particular library (an assortment of mostly-independent functionality with a release policy that doesn't distinguish security updates from significant behavior changes) combined with the behavior of Go Modules (the highest declared dependency in any module of a program forces upgrading on the entire program) means that I've concluded that this dependency will only be upgraded here if the upgrade would directly benefit cty
, and that downstreams should review the consequences of upgrading and decide for themselves whether to select a newer version in their own go.mod
, which would then upgrade cty
's use of the library too. (Only one version of the module can appear in any final program.)
The new version 0.6.0 fixed https://pkg.go.dev/vuln/GO-2022-1059
It is worth noting however that AFAICT
go-cty
is not affected by this vulnerability, since it only usesgolang.org/x/text/unicode/norm
package in https://github.com/zclconf/go-cty/blob/1384f8d8c5d747275c9686ab9829b30c78189ecc/cty/value_init.go#L8 from this library. i.e. it does not use MatchStrings nor ParseAcceptLanguage.Therefore this merely reduces any possible noise from vulnerability scanners downstream.