Terri Cain

So when I run the S3 tests locally without the changes, I get the same number failed as with the changes, so I don't think they're related :)

Yeah it looks like moto is unhappy for some reason. I ran the server standalone and pointed the tests at it and they seem to be getting 404'd at least...

Yeah the coverage isnt going to be great as we can't test this unless moto runs with TLS. We could make that would though I think that should be done...

This hasn't been touched for over a year, is there anything of value we want to incorperate from this pr?

Not come across it yet, yeah it'll probably end up in overriding lots more stuff :(

ty lol. Not a clue, got given it by a previous company :D

https://github.com/boto/botocore/blob/e720eefba94963f373b3ff7c888a89bea06cd4a1/botocore/auth.py#L886 From the looks of it, `SigV4Auth` is subclassed by `S3SigV4Auth` which calls `_modify_request_before_signing` which then calls the superclass's `_modify_request_before_signing` which calls `self.credentials.token`. I saw a github issue somewhere saying...

Looking a bit more into this before I sleep. https://github.com/aio-libs/aiobotocore/blob/master/aiobotocore/signers.py#L70 - We'll probably need to hijack `AUTH_TYPE_MAPS` and substitute our own async variants then asyncify https://github.com/aio-libs/aiobotocore/blob/master/aiobotocore/signers.py#L63 Then in the signers,...

Ok from what I can see. The only place `SigV4Auth` is instantiated is in the `AUTH_TYPE_MAPS` dict in `auth.py`, and the only place it's values are accessed would be in...

Not using much brain power here but couldn't we run a travis test that installs `aiobotocore[boto3]` then run pipdeptree (or similar) and see if its exits 0?