zclconf / go-cty

A type system for dynamic values in Go applications
MIT License
338 stars 70 forks source link

deps: bump golang.org/x/text to 0.6.0 #151

Closed radeksimko closed 1 year ago

radeksimko commented 1 year ago

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 uses golang.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.

apparentlymart commented 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.)