-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updating dependency requests to 2.32.2 will fail with Not supported URL scheme http+unix #1182
Comments
Thank you very much! Had the same issue and could not find the reason. Downgrading the requests solved it for now. |
Thanks for bringing this to our attention. The Unfortunately, In the meantime (and in general) I would recommend sticking with a specific version of requests and urllib3 that has worked for you prior - this is not the first time such updates have caused breakage, and it likely won't be the last. |
@cartertinney : I think it is reasonable to see this as not only an external bug, but also a problem with this projects requirements specification. In setup.py it is specified: "requests>=2.20.0,<3.0.0",
"requests-unixsocket>=0.1.5,<1.0.0", which means that this should install cleanly in any environment which satisfy these limits. It is of course impossible to actually guarantee that you can handle all combinations, but its reasonable to expect the dependency requirements to at least be correct for the latest versions you specify for all dependencies. And the fact is that So to sum up; I think you should also change the |
I agree, like I said, above:
I'm hesitant to come out and immediately restrict the version because the update to requests in question is a security fix - if we restrict our version in the long term, we're rejecting this security update as well as any future ones. If it comes down to it we will (at least in the short term), but that's not an ideal outcome either. |
There's an issue in the request-unixsocket repo for this issue: msabramo/requests-unixsocket#73 Since the project is abandoned an user forked the project with a fix. Would it be possible to either use that fork or for this SDK to have its own fork? The project is abandoned anyway so it shouldn't matter if the fork doesn't receive any updates other than critical bugs like this one Edit: just noticed it's your issue @cartertinney. The comment still applies |
It's something we're considering, certainly, although it's not trivial for us to simply switch to the other fork, as we would need to do a security analysis, etc. We're discussing our options right now, and will make some decisions on how to proceed in the coming days. |
I understand why just switching to the other fork could have security issues, that's why I suggested doing a separate fork just for this SDK and only fix critical bugs there. I'll certainly wait for any updates in the next few days, thanks for the info! |
Update: we will be simply restricting the A release will be made including these changes as soon as possible. |
|
Context
Package Version
annotated-types 0.7.0
azure-iot-device 2.13.0
certifi 2024.2.2
charset-normalizer 3.3.2
deprecation 2.1.0
idna 3.7
janus 1.0.0
packaging 24.0
paho-mqtt 1.6.1
pip 24.0
pydantic 2.7.1
pydantic_core 2.18.2
PySocks 1.7.1
requests 2.32.2
requests-unixsocket 0.3.0
typing_extensions 4.11.0
urllib3 1.26.18
Description of the issue
Today we updated the dependencies on a test iot edge module and saw that the module no longer could connect to the edgeHub using IoTHubModuleClient.create_from_edge_environment().
After some testing to check which changes were made, it seems to boil down to the requests package which has been updated May 20, 2024 to 2.32.0 with some subsequent updates to 2.32.2 today. But this latest fix still results in the same issue.
Explicitly downgrading to 2.31.0 fixes the issue for now.
Code sample exhibiting the issue
I retested it with the sample code from https://github.com/Azure/azure-iot-sdk-python/blob/main/samples/async-edge-scenarios/invoke_method_on_module.py with same issue.
Console log of the issue
The text was updated successfully, but these errors were encountered: