Upgrade grpcio to 1.60.0 to fix CVE-2023-1428 #174
Conversation
| @@ -80,7 +80,7 @@ def build_extension(self, ext): | |||
| extras_require["functions"] = sorted( | |||
| { | |||
| "protobuf>=3.6.1,<=3.20.3", | |||
| "grpcio>=1.8.2", | |||
| "grpcio>=1.60.0", | |||
There was a problem hiding this comment.
| "grpcio>=1.60.0", | |
| "grpcio>=1.53.0", |
Why not use 1.53.0, the minimum viable version?
There was a problem hiding this comment.
IMO, when upgrading a dependency, it's better to use the latest version at that moment if it does not break the compatibility. Though this repo does not check the compatibility.
There was a problem hiding this comment.
This is the dependency requirement instead of the specific dependency version. It's not like the dependency version control like in maven pom. I think maybe a good practice is to upgrade the requirement to the minimum viable version. What do you think of this point?
There was a problem hiding this comment.
If it's compatible to install, the version will be minimum required version. I tested it locally and verified 1.60.0 could be installed with other dependencies.
There was a problem hiding this comment.
I added a workflow to verify the installation in CI. It's not like Maven because sometimes the Python wheel uses the underlying C extension (like the Pulsar Python C++ client) and a specific version of dependency A might not be compatible with dependency B due to the symbols conflict or something else.
However, if all dependencies are compatible, using the latest version is good. Here we use grpcio>=1.60.0 means in future if another dependency breaks the compatibility with grpc==1.60.0, there will be a chance to install a higher version of grpcio.
There was a problem hiding this comment.
What if users introduce another dependency compatible with grpcio 1.53.0 but not with 1.60? Maybe that dependency depends on a behavior supported in 1.53.0 but not 1.60.0? When installing the Python client, the pip will upgrade the existing grpcio to 1.60.0, which may conflict with other dependencies.
I didn't find any breaking changes from grpcio 1.53.0 to 1.60.0. So I'm OK with this PR. However, I would like to discuss the best practice for the dependency requirements.
There was a problem hiding this comment.
What if users introduce another dependency compatible with grpcio 1.53.0 but not with 1.60?
Another question: what if users introduced another dependency compatible with grpcio 1.60 but not with 1.53.0?
There is no best practice. But in general, a new release should be better than an older one.
There was a problem hiding this comment.
When installing the Python client, the pip will upgrade the existing grpcio to 1.60.0, which may conflict with other dependencies.
However, you assume the existing grpcio version is in [1.53, 1.60). If the grpcio version is less than 1.53, there will be no difference.
There was a problem hiding this comment.
Another question: what if users introduced another dependency compatible with grpcio 1.60 but not with 1.53.0?
That should be a common case. Support we use grpcio>=1.53.0, then that another dependency should define the requirements with grpcio>=1.60.0. The pip will upgrade the grpcio to 1.60, and everything should be fine.
However, you assume the existing grpcio version is in [1.53, 1.60). If the grpcio version is less than 1.53, there will be no difference.
Why? I am assuming the grpcio version <1.60.
Suppose we have another dependency A that requires grpcio version in [1.40,1.55].
If the existing grpcio version < 1.53(Let's suppose it as 1.40) :
- If we use
grpcio>=1.53.0, the pip will upgrade the grpcio to 1.53.0. All works fine. - If we use
grpcio>=1.60.0, the pip will uggrade the grpcio to 1.60.0. The dependency A isn't compatible with this.
See https://nvd.nist.gov/vuln/detail/CVE-2023-1428