Given how moto is intended to be used, and how it uses Jinja2, [CVE-2019-10906](https://nvd.nist.gov/vuln/detail/CVE-2019-10906) is unlikely to affect many users, but we should use a secure version anyway just in case moto is being used in unforeseen ways.
As of #1733, Python 3.7 is supported, so reflect that in the Trove
classifiers.
As of 2017-09-29, Python 3.3 is end-of-life and no longer receives
updates of any kind (including security fixes), so remove it from the
list of supported versions.
Include the readme as the `long_description` argument to `setup` and set
its content type appropriately. This allows PyPI to render the content
correctly.
Discovered using pipenv's security check feature that there's a vulnerability in the cryptography package versions<2.3.
> Checking installed package safety...
36351: cryptography >=1.9.0,<2.3 resolved (2.2.2 installed)!
python-cryptography versions >=1.9.0 and <2.3 did not enforce a minimum tag length for finalize_with_tag API. If a user did not validate the input length prior to passing it to finalize_with_tag an attacker could craft an invalid payload with a shortened tag (e.g. 1 byte) such that they would have a 1 in 256 chance of passing the MAC check. GCM tag forgeries can cause key leakage.
More details here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10903
botocore v1.11.0 changed it's internal implementation so that it now
uses a different library for HTTP requests. This means that moto's
mocking will not work, and test code will inadvertently call the live
AWS service.
As an interim solution to reduce the impact of this breakage, we
restrict the "required" (ie. recommended) version of botocore so that
users will be less likely to use an incompatible version, and will
receive a pip warning when they do.
* Added Filtering support for S3 lifecycle
Also added `ExpiredObjectDeleteMarker`.
closes#1533closes#1479
* Result set no longer contains "Prefix" if "Filter" is set.
In commit 4157abe8de, the Jinja2
dep in setup.py was changed from being unpinned to requiring version
2.8 or newer. That change was made in response to this issue:
https://github.com/spulec/moto/issues/728
which pointed out that the use of 'lstrip_blocks' needed to
be supported. Support for that option was added in Jinja 2.7,
so it seems like the best option here, unless 2.8 is truly
required by moto, would be to allow Jinja 2.7.3 and newer --
preventing dep resolution conflicts in Python projects that pin
Jinja2 2.7.3 but also need to use moto.
