Thanks for the replies everybody. A few thoughts.... >From Adrián:
> You should probably be addressing urllib devs with this inquiry (e.g. such vuln is then probably in many other web frameworks) I did that in 2021 when I found the issue with newlines in URLs. Python devs had the resources to fix the newlines but not to make urlparse spec/browser compliant. They had concerns about backwards compatibility (fair enough), and it seemed like they'd have to largely rewrite the library to do things properly b/c URLs are so nasty these days. I think they also felt like they couldn't keep up with the standard and that the language shouldn't try. Instead, they argued the usual thing: folks should use third party libraries that can be better and that can change more quickly (fair enough). Until Ada, I hadn't heard of better solutions, so I let it lay. >From Jorg: > the fact that django or an upstream lib decided to slightly deviate from the latest URL parsing spec incarnation does not make it vulnerable per se >From Adam: > On the contradictory standards, see the cURL maintainer’s post I agree, Jorg, and thanks for the cURL reference, Adam. Specs aren't my target so much as "what browsers do," and wherever our URL parser diverges from what browsers do, we risk a redirect vulnerability. It's been a few years since I worked on this issue, but IIRC, this particular spec is actually well aligned with what browsers do, so they're essentially one and the same. I understand the push back that we need proof of an issue here before we'd move forward with anything. WHATHG provides a test suite of nasty URLs <https://github.com/web-platform-tests/wpt/tree/master/url>. I guess what I should do is run that through urlparse and look for places where it fails. If, for example, it's possible to send a valid URL to urlparse and have it get the wrong (sub)domain name, we would consider that a vulnerability or at least an issue, right? ----- That's it for my substantive comments, but I want to reply to this too: > But then add something about their time being too valuable to work on making it better. I don't know C, so I can't help much with the Python language, but I am here, where I have more expertise. You'll note that I offered to assign a paid developer to adding Ada to Django if we wanted to. That's me being busy with other priorities, but offering resources from my org. If that's not good enough, I don't know what is. Also, I'm not denigrating Python by saying it's maintained by volunteers — in my experience, it is. The fact that Python doesn't have tons of resources is one of the reasons it was difficult to get this vulnerability fixed in the language itself. They did a minimal fix because a bigger one wasn't possible given the resources of those that work on the language (and concerns about backwards compat). Finally, you might also consider that I spent a lot of my time working on the vulnerability above, and that I contribute to other open source projects practically every day for the last decade. Point being: If you want to drive me away from contributing here, you're on your way, but I'm here trying to help, and I've got a record of doing so here and elsewhere in various ways. Sorry to others here for the off topic response. Though I probably should, I can't let that kind of comment go in the Django discussion group. Thank you all, Mike -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3f95d432-67ad-45bc-aec1-063e9b762ac7n%40googlegroups.com.
