Uploaded image for project: 'Puppet'
  1. Puppet
  2. PUP-6904

Evaluate FileType and ParsedFile classes for UTF-8 compatibility



    • Improvement
    • Status: Closed
    • Normal
    • Resolution: Won't Do
    • None
    • None
    • None


      While investigating how the FileType class works for PUP-6188, a bit of a can of worms was opened.

      FileType has 5 locations where it can specify an encoding explicitly:

      • 1 location for read
      • 4 locations for write

      The problem with changing these from their current default is that FileType is consumed by a number of classes (and also specifically by the Puppet::Provider::ParsedFile helper), so it's not easy to change things for just a single implementation.

      Cron tab files and their equivalent on AIX and Sun should all likely be the Ruby Encoding.default_external encoding, which should match the system encoding... but arguably, INI files should be read / written as UTF-8 in at least some circumstances.

      The problem again is that ParseFile passes in a type of :flat to the FileType helper, which adds some behavior that assumes an encoding - which is likely not technically correct. ParsedFile is used by:

      • lib/puppet/provider/naginator.rb - should probably be default system encoding
      • lib/puppet/provider/cron/crontab.rb - should probably be default system encoding
      • lib/puppet/provider/host/parsed.rb - should probably be default system encoding
      • lib/puppet/provider/mailalias/aliases.rb - should probably be default system encoding
      • lib/puppet/provider/mount/parsed.rb - should probably be default system encoding
      • lib/puppet/provider/ssh_authorized_key/parsed.rb - ASCII should be fine (but what if comments contain Unicode?)
      • lib/puppet/provider/sshkey/parsed.rb - ASCII should be fine (but what if comments contain Unicode?)

      There are currently no user reports of problems, but it's possible that Puppet is just getting lucky here based on current customer usage.

      The short term fix is probably to tactically fix localized problem spots (based on ability to reproduce problems)

      A couple of longer-term solutions here might be:

      • Remove the FileType class completely - this may be tricky given its difficult to fully understand where public API is exposed
      • Allow users to specify encodings in the individual resource types and pass that value down through the resources where appropriate


        Issue Links



              Unassigned Unassigned
              ethan Ethan Brown
              0 Vote for this issue
              3 Start watching this issue



                Zendesk Support