Update text library to non-vulnerable version v0.3.7. CVE-2021-38561

[ybocalandro]

Request to update github.com/zclconf/go-cty to v1.11.0 in order to remove golang.org/x/text vulnerable versions. CVE-2021-38561

vulnerable versions golang.org/x/text v0.3.2 golang.org/x/text v0.3.5 golang.org/x/text v0.3.6

[hashicorp-cla]

All committers have signed the CLA.

[apparentlymart]

Hi @ybocalandro! Thanks for this contribution.

Upstream cty v1.11.0 and later requires Go 1.18, so I think we'll need to check whether any important users of this library are blocked from using Go 1.18 before we proceeed, but in general it does seem reasonable to switch to the later version of that library.

In the meantime though, you should be able to upgrade golang.org/x/text from your own main module's go.mod, because go.mod files only describe minimum dependencies, not exact dependencies:

go get golang.org/x/text@latest

If your own go.mod specifies a newer version of that package than go-cty does then the Go toolchain will use the newer version.

With that said, the specific disclosure you mentioned does not seem relevant to HCL or cty because it is related to language tag parsing, and neither HCL or cty interact with language tags. cty uses golang.org/x/text only for its Unicode normalization package, which does not interact with language tags. Remaining on the old version should therefore not make your application vulnerable unless some unrelated caller of golang.org/x/text in your dependency graph is using the language tag parser.

[ybocalandro]

Hi @apparentlymart Thanks for taking a pass on this PR I don't see the requirement on Go 1.18 as a blocker in my opinion since hcl v2 is using Go 1.18 already.

[apparentlymart]

The test suite for the v2 series of HCL does currently require Go 1.18 for the fuzz testing features, but the main library code intentionally doesn't require any Go 1.18 features yet because not all callers of HCL are ready to upgrade to Go 1.18.

We will upgrade the dependency on github.com/zclconf/go-cty only once HCL actually requires a newer version of that library. HCL is not yet using any features of that library which require a later version, and a library's responsibility is only to declare what it requires, not what its callers require. If you have a caller which requires a newer version then you can upgrade that dependency yourself for your entire program as I described in my previous comment.

Any change to this version requirement will typically come as part of another PR which adds code which depends on a newer version of the dependency, rather than as a separate change just to upgrade the dependency, and so I'm going to close this until we have such a reason to upgrade. Thanks!