Hacker News Reader

I was the one who reported this originally in 2020. Christian said it wasn't a vulnerability because it was intended that people who used standard library functions should validate user input. A day later I get another email saying that a CVE had been assigned, and that it was now suddenly a vulnerability.

I wait a few months, follow up and nothing. Pretty much dropped it for 2 years and now I see that they finally fixed it and never let me know. I asked a few days ago whether I'd be credited in the CVE, still no reply...

Why do I feel as if there are serious communication issues here?

Maybe it is not in their code of conduct to let you know or reply in a timely manner.

Because there are.

Digging through our history, a person who reported the same thing earlier than you never got a response at all. Like I said, we've identified organizational issues to be addressed.

(I honestly don't know who should be "credited" on the CVE nor do I have control over that, sorry)

Yep, that's how orgs work. Any org older than a certain number of years must delete itself and allow others to form another entity - or else it will amass warm bodies that collect titles and dont do anything useful. Unfortunately orgs will do everything to continue to exist, despite becoming irrelevant, inefficient, and losing their merit.

Code of conduct is apart of this, it is designed to prevent strong dissenting opinion by claiming its offensive/improper. You cannot call out the true bad actors, because culturally we view offense as wrong and authority to be correct. COC is basically an HR document, it's to protect the org, not to do the right thing. History repeats itself.

Linking the Code of Conduct instead actually pointing out anything specific ist such a shitty approach to this. We're used to this kind of ToS-pointing from SV tech corportations but it's sad that it seems to be getting more common in open source communities too.

> Why would anyone want to participate in a community this toxic?

gpshead is Google:

https://github.com/gpshead

thats all you need to know. Google makes some great stuff (Go language), but their community has plenty of arrogant members that have no concept or interest in nuanced discussions.

I think you mean a googler. He isn't Google.

sorry, I don't use made up words.

All words are made up.

"Google", which you used, is a "made-up word".

You mean, a guy who works at Google; for a second, I thought you were implying that name was an acronym for Google Python Services or something like that.

I'm pretty sure the decision on how to address the bug (and the determination of even if it's a bug) was not done by one dev. Other devs were involved and the determination was made as a team to make the change. Having a better fix, e.g. something like what is suggested in #90716 is not precluded. As yet, no one has actually stepped up with a better int-to-str implementation. I.e. something that can be reviewed, tested and then maintained in the long term As discussed in #90716, there is not much point in trying to do something similar to what GMP does. People can just install that library and use it.

I'm not sure why people are so excited about this issue. It's not much different than sys.setrecursionlimit(). We know how to implement tail recursion. Python doesn't do it though and so there is a limit, set high enough that most people don't care. It seems a perfectly practical approach to me.

It's a breaking change in a patch release that fixes the "Security Vulnerability" that python is sometimes slow.

If you are writing a server in python, you should expect these sorts of "vulnerabilites" (ie performance problems) in exchange for the convenient abstractions that you get.

The vulnerability is int-ing untrusted inputs.

but it's not a vulnerability in the traditional sense. No information gets leaked, no invalid memory is accessed. It's just slow. If being slow is a vulnerability, all python code is a vulnerability.

This is a bad take. The operation is not slow as in "takes longer", but as in "effectively never finishes". (that's what taking minutes on a single request means) That makes it trivial to DoS a service if you know it's running on a standard python runtime. And availability related to untrusted input is very much a vulnerability in a traditional sense.

As traditional as it gets really: https://www.cvedetails.com/vulnerability-list/opdos-1/denial...

It also has a financial impact definitely something security people are interested in.

They set the limit at (on my computer) 0.1ms. Also, their implementation is roughly 100x slower than it should be. Should python also error out on loops that run for more than 1000 iterations? The problem isn't that int parsing is broken, the problem is that web-servers aren't validating their inputs.

It's different layers. You're in control of the loops, so no. (guess what though - recursion level is limited) You're not in control of the int() implementation, so that falls on python.

It's similar to what we've done with hash collisions - we can't count on everyone fixing that in every place released so far, so all languages added hash randomisation at startup. That one fortunately had no side effects like this one does.

> They set the limit at (on my computer) 0.1ms.

That seems reasonable to me. I'm not sure if you're saying it's too low or too high?

> the problem is that web-servers aren't validating their inputs.

And they won't. This would be repeated many times in various form affecting Web servers, job queues, parsers, etc. and keep coming back for decades. We already have that with Java XML entities. They weren't fixed at the source and we get a new implementation with that bug ever day.

"Trivial," you say?

I sanitize all my inputs while they are still strings, like we have been doing for thirty years in web apps.

Now explain how you can "trivially" DoS my service.

What do you mean by "all inputs"? Did you write your whole server from scratch? Did you verify the length of every single int that comes in your query? Fragment? Json? Header? Header part that may be parsed internally by python's standard libs? Chunk lengths? IP conversions? Every external library call? Variables that may turn numeric in future revisions? If that's true, how sure are you you haven't missed a single spot?

> like we have been doing for thirty years in web apps.

I have bad news for you. If everything you said is true, you've been working on some ideal code in a prefect team with no dependencies... But more likely you're going to have a bad collision with reality one day.

Also, your code, I believe? https://github.com/rec/gitz/blob/0c15c9e3d213c3556f38f6fbf63... (I know that's not a Web service, but couldn't find one. Still untrusted input. If you point me at one, I'll be happy to find another example.)

says the person posting in a fairly toxic manner

Could you point me to which part of my comment you found toxic? I thought I was careful to make sure it was only recounting facts, and the question I posed is genuine — as someone who used to contribute to Python (but hasn't worked with Python in a long time) I'd love to understand how things got to this point.

for what it's worth, I think you summarized the situation fairly accurately, but it's unclear what feeling you intend to convey with your comment other than to inflame readers emotionally

If you don't understand why I cited the code of conduct and redirected discussion to a more appropriate forum for constructive discussion, go read our code of conduct vs the language that was being directed at us and what being linked from this toxic site was about to bring.

There was no fighting. As soon as Mark piped up I was extremely pleased to see that he had found something that should've been obvious that we'd overlooked in the process of doing everything spread over time. Mark wasn't able to review the PR code before it was made public due to the current processes (lack of...) we're working to improve for the Python security response team.

"pedantically correct" was not intended to be read as passive aggressive. I use that term to mean exact vs almost when it comes to computations. I didn't need convincing. I wanted the reasoning to be made understandable to everyone else in the future (future selves included) who was going to read this code later. I still think there is room for better explanation of the math but that is true for large parts of Objects/longobject.c anyways.

I find your interpretation of events... amusing. :P

I went back and read the last comments before the CoC was invoked, and I read the CoC as well. Having done that, I don't understand which part of the CoC the comments were in violation of. Could you expand on why you think it was appropriate to shut the discussion down without even responding to those comments?