This addresses the following security issues:
* CVE-2019-14846 - Several Ansible plugins could disclose aws
credentials in log files. inventory/aws_ec2.py, inventory/aws_rds.py,
lookup/aws_account_attribute.py, and lookup/aws_secret.py,
lookup/aws_ssm.py use the boto3 library from the Ansible process. The
boto3 library logs credentials at log level DEBUG. If Ansible's
logging was enabled (by setting LOG_PATH to a value) Ansible would set
the global log level to DEBUG. This was inherited by boto and would
then log boto credentials to the file specified by LOG_PATH. This did
not affect aws ansible modules as those are executed in a separate
process. This has been fixed by switching to log level INFO
* Convert CLI provided passwords to text initially, to prevent unsafe
context being lost when converting from bytes->text during post
processing of PlayContext. This prevents CLI provided passwords from
being incorrectly templated (CVE-2019-14856)
* properly hide parameters marked with no_log in suboptions when
invalid parameters are passed to the module (CVE-2019-14858)
* resolves CVE-2019-10206, by avoiding templating passwords from
prompt as it is probable they have special characters.
* Handle improper variable substitution that was happening in
safe_eval, it was always meant to just do 'type enforcement' and have
Jinja2 deal with all variable interpolation. Also see CVE-2019-10156
Changelog: https://github.com/ansible/ansible/blob/9bdb89f740a87bcf760424577ce18a8f68d7a741/changelogs/CHANGELOG-v2.6.rst
This addresses the following security issues:
* Ansible: Splunk and Sumologic callback plugins leak sensitive data in logs (CVE-2019-14864)
* CVE-2019-14846 - Several Ansible plugins could disclose aws
credentials in log files. inventory/aws_ec2.py, inventory/aws_rds.py,
lookup/aws_account_attribute.py, and lookup/aws_secret.py,
lookup/aws_ssm.py use the boto3 library from the Ansible process. The
boto3 library logs credentials at log level DEBUG. If Ansible's
logging was enabled (by setting LOG_PATH to a value) Ansible would set
the global log level to DEBUG. This was inherited by boto and would
then log boto credentials to the file specified by LOG_PATH. This did
not affect aws ansible modules as those are executed in a separate
process. This has been fixed by switching to log level INFO
* Convert CLI provided passwords to text initially, to prevent unsafe
context being lost when converting from bytes->text during post
processing of PlayContext. This prevents CLI provided passwords from
being incorrectly templated (CVE-2019-14856)
* properly hide parameters marked with no_log in suboptions when
invalid parameters are passed to the module (CVE-2019-14858)
Changelog: https://github.com/ansible/ansible/blob/24220a618a6d5cd3b5c99f8c7f7771661ed08d33/changelogs/CHANGELOG-v2.8.rst
This fixes the following security issues:
* Ansible: Splunk and Sumologic callback plugins leak sensitive data
in logs (CVE-2019-14864)
* CVE-2019-14846 - Several Ansible plugins could disclose aws
credentials in log files. inventory/aws_ec2.py, inventory/aws_rds.py,
lookup/aws_account_attribute.py, and lookup/aws_secret.py,
lookup/aws_ssm.py use the boto3 library from the Ansible process. The
boto3 library logs credentials at log level DEBUG. If Ansible's
logging was enabled (by setting LOG_PATH to a value) Ansible would set
the global log level to DEBUG. This was inherited by boto and would
then log boto credentials to the file specified by LOG_PATH. This did
not affect aws ansible modules as those are executed in a separate
process. This has been fixed by switching to log level INFO
* Convert CLI provided passwords to text initially, to prevent unsafe
context being lost when converting from bytes->text during post
processing of PlayContext. This prevents CLI provided passwords from
being incorrectly templated (CVE-2019-14856)
* properly hide parameters marked with no_log in suboptions when invalid
parameters are passed to the module (CVE-2019-14858)
* resolves CVE-2019-10206, by avoiding templating passwords from
prompt as it is probable they have special characters.
* Handle improper variable substitution that was happening in
safe_eval, it was always meant to just do 'type enforcement' and have
Jinja2 deal with all variable interpolation. Also see CVE-2019-10156
Changelog: https://github.com/ansible/ansible/blob/0623dedf2d9c4afc09e5be30d3ef249f9d1ebece/changelogs/CHANGELOG-v2.7.rst#v2-7-15
Update to latest version & updated the patch file to match with the
lastest verison.
Fixes the following security issue:
* CVE-2019-19722: Mails with group addresses in From or To fields
caused crash in push notification drivers.
This cuts down the dependency tree on some rust builds where a crate not
just exposes a binary but also a library. `$out/lib` contained a bunch
of extra support files that among other information carry linker flags
(including the full path to link-time dependencies). Worst case this led
to some binary outputs depending on the full build closure of rust
crates.
Moving all the `$out/lib` files to `$lib/lib` solves this nicely.
`lib` might be a bit weird here as they are most of the time just rlib
files (rust libraries). Those are essential only required during
compilation but they can also be shared objects (like with traditional
C-style packages). Which is why I went with `lib` for the new output.
One of the caveats we are running into here is that we do not (always)
know ahead of time of a crate produces just a library or just a binary.
Cargo allows for some ambiguity regarding whether or not a crate
provides one, two, … binaries and libraries as it's outputs. Ideally we
would be able to rely on the `crateType` entirely but so far that isn't
the case. More work on that area might show how difficult that actually
is.
This is a more sane default since we do not magically (without opt-in)
pull in binaries from `~/bin`. That is not really an expected behavior
for many users. Users that still want that behavior can now just flip
that switch.
This has the benefit of being able to override all the inputs to the
build where you were previously only able to override the entire package
set (if at all).
Previously only direct dependencies were available in the python search
path. Transitive dependencies would not be available and thus a few
features would not work due to import errors. Those import errors were
being caugth and gave a (wrong) hint why it wouldn't work. By using
`python.withPackages` instead of the crafted search path with only the
direct dependencies those missing feature should now be working.
See issue #67094 for details on the observed errors.
Fixes#67094
It turned out that /dev/snd/* always exists even if there are no sound
drivers loaded at all. Loading `snd` and `snd_timer` fixes that
situation. It is probably fair to assume someone that wants to use sound
also enables that in the NixOS configuration.
With systemd version 243 network units with empty match block will
generate warnigs. The reasoning seems to be that the intended behaviour
is hard to infere. Being explicit about really meaning any interface is
the reasonable thing here.
We want to get rid of this mechanism in the long run but as long as we
do not have a replacement we should stick with it and keep it in
reasonable good shape.
While Firefox 68 started messing with our profiles and required new
profiles on binary location changes Firefox 69 now verifies that we
aren't downgrading to an older Firefox even of the same version. If you
switch between two channel versions and/or between nixpkgs releases
Firefox will refuse to start and demand a fresh profile. Disabling the
downgrade protection works around that issue.
Fixes:
* CVE-2019-6472 affects the Kea DHCPv6 server, which can exit
with an assertion failure if the DHCPv6 server process receives
a request containing DUID value which is too large.
(https://kb.isc.org/docs/cve-2019-6474)
* CVE-2019-6473 affects the Kea DHCPv4 server, which can exit with
an assertion failure if it receives a packed containing a malformed
option. (https://kb.isc.org/docs/cve-2019-6473)
* CVE-2019-6474 can cause a condition where the server cannot be
restarted without manual operator intervention to correct a problem
that can be deliberately introduced into the stored leases.
CVE-2019-6474 can only affect servers which are using memfile
for lease storage. (https://kb.isc.org/docs/cve-2019-6474)
Annoucement: https://www.openwall.com/lists/oss-security/2019/08/29/1
Andreas Rammhold