Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
-
Agent
-
2
-
AP 2017-01-25, AP 2017-02-08, AP 2017-02-22, AP 2017-03-08, Agent 2017-03-22, Agent 2017-04-05
-
Bug Fix
-
-
No Action
-
Build and infra changes not risk-assessed
Description
Puppet::Parameter#format currently does not check if the strings it is interpolating are of incompatible encodings.
This method is used, among other places, in the resource harness when setting the message for failed change events. If the strings contain incompatible encodings (i.e., they cannot be concatenated) the format method will fail, the event will not contain a message, and then it will fail to be logged.
This also results in error messages that look like this:
Error: /Stage[main]/Main/Node[ubuntu16.localdomain]/User[foo]: Could not evaluate: Puppet::Util::Log requires a message
|
Notes
- After diving further into this, this form of problem is scattered all through puppet - the concatenation of strings without regard to encoding. The deeper problem is that strings are entering the system in incompatible encodings to begin with. The problem-area that gave rise to this specific bug is the nameservice provider, and specifically it's reliance on the Etc module in ruby, which can return strings in default external encoding which are then sent around puppet to be compared and munged with utf-8 strings. Thus this ticket is now re-scoped from it's original (smaller context) to include a broader fix of setting strings incoming from Etc to utf-8.
In Scope
- Anywhere we take strings in the from the Etc module in a provider, these strings should have UTF-8 encoding
Attachments
Issue Links
- relates to
-
PUP-7498 Puppet merges two users in different encodings into one
-
- Closed
-
-
PUP-7031 Unicode characters in 'comment' don't round-trip on Windows
-
- Closed
-
-
PUP-1473 user resource fails on UTF-8 comment
-
- Closed
-
-
PUP-6777 regression: incompatible character encodings: UTF-8 and ASCII-8BIT
-
- Closed
-
- links to