Traceback (most recent call last):
File "/nix/store/8qkdlyv2ckrimvi50qvl0anzv66jcp2j-python-swiftclient-3.6.0/bin/.swift-wrapped", line 7, in <module>
from swiftclient.shell import main
File "/nix/store/8qkdlyv2ckrimvi50qvl0anzv66jcp2j-python-swiftclient-3.6.0/lib/python3.7/site-packages/swiftclient/__init__.py", line 20, in <module>
from .client import * # noqa
File "/nix/store/8qkdlyv2ckrimvi50qvl0anzv66jcp2j-python-swiftclient-3.6.0/lib/python3.7/site-packages/swiftclient/client.py", line 33, in <module>
from swiftclient import version as swiftclient_version
File "/nix/store/8qkdlyv2ckrimvi50qvl0anzv66jcp2j-python-swiftclient-3.6.0/lib/python3.7/site-packages/swiftclient/version.py", line 15, in <module>
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'
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: 9bdb89f740/changelogs/CHANGELOG-v2.6.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: 0623dedf2d/changelogs/CHANGELOG-v2.7.rst (v2-7-15)
tigervnc ships vncserver, quote from the documentation:
vncserver - a wrapper script which makes starting Xvnc more convenient vncserver requires Perl.
This override to the old 1.x version of `prompt_toolkit` appears to be
unnecessary; removing it does not change the hash of `awscli`.
In a follow-up, we could likely remove the RSA override as well, if we're OK
with patching out the `setup.cfg` requirements. This dropped support for some
old modules, but appears to not break API compatibility otherwise:
https://github.com/sybrenstuvel/python-rsa/blob/master/CHANGELOG.md#version-40---released-2018-09-16
