Bump uvicorn to >=0.11.7

[weltonrodrigo]

Closes https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker/issues/85

I suppose it would be more maintainable to somehow have this dependencies managed by poetry and let dependabot deal with them.

Not sure how to do that for this (nice) build and test infrastructure you have here.

EDIT:

I understand that during build, the last version of uvicorn and gunicorn will be installed. The problem is that they obviously only get updated when the images are built. Which happens, I suppose, when you run the deploy workflow.

So, if you find a way to let dependabot control the versions, you will be able to accept a bump and keep them updated in a controlled way.

But NOTE: The CVE in the referenced issue (CVE-2020-7695 and CVE-2020-7694) are from July 2020. The last run of deploy action as 4 months ago, uvicorn 0.11.7 (which fixed them) was released also in July, so I'm not sure why it have not been updated.

By the way, just to be sure that the version on docker hub is vulnerable:

docker run --rm -ti --entrypoint uvicorn tiangolo/uvicorn-gunicorn-fastapi:python3.8 --version

python3.8: Pulling from tiangolo/uvicorn-gunicorn-fastapi
Digest: sha256:dc7ccd01872231254a04b82011180608a1f80d455674e1b302aa719b7c02065b
Status: Image is up to date for tiangolo/uvicorn-gunicorn-fastapi:python3.8
Running uvicorn 0.11.3 with CPython 3.8.2 on Linux

[Mazyod]

+1

Regarding the dependency, I believe using external dependency managers might also required multi-stage build to avoid bloating the final image with build dependencies.

[tiangolo]

Thanks for coming back and closing the issue 👍

Sorry for the long delay! 🙈 I wanted to personally address each issue/PR and they piled up through time, but now I'm checking each one in order.