search

hashicorp / terraform-provider-cloudinit

Utility provider that exposes the cloudinit_config data source which renders a multipart MIME configuration for use with cloud-init (previously available as the template_cloudinit_config resource in the template provider)
https://registry.terraform.io/providers/hashicorp/cloudinit/latest
Mozilla Public License 2.0
101 stars 17 forks source link

Support non-ASCII encoded parts #165

Open lel-amri opened 11 months ago

lel-amri commented 11 months ago

Terraform CLI and Provider Versions

terraform version:

Terraform v1.4.4
on linux_amd64
+ provider registry.terraform.io/hashicorp/cloudinit v2.3.2
+ provider registry.terraform.io/hashicorp/local v2.4.0
+ provider registry.terraform.io/hashicorp/null v3.2.1
+ provider registry.terraform.io/hashicorp/random v3.5.1
+ provider registry.terraform.io/hetznercloud/hcloud v1.42.1
+ provider registry.terraform.io/integrations/github v5.34.0
+ provider registry.terraform.io/tenstad/remote v0.1.2

Your version of Terraform is out of date! The latest version
is 1.5.6. You can update by downloading from https://www.terraform.io/downloads.html

Use Cases or Problem Statement

The cloud-init provider sets Content-Transfer-Encoding to 7bit and doesn't make that configurable. This prevent users from having non-ASCII encoded payloads, such as UTF-8 encoded text with characters above the 0x7F code point.

Proposal

There are two encodings that "officially" allow non-ASCII characters in MIME body: quoted-printable and base64. Terraform does not provide a built-in way to escape a string with the quoted-printable style, as defined in RFC 2045, which leave the base64 encoding, which is provided by the textencodebase64 function. This is why I lean towards using base64 encoding rather than quoted-printable escaping.

I suggest we let the user decide a value for Content-Transfer-Encoding in part blocks, with a default of 7bit. This way the cloud-init provider can stay dumb (the user is responsible for providing sensible values to the arguments (this is already the case as of today)) and there are no retro-compatibility issues.

Otherwise, we could do the "smart" thing automatically: If we detect bytes greater than 0x7F in content, we automatically encode the content to base64 and we set Content-Transfer-Encoding to base64. This is a simple behavior that should always work, if we believe the RFCs. This shouldn't break retro-compatibility because cloud-init is unable to read MIME that have Content-Transfer-Encoding set to 7bit and a body with characters greater than 0x7F. The error looks like this:

cloud-init[929]: 2023-09-05 12:00:00,000 - util.py[WARNING]: Failed loading yaml blob. unacceptable character #xdce9: special characters are not allowed in "<unicode string>", position 6783
cloud-init[929]: 2023-09-05 12:00:00,000 - cloud_config.py[WARNING]: Failed at merging in cloud config part from init.cfg: empty cloud config

Working configurations will keep working. Broken configurations will at best start working and at worst stay broken.

How much impact is this issue causing?

Medium

Additional Information

No response

Code of Conduct

lel-amri commented 8 months ago

Hello @austinvalle, I'm sorry to ping you, but I'd like to bring your attention to this three months old issue, which have a small pull request (https://github.com/hashicorp/terraform-provider-cloudinit/pull/170) waiting. It seems to me that you are the only maintainer for this provider currently.