Hacker News Reader

Comment by 0xFEE1DEAD | Hacker News Reader

> I fail to see how this is a bug if you feed it garbage

What an awful response to someone reporting a pretty serious security vulnerability.

"Pretty serious" is a major overstatement. Regardless if you want to report a security bug you should include the impact.

If you've never been on the other end of this - the number of false security reports with minimal details popular open source projects get are staggering. Many are unrealistic. People saying things like, if i give the attacker my password then the attacker has my password.

> Regardless if you want to report a security bug you should include the impact.

Assigning impact, even only as a measure of risk, is not the responsibility of the reporter.

A reporter must provide a fair description and a proof of concept. Calculating impact involves much more than that.

I would disagree that it is a fair description without some description of impact.

Hell, without impact, its not even a normal bug, let alone a security bug. The fundamentals of a bug report are "I expect X to happen when I do Y, but instead Z happens". Without impact, all you are saying is "I expect X to happen".

"Impact" is much more than just what happens when a vulnerability is exploited in a vacuum. That is the reason behind CVSS scores and incident response.

Sure, there are different levels of explaining "impact" and the reporter isn't responsible for being the final authority. They should have some idea though as to what the bad thing you can do with the bug is. (However, cvss scores are basically garbage)

Then they proceed to explain why, but why in the world would you return true if the underlying function calls failed???

That if you don’t meet the documented preconditions to calling a function you can’t assume the output is valid?

That seems fine to me, not every programming language has to be defensive about bad inputs, lord knows C isn’t. It seems like he got caught between two conflicting pieces of documentation one having stronger guarantees.

PHP has a lot of C-isms under the hood, not only in its infamous function names but also in how they signal errors in-band in the old functions. crypt() is one of those old functions with a crappy API, and password_verify() is just a thin wrapper around it. Maybe this explains the "it's undefined, so we can do whatever" attitude.

Reply on news.ycombinator.com