The Ada programming language is cursed with overlapping acronyms. GPS, ADA, SPARK, AWS. Seems it just got a little bit worse.
At least the can_ada (canada!) makes it a little bit more unique.
Parsing URLs in Python
21–30 of 99 posts
Re: Parsing URLs in Python
#22Hard to imagine the tradeoff of using a third party binary library developed this year vs just using urllib.parse being worth it. Is this solving a real problem?
urlib.parse is a pain. We really need something more like pathlib.Path.
There is https://github.com/gruns/furl
Re: Parsing URLs in Python
#23Parsing an url is really a pain in the a*
Another post in this thread was downvoted and flagged (really?) for claiming that URL parsing isn't difficult. The linked article claims that "Parsing URLs correctly is surprisingly hard." As a software tester, I'm very willing to believe that, but I don't know that the article really made the case.
I did find a paper describing some vulnerabilities in popular URL parsing libraries, including urllib and urllib3. Blog post here:
https://claroty.com/team82/research/exploiting-url-parsing-c...
Paper here:
https://web-assets.claroty.com/exploiting-url-parsing-confus...
If you remember the Log4j vulnerability from a couple of years ago, that was an URL parsing bug.
Re: Parsing URLs in Python
#24Hard to imagine the tradeoff of using a third party binary library developed this year vs just using urllib.parse being worth it. Is this solving a real problem?
According to itself, it's solving the issue of parsing differentials vulnerabilities: urllib.parse is ad-hoc and pretty crummy, and the headliner function "urlparse" is literally the one you should not use under any circumstance: it follows RFC 1808 (maybe, anyway) which was deprecated by RFC 2396 25 years ago . The odds that any other parser uses the same broken semantics are basically nil.
It seems unlikely that this C++ library written by a solo dev is somehow more secure than the Python standard library would be for such a security-sensitive task.
Re: Parsing URLs in Python
#25[flagged]
> Parsing urls is not difficult at all I’d like to have 100 developers each write a url parser, and see how many bugs per implementation we can find. I’d guess an average in the double-digits
Maybe this is a case of "I could write curl in a weekend", proceeds to use libcurl one way or the other.
Re: Parsing URLs in Python
#26Earlier quoted context omitted.
urlib.parse is a pain. We really need something more like pathlib.Path.
There is https://github.com/gruns/furl
Re: Parsing URLs in Python
#27Earlier quoted context omitted.
According to itself, it's solving the issue of parsing differentials vulnerabilities: urllib.parse is ad-hoc and pretty crummy, and the headliner function "urlparse" is literally the one you should not use under any circumstance: it follows RFC 1808 (maybe, anyway) which was deprecated by RFC 2396 25 years ago . The odds that any other parser uses the same broken semantics are basically nil.
It seems unlikely that this C++ library written by a solo dev is somehow more secure than the Python standard library would be for such a security-sensitive task.
Not in the sense of differential vulnerabilities, since the standard library refuses to match any sort of modern standard.
It's also
1. not a solo dev
2. Daniel Lemire
3. a serious engineering and research effort: https://arxiv.org/pdf/2311.10533.pdf
Re: Parsing URLs in Python
#28Parsing an url is really a pain in the a*
Another post in this thread was downvoted and flagged (really?) for claiming that URL parsing isn't difficult. The linked article claims that "Parsing URLs correctly is surprisingly hard." As a software tester, I'm very willing to believe that, but I don't know that the article really made the case. I did find a paper describing some vulnerabilities in popular URL parsing libraries, including urllib and urllib3. Blog…
> If you remember the Log4j vulnerability from a couple of years ago, that was an URL parsing bug.
I don't think that's a fair description of the issue.
The log4j vulnerability was that it specifically added JNDI support (https://issues.apache.org/jira/browse/LOG4J2-313) to property substitution (https://logging.apache.org/log4j/2.x/manual/configuration.ht...), which it would apply on logged messages. So it was a pretty literal feature of log4j. log4j would just pass the URL to JNDI for resolution, and substitute the result.
Re: Parsing URLs in Python
#29Earlier quoted context omitted.
It seems unlikely that this C++ library written by a solo dev is somehow more secure than the Python standard library would be for such a security-sensitive task.
Not in the sense of differential vulnerabilities, since the standard library refuses to match any sort of modern standard. It's also 1. not a solo dev 2. Daniel Lemire 3. a serious engineering and research effort: https://arxiv.org/pdf/2311.10533.pdf
This is the commit history: https://github.com/TkTech/can_ada/commits/main/
I guess you are right that there are 2 commits from a different dev, so it is technically not a solo project. I still wouldn't ever use this in production code.
Re: Parsing URLs in Python
#30Okay so some googling found me that the "xn--" means the rest of the hostname will be unicode, but why does é become -fsa in www.xn--googl-fsa.com.
Google failed on the second part.