OpenAPITools / openapi-generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
https://openapi-generator.tech
Apache License 2.0
20.51k stars 6.27k forks source link

[BUG] [python] Python client expects vulnerable urllib3 #18993

Open dbold opened 1 week ago

dbold commented 1 week ago

Bug Report Checklist

Description

After #15810 the generated Python client expects urllib3 >= 1.25.3, < 2.1.0.

Except 1.26.19 all these urllib3 have some security vulnerability: https://security.snyk.io/package/pip/urllib3

openapi-generator version

7.5.0

OpenAPI declaration file content or url

N/A

Generation Details

java -jar openapi-generator-cli-7.5.0.jar generate -i .../some/swagger/service.yaml -g python

Steps to reproduce

Generate a Python client.

Related issues/PRs

15810

Suggest a fix
wing328 commented 3 days ago

After https://github.com/OpenAPITools/openapi-generator/pull/15810 the generated Python client expects urllib3 >= 1.25.3, < 2.1.0.

may i know if you've time to contribute a PR to update that?

a good starting point is https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/python/requirements.mustache#L3

dbold commented 3 days ago

Procedurally, I would start by doing something else: include generated Python client in the codebase, probably under samples/client/others.

I see there's a few other clients there but not all the officially supported clients.

This would have the project take ownership not only of the project code but of the (quality of the) generated code too. And more to the point, you would get dependabot security issues on generated code too.

Indeed, I can make a PR to change the urllib3 dependency to the only known safe version, 1.26.19 but I think what I talked above is even more important. You need a feedback loop around generated clients too.

wing328 commented 3 days ago

we do have dependabot turned on, e.g. https://github.com/OpenAPITools/openapi-generator/pull/18989

in your repo hosting the auto-generated Python client, did you get the alert?

dbold commented 2 days ago

Interesting, I see you do have the client part of the codebase in samples/openapi3/client/petstore/python .

So, it's quite surprising you have no dependabot security issue for that folder. I wonder if it happens because pyproject.toml has urllib3 = ">= 1.25.3" while requirements.txt has urllib3 >= 1.25.3, < 2.1.0 ?

By a stroke of luck, there exists a single version with no security issues, 1.26.19, according to https://security.snyk.io/package/pip/urllib3 . I would be very surprised if Dependabot honed in on that.

in your repo hosting the auto-generated Python client, did you get the alert?

In my case I'm using --additional-properties=generateSourceCodeOnly=true ie. I'm including the client in my existing project. Since I was already using urllib3 I had just bumped it to 2.2.2 due to the previous security notices.

So I now have to downgrade it to use the generated openapi Python client.

But as soon as 1.26.19 gets a security problem, there will be no secure version to use. This makes the openapi generator a tough sell.

dbold commented 2 days ago

OK, the interesting thing seems to be dependabot will not report security issues if you have a range of versions. It only opens a security issue if you have a pinned version.

I've copied the openapi-generator python client to this project https://github.com/dbold/test-openapi-generator , renamed requirements.txt to requirements.in then did a pip freeze >requirements.txt which settled on urllib3==2.0.7.

As soon as I have an exact version, dependabot opened a security issue for the openapi Python client:

dependabot-openapi-python