(#18986) Write to the console using Unicode Win32 APIs

Previously, puppet on windows could not output unicode characters to the
console reliably, such as the box drawing characters used by the module
tool when displaying dependencies.

Ruby 1.8 uses the ANSI Win32 APIs, e.g. WriteConsole, to write to the
console. However, it uses the current console codepage. So if the current
codepage cannot handle the unicode character we're trying to write, e.g.
cp1252, then it displays garbage.

Ruby 1.9 uses the Unicode Win32 APIs, e.g. WriteConsoleW. As such, it can
correctly write unicode output, without being sensitive to the current
codepage.

However, because puppet writes ANSI escape sequences, we use the
win32console gem to color the output. This win32console gem redefines the
stdout and stderr streams to accomplish this, and sadly uses ANSI versions
of Win32 APIs to write to the console. So it has the same problems as ruby
1.8.

This commit overrides the win32console classes, Console and IO, to ensure
the Unicode APIs are used. This enables us to display ANSI escape
sequences and unicode characters that may not be compatible with the
current codepage.

Longer term we should think about removing win32console gem altogether and
moving to ruby 1.9, as these hacks would no longer be required. Though
doing so would mean losing color output, or taking more drastic measures
like ansicon.
(#19393) Safely load YAML from the network

When using Psych (only available in Ruby 1.9), YAML.load may in certain
cases (!map: and !ruby/hash: tags) use the initialize and []= methods to
create objects. These methods could potentially allow arbitrary code to
be executed. We now add a safely_load method which parses the input
first, checks it for dangerous tags, and fails if they are found. If the
input is clean, we transform the result (as YAML.load would have done)
and go on our merry way.

This change is only applied to YAML coming in either HTTP requests or
responses. YAML from the local system is trusted, as anyone who can
write that YAML could do damage some other way.
(#19393) Safely load YAML from the network

When using Psych (only available in Ruby 1.9), YAML.load may in certain
cases (!map: and !ruby/hash: tags) use the initialize and []= methods to
create objects. These methods could potentially allow arbitrary code to
be executed. We now add a safely_load method which parses the input
first, checks it for dangerous tags, and fails if they are found. If the
input is clean, we transform the result (as YAML.load would have done)
and go on our merry way.

This change is only applied to YAML coming in either HTTP requests or
responses. YAML from the local system is trusted, as anyone who can
write that YAML could do damage some other way.
Merge remote-tracking branch 'puppet-cve-test/safely-yaml-3.1.0' into security/3.1.0/february_code_orange

* puppet-cve-test/safely-yaml-3.1.0:
  (#19393) Safely load YAML from the network
Merge pull request #11 from puppetlabs/safely-yaml

(#19393) Safely load YAML from the network
(#14093) Cleanup tests for template functionality

Some of the previous tests were unneeded (check for simple existance) or
mis-named. This cleans those up. A few other tests were trying to
indirectly test many things at once (the ones about access to instance
variables). Instead of the indirect test this splits it into much more
specific tests and statement of behavior.
(#14093) Remove unsafe attributes from TemplateWrapper

The attribute accessor for the :string attribute in the TemplateWrapper
conflicted with a variable being in scope that is named string. The
variable would take precedence and because of the way the
TemplateWrapper accessed the value of the attribute, the variable's
value would be used as the template.

This changes the TemplateWrapper to completely remove :string as an
attribute and only use local variables. This also removes the :file
attribute in favor of a "private"-style naming of the instance variable.
There are no collisions with @__file__ that would cause problems, but
this should reduce the likelihood of them happening in the first place.
(#14093) Restore access to the filename in the template

The change to fix certain variables interfering with template evaluation
also removed the accessor method for file. It appears that this is a
mechanism that had been used by others for identifying the name of the
template being evaluated so that they can trace back from a file on a
node to the module and template that created it. This restores that
functionality.
Merge branch 'zaphod42-issue/3.1.0/14093-string-overrides-all-template-output' into security/3.1.0/february_code_orange

* zaphod42-issue/3.1.0/14093-string-overrides-all-template-output:
  (#14093) Restore access to the filename in the template
  (#14093) Remove unsafe attributes from TemplateWrapper
  (#14093) Cleanup tests for template functionality
(#14093) Remove unsafe attributes from TemplateWrapper

The attribute accessor for the :string attribute in the TemplateWrapper
conflicted with a variable being in scope that is named string. The
variable would take precedence and because of the way the
TemplateWrapper accessed the value of the attribute, the variable's
value would be used as the template.

This changes the TemplateWrapper to completely remove :string as an
attribute and only use local variables. This also removes the :file
attribute in favor of a "private"-style naming of the instance variable.
There are no collisions with @__file__ that would cause problems, but
this should reduce the likelihood of them happening in the first place.

This commit is modified from the original version to exclude changes to
the specs that were not related to issue #14903, due to the scope code
being so different in 2.7.x than 3.x.
(#14093) Restore access to the filename in the template

The change to fix certain variables interfering with template evaluation
also removed the accessor method for file. It appears that this is a
mechanism that had been used by others for identifying the name of the
template being evaluated so that they can trace back from a file on a
node to the module and template that created it. This restores that
functionality.
Merge branch 'zaphod42/2.7.20/14093-string-template-overrides' into security/2.7.20/february_code_orange

* zaphod42/2.7.20/14093-string-template-overrides:
  (#14093) Restore access to the filename in the template
  (#14093) Remove unsafe attributes from TemplateWrapper
(#19391) (CVE-2013-1652) Disallow use_node compiler parameter for remote requests

Without this it is possible to bypass catalog access restrictions by passing
in a node object for a different host. We also validate that facts provided
match the node requested.
(#19391) (CVE-2013-1652) Disallow use_node compiler parameter for remote requests

Without this it is possible to bypass catalog access restrictions by passing
in a node object for a different host. We also validate that facts provided
match the node requested.
(#19151) Reject SSLv2 SSL handshakes and ciphers

Without this patch, SSL connections on older versions of Ruby will
negotiate down to insecure modes of operation, specifically SSLv2.  This
is a problem because SSLv2 needs to be rejected outright to meet
security policies.

This patch addresses the problem by changing the behavior of the
OpenSSL::SSL::SSLContext class.  With this patch applied, all SSLContext
objects will be initialized with a default cipher rule set that always
contains the '!SSLv2' substring.  This has the effect of removing SSLv2
ciphers from the cipher list and prohibiting them from being re-added by
later elements in the cipher spec.

Details regarding how OpenSSL behaves with this cipher string are
available at: http://www.openssl.org/docs/apps/ciphers.html

In order to see which ciphers are enabled for a specific version of the
OpenSSL library, please see the output of the command:

    $ openssl ciphers $CIPHERS

This command will display an ordered list of the ciphers enabled for use
during the SSL handshake.

This change is a monkey patch to MRI Core and will affect all SSL socket
clients and servers.  The options and cipher list may still be
explicitly set by passing an options hash with the :options and :ciphers
keys to the SSLContext#set_params method, or by calling the
SSLContext#options= instance method as WEBrick does.  We cannot monkey
patch SSLContext#options= because this method is implemented as a C
extension to MRI and as such cannot be easily redefined.  Segfaults
abound in MRI 1.8.5.
(#19151) Reject SSLv2 SSL handshakes and ciphers

Without this patch, SSL connections on older versions of Ruby will
negotiate down to insecure modes of operation, specifically SSLv2.  This
is a problem because SSLv2 needs to be rejected outright to meet
security policies.

This patch addresses the problem by changing the behavior of the
OpenSSL::SSL::SSLContext class.  With this patch applied, all SSLContext
objects will be initialized with a default cipher rule set that always
contains the '!SSLv2' substring.  This has the effect of removing SSLv2
ciphers from the cipher list and prohibiting them from being re-added by
later elements in the cipher spec.

Details regarding how OpenSSL behaves with this cipher string are
available at: http://www.openssl.org/docs/apps/ciphers.html

In order to see which ciphers are enabled for a specific version of the
OpenSSL library, please see the output of the command:

    $ openssl ciphers $CIPHERS

This command will display an ordered list of the ciphers enabled for use
during the SSL handshake.

This change is a monkey patch to MRI Core and will affect all SSL socket
clients and servers.  The options and cipher list may still be
explicitly set by passing an options hash with the :options and :ciphers
keys to the SSLContext#set_params method.
(#14985) Fix hiera lookup for calling_module and calling_class
(#14985) Fix hiera does not lookup calling_class and calling_module
(#14985) Fix test, return downcase values and check for nil scope.source
(#14985) Fix exception when nil is returned from inner scope