Add word/profanity filter for random_pet

[garretth9]

Terraform CLI and Provider Versions

Terraform v1.5.7
on darwin_arm64

• provider registry.terraform.io/hashicorp/azuread v2.46.0
• provider registry.terraform.io/hashicorp/random v3.6.0

Use Cases or Problem Statement

In some cases random_pet names may be used in user-facing scenarios. For example we use random_pet to generate initial passwords for certain types of accounts. With the current list of words that are being used by the provider it's possible to generate pets that some would consider inappropriate, such as "primarily-witty-jackass" (a real-world example).

Proposal

A couple possible options.

1. Add an "excluded_words = list(string)" parameter. If a pet name is generated containing any of these words a new one should be generated instead.
2. Add an "exclude_profanity = bool" parameter. This could potentially use a libarary such as https://github.com/TwiN/go-away to detect words that could be considered inappropriate without the user needing to manually specify them and generate a new pet name if an inappropriate word is detected.

How much impact is this issue causing?

Low

Additional Information

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[bflad]

Hi @garretth9 👋 Thank you for raising this and sorry for the questionable word results out of this resource.

The random_pet resource implementation relies on an upstream Go module, github.com/dustinkirkland/golang-petname, for returning the names. That Go module sources them from another repository and the maintainer seems amenable to removing questionable word results, such as recently here: dustinkirkland/petname#3 -- since maintainer seems responsive and amenable to these sort of requests, this might seem like a preferable resolution path in these cases. Having practitioners determine and implement a skip-list for every resource implementation seems less than ideal in comparison, since practitioners likely will not know what words the generator may return and therefore what to potentially skip. Implementing a separate library to filter results also seems a little heavy-handed when the results list is extremely stable and manually maintained.

Luckily in this case, it seems like "jackass" was removed in a prior change upstream: dustinkirkland/golang-petname@c546b6c

To fix this immediate issue, I propose we go ahead and upgrade the Go module to remove this particular result, cutting a release, and I might suggest you take a look at (or suggesting further changes to) https://github.com/dustinkirkland/petname/ before doing anything more drastic in this codebase.

Does that sound reasonable? Thanks.

[bflad]

For what it's worth, hashicorp/random v3.6.2 is releasing now with that particular example result removed by nature of upgrading the dependency.