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.
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.
* append appropriate urls when scaffolding
* make dispatch for rest-api
* fix dispatch for rest-json
* fix moto/core/response to obtain path and body parameters
* small fixes
* remove unused import
* fix get_int_param
* Add features of things and thing-types
* fix scaffold
* basic crud of cert
* support basic CRUD of policy
* refactor
* fix formatting of scaffold
* support principal_pocicy
* support thing_principal
* update readme
* escape service to handle service w/ hyphen like iot-data
* escape service w/ hyphen
* fix regexp to extract region from url
* escape service
* Implement basic iota-data feature
* iot-data shadow delta
* update readme
* remove unused import
* remove comment
* fix syntax
* specify region when creating boto3 client for test
* use uuid for seed of generating cert id
* specify region_name to iotdata client in test
* specify region to boto3 client in moto response
* excude iot and iotdata tests on server mode
* fix handling of thingTypeName in describe-thing
* test if server is up for iot
Boto and Boto3 can be a little old but Moto will throw an error if
botocoe doesn't even know about some of the services it supports.
As of this commit Polly is new enough some users are running into
exceptions.
* X-Ray Client SDK patched
Fixes#1250
* Fixed flake8
* Fixed some issues
* Fixed flake8
* Fixed more typos
* Fixed python2 string
* Fixed aws-sdk patch order
* Added more test cases to test the patching
