Open disconnect3d opened 5 years ago
PR #5135 I feel as though the call to the socket library is actually unnecessary here.
Ping @kennethreitz @Lukasa @sigmavirus24 @nateprewitt @slingamn can we finally get some love here and get this fixed?
This could probably also be marked as a security issue since if someone uses this in a security relevant context, they can get in trouble. (Although I doubt and hope that nobody does use those functions in such a way).
These are not intended for use by others. The fact the language has no way of making things as private or internal means that we can't stop people from giving a function not intended for public use garbage or getting garbage out
Also, @disconnect3d rather than demand free labor of others, you're welcome to submit a fix for this
These are not intended for use by others. The fact the language has no way of making things as private or internal means that we can't stop people from giving a function not intended for public use garbage or getting garbage out
The typical way to mark this is to prefix the name with underscore or two ;).
Yeah and people still use it from this library so we stopped bothering. I've been maintaining this library for almost a decade now. Writing python for longer. I know what the convention is and I know people don't care
Is there an argument against using socket.inet_pton
instead of socket.inet_aton
? It seems like socket.inet_pton
has had its implementation fixed to not accept the extra strings and could solve this whole problem? If there's historical reason to not use it in these contexts, that's fine, but it seems like a simple fix (I'd be more than willing to submit something for review for it) if not.
PR #6675
@disconnect3d , the socket
implementation was replaced by ipaddress
, fixing the bugs
Thanks! :)
On Thu, 28 Mar 2024 at 02:33, Vítor Capparelli @.***> wrote:
PR #6675 https://github.com/psf/requests/pull/6675 @disconnect3d https://github.com/disconnect3d , the socket implementation was replaced by ipaddress, fixing the bugs
— Reply to this email directly, view it on GitHub https://github.com/psf/requests/issues/5131#issuecomment-2024242564, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACMLWCTYXD6D26KQNEHTDGDY2NXPTAVCNFSM4H5MK2VKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBSGQZDIMRVGY2A . You are receiving this because you were mentioned.Message ID: @.***>
TLDR: On some libc implementations (e.g. glibc) the
socket.inet_aton
function parses IP strings trailed with whitespace and garbage, and this function is used by requests utility functions which if used externally, may cause bugs or/and security vulnerabilities.An example of the issue can be seen below:
I have written a more detailed description of the
socket.inet_aton
's underlying problem on Python's bugtracker issue 37495. It is yet to be decided if this is going to be fixed in Python.Expected Result
The
requests.utils
functionsaddress_in_network
,is_ipv4_address
andis_valid_cidr
should fail with invalid input.Actual Result
Incorrect IP strings do not return an error and instead return as if the trailing garbage did not exist in the IP string.
Reproduction Steps
System Information
The issue is related to libc implementation and has been tested on glibc 2.27 and 2.29.
It also occurs on MacOS which I am not sure if it is based on glibc.