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. 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