| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|\
| |
| | |
Use the latest libxml2, libxslt, libyaml, and openssl
|
| |
| |
| |
| | |
Signed-off-by: Tim Smith <tsmith@chef.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libxml2:
A GIANT list of bugfixes and these CVEs:
CVE-2017-9050
CVE-2017-9049
CVE-2017-9048
CVE-2017-9047
CVE-2017-8872
CVE-2016-9318
https://www.cvedetails.com/vulnerability-list/vendor_id-1962/product_id-3311/Xmlsoft-Libxml2.html
libxslt:
- Fixes bad memory handling and null derefs plus a GIANT list of bug
libyaml:
* Fixed segfault in yaml_string_write_handler.
* Fixed invalid simple key assertion.
* Fixed error handling in some examples (thank to Mathias Svensson).
* Removed obsolete VS project files.
openssl:
CVE-2017-3731 (OpenSSL advisory) [Moderate severity] 26th January 2017:
If an SSL/TLS server or client is running on a 32-bit host, and a specific cipher is being used, then a truncated packet can cause that server or client to perform an out-of-bounds read, usually resulting in a crash. For OpenSSL 1.1.0, the crash can be triggered when using CHACHA20/POLY1305; users should upgrade to 1.1.0d. For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have not disabled that algorithm should update to 1.0.2k Reported by Robert Święcki of Google.
CVE-2017-3732 (OpenSSL advisory) [Moderate severity] 26th January 2017:
There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very similar to CVE-2015-3193 but must be treated as a separate problem. Reported by OSS-Fuzz project.
CVE-2016-7055 (OpenSSL advisory) [Low severity] 10th November 2016:
There is a carry propagating bug in the Broadwell-specific Montgomery multiplication procedure that handles input lengths divisible by, but longer than 256 bits. Analysis suggests that attacks against RSA, DSA and DH private keys are impossible. This is because the subroutine in question is not used in operations with the private key itself and an input of the attacker's direct choice. Otherwise the bug can manifest itself as transient authentication and key negotiation failures or reproducible erroneous outcome of public-key operations with specially crafted input. Among EC algorithms only Brainpool P-512 curves are affected and one presumably can attack ECDH key negotiation. Impact was not analyzed in detail, because pre-requisites for attack are considered unlikely. Namely multiple clients have to choose the curve in question and the server has to share the private key among them, neither of which is default behaviour. Even then only clients that chose the curve will be affected.ctures using a callback which do not handle NULL value are affected. Reported by Publicly reported.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| |
|
|\
| |
| | |
Include Ohai 13.6
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ohai Release Notes 13.6
- Critical Plugins
Users can now specify a list of plugins which are `critical`. Critical plugins will cause Ohai to fail if they do not run successfully (and thus cause a Chef run using Ohai to fail). The syntax for this is:
```
ohai.critical_plugins << :Filesystem
```
- Filesystem now has a `allow_partial_data` configuration option
The Filesystem plugin now has a `allow_partial_data` configuration option. If set, the filesystem will return whatever data it can even if some commands it ran failed.
- Rackspace detection on Windows
Windows nodes running on Rackspace will now properly detect themselves as running on Rackspace without a hint file.
- Package data on Amazon Linux
The Packages plugin now supports gathering packages data on Amazon Linux
Signed-off-by: Bryan McLellan <btm@loftninjas.org>
|
| |
|
|\
| |
| | |
Deprecate the deploy resource and family
|
| |
| |
| | |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
| |
| |
| |
| | |
Signed-off-by: Noah Kantrowitz <noah@coderanger.net>
|
| | |
|
|\ \
| | |
| | | |
Fix remote_file with UNC paths failing
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Our check here to see if we're on Windows uses node data that's not
available in this context. Use the same Chef::Platform.windows? check we
use above. Without this you get the following error:
[2017-10-02T21:40:42+00:00] DEBUG: Re-raising exception: NameError - remote_file[c:/foo/bar] (foo::default line 14) had an error: NameError: undefined local variable or method `node' for #<Chef::Provider::RemoteFile::NetworkFile:0x00000000064c0148>
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Bump dependencies to pull in new InSpec
|
|/ /
| |
| |
| | |
Signed-off-by: Adam Leff <adam@leff.co>
|
| | |
|
|\ \
| | |
| | | |
[MSYS-647] array support for choco pkg from artifactory
|
| | |
| | |
| | |
| | | |
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
|
| | |
| | |
| | |
| | | |
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
|
| | |
| | |
| | |
| | | |
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
|
| | |
| | |
| | |
| | | |
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
|
| | |
| | |
| | |
| | | |
Signed-off-by: dheerajd-msys <dheeraj.dubey@msystechnologies.com>
|
| | | |
|
|\ \ \
| | | |
| | | | |
MSYS-684: Added parser for DSC configuration
|
| | | |
| | | |
| | | |
| | | | |
Signed-off-by: piyushawasthi <piyush.awasthi@msystechnologies.com>
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
fix rebooter for solaris and background reboots
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
closes #5026
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
| | | | | |
|
|\ \ \ \ \
| |/ / / /
|/| | | |
| | | | |
| | | | | |
chef/ash/add_none_frequency_to_windows_task_resource
Windows: Added :none frequency to windows_task resource
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: NAshwini <ashwini.nehate@msystechnologies.com>
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: NAshwini <ashwini.nehate@msystechnologies.com>
|
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: NAshwini <ashwini.nehate@msystechnologies.com>
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
only rhel >= 8 and fedora >= 22 get dnf
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
the shell_out approach to parse the version string from rpm is a bit of
a failed experiment.
the shell_out that gets incurred on every package provider is a bit
terrible for performance.
DNF < 1.00 has also never formally landed in any distribution and its
very difficult at this point to deploy it.
when amazon deploys DNF we should add a version comparison for that.
If this patch causes issues we can go back to adding some form of
`provides :package ... { which("dnf" }`
That will be much faster than having the shell_out().
Signed-off-by: Lamont Granquist <lamont@scriptkiddie.org>
|
|\ \ \ \ \
| | | | | |
| | | | | | |
A bit of changelog cleanup
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Remove some items that don't matter. Remove internal Chef ticket
numbers.
Signed-off-by: Tim Smith <tsmith@chef.io>
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We should not stack-trace, we should exit with a clean error
Signed-off-by: Phil Dibowitz <phil@ipom.com>
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Sleep for another interval after handling SIGHUP
|
|/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Giedrius Rekasius <giedrius.rekasius@gmail.com>
This resolves a bug that caused chef-client service to go into
infinite sleep after handling SIGHUP.
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
[SUSTAIN-731] Don't spin in powershell module that launches chef processes
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: Kartik Null Cating-Subramanian <ksubramanian@chef.io>
|