Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google broke a conditional statement that verifies passwords on Chrome OS

arstechnica.com

Post reply on HN
Print view View original

151–160 of 276 posts

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#151

Post by zarzavat »

kbelder wrote: post #132
JonathonW wrote: post #128

Earlier quoted context omitted.

If you're going for "each line of code should do exactly one thing", you'd probably prefer that as if(foo) { if(foo->bar) { //whatever } } separating out the null check and the actual conditional. More lines of code and more nesting, yes, but, if you're trying to strictly adhere to a one thing/one line principle, you probably don't care. Short-circuit 'or' is a little harder to avoid (if you specifically want the sho…

Yep, I'd prefer that option, despite its wordiness. Obviously this depends a lot on individual preferences, and in this simple example it really doesn't make a lot of difference. I imagine the compiler spits out pretty similar code either way. It's more just a recognition of my own limitations... I'm a lot less likely to screw up something up, the more explicitly it's written out. When I was a younger man, I wouldn't…

The problem with that code and the reason that it is often considered bad C++ practice is that it is very easy to accidentally move the inner conditional outside of the outer conditional, thus creating undefined behaviour.

Putting the null check in the same line as the usage means that it is much harder to separate them accidentally.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#152

Post by tialaramex »

anyfoo wrote: post #94
crazygringo wrote: post #90

Earlier quoted context omitted.

> in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they resolve to different types. That's not true at all. Whenever you're intending to compare equality, they're usually going to be the same type already unless you're being really slopping in a scripting language like JavaScript or PHP -- but even then they're usually two numbers, two strings, or tw…

No. It can help because the result of the expression would have a different type, one that "if" does not accept. If a and b are integers, then the expression "a = b" is an integer too, but "a == b" is a boolean. In a strongly typed language, you can assume that "if" only accepts booleans.

Yeah. The direction of modern languages has been away from features like this which are "clever" but don't express anything you couldn't have said by another means - and yet allow programmers to accidentally write something nobody would ever want.

Assignment shouldn't have a return type. Compound assignment operators? Likewise. You never need this return value, and sometimes you may use it by mistake. So, abolish it. In C++ not only do operators that shouldn't have a return value have one anyway, the type of that value might be anything. You can even overload both ++ operators to return different unrelated types so that

  mytype aThing { blah };
  auto a = aThing++;  // returns a String "Fuck tha police"
  auto b = ++aThing;  // returns a double, 8.63
The Jeff Goldblum GIF is often the appropriate reaction to C++ features:

"Your scientists were so preoccupied with whether or not they could, that they didn't stop to think if they should"

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#153

Post by vlovich123 »

ectopod wrote: post #97
vlovich123 wrote: post #85

Earlier quoted context omitted.

This isn’t extreme negligence of any single individual. If there are linters/compiler warnings that should have caught this, this is an organizational failure that can be remedied and the manager/TL should be taking a bit of a hit here as having those enabled is best practices. Since it’s ChromeOS I imagine there’s a dedicated team managing the build infra and it’s not using the base set of things that Google3 protec…

The GGGP is talking about failures at a higher level. Not reprimanding the coder who missed an ampersand, but the manager who was ultimately responsibly for ensuring there was a functioning process for catching this sort of nonsense.

In situations like these there's not really one manager, so who are you reprimanding? I'm sure there's failures all around. Seriously, blameless post mortems are a cultural thing you need to adopt. Reprimanding just instills fear which causes people to take actions that you don't want organizationally (shifting blame/responsibility, hiding issues, politicking etc). Better for people to just be proactive about when a problem exists & marshal your org to prevent such issues in the future. It's unlikely to be the cause of 1 individuals incompetence so any individual(s) you find to blame are just victims of circumstance.

Where you do want to reprimand is if the technical team was repeatedly raising concerns related to failures like this & their concerns weren't being addressed OR someone was being deceitful & hiding issues. That's about the only cases where you want to fire/replace anyone in my book.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#154

Post by dataflow »

MauranKilom wrote: post #138
anyfoo wrote: post #86

Earlier quoted context omitted.

Why would you even need non-shortcircuiting behavior in boolean expressions? Because either side of the operator has side effects that you want to happen unconditionally? Please just write it out as an extra statement then instead of hammering it into place with an implicit coercion to an integer type only so you can abuse bitwise AND and OR only to force that side effect to... you can see why this is probably not th…

What I would like to write in unit tests: for (auto x : y) ok &= check(x); That gets you angry messages from static analysis, so you probably have to write (since there is no corresponding assignment operator) for (auto x : y) ok = ok && check(x); ...except now you don't actually perform checks after the first failure. That may or may not be intentional (or even confusing - depending on logging). What you'd really ne…

> I really do wonder why the standard doesn't just specify the behavior of bool & bool.

Confused about your question. Did you have a typo? bool & bool is valid in C++.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#155

Post by usefulcat »

gavinray wrote: post #65
Trollmann wrote: post #26

Earlier quoted context omitted.

You can use `and` and its siblings instead of && and similar in C++11. Most people here, and in other boards, will try to convince you that it hurts readability because 'that‘s how we always did it' (read I‘m used to it and don‘t like change).

I was surprised to read that `and`, `and_eq`, `xor`, etc are all supported "secondary/alternative operators" Never seen them used, but I use them in my C++ code when I have to write it to accomplish something else: https://en.cppreference.com/w/cpp/language/operator_alternat...

I use them, some of them anyway. I find them to be more readable (in particular’not’ instead of ‘!’). Also it means that I can reserve ‘&&’ for rvalue references.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#156

Post by comex »

Macha wrote: post #143
jcelerier wrote: post #127

Earlier quoted context omitted.

Which of "Rust, Haskell (core Haskell), OCaml, and SML" is able to parametrize types on values, à la template ?

Rust 1.51+: https://blog.rust-lang.org/2021/03/25/Rust-1.51.0.html

In extremely limited form. That should change in the future, though.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#157

Post by SilasX »

anyfoo wrote: post #59
dylan604 wrote: post #28

Earlier quoted context omitted.

That so sounds like an error I would make and not some superDev working at the Googs making around 4x the amount of money I make.

Not sure why you think a "superDev" would be less susceptible to simple typos?

The superDev would be; the linters and test suite (that said devs should be enforcing and maintaining) shouldn’t be.

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#158

Post by zinekeller »

SahAssar wrote: post #22

Just reading the title it sounded very much like "Single Point of Failure: The (Fictional) Day Google Forgot To Check Passwords": https://www.youtube.com/watch?v=y4GB_NDU43Q

Fortunately (or not, depending if you have a Chromebook and store files locally there), the inverse has happened and it locked up your book (fail-deadly versus fail-safe).

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#159

Post by oceanswave »

inetknght wrote: post #105
gavinray wrote: post #65

Earlier quoted context omitted.

I was surprised to read that `and`, `and_eq`, `xor`, etc are all supported "secondary/alternative operators" Never seen them used, but I use them in my C++ code when I have to write it to accomplish something else: https://en.cppreference.com/w/cpp/language/operator_alternat...

I used to use them. Then I was burned by some Very Opinionated managers and coworkers who didn't like seeing new things. It wasn't a hill I was willing to die on; there's more important things to argue about in C++.

Development is a massive cargo cult

Re: Google broke a conditional statement that verifies passwords on Chrome OS

#160

Post by josefx »

anyfoo wrote: post #86
gpderetta wrote: post #73

Earlier quoted context omitted.

the problem is that bitwise & and | are routinely used for their non-shortcircuiting behaviour in boolean expressions, so it is hard for the compiler to flag this as an error. Many linters and static analysis tools do flag them though as these days it is not considered good practice.

Why would you even need non-shortcircuiting behavior in boolean expressions? Because either side of the operator has side effects that you want to happen unconditionally? Please just write it out as an extra statement then instead of hammering it into place with an implicit coercion to an integer type only so you can abuse bitwise AND and OR only to force that side effect to... you can see why this is probably not th…

Reduced unit test complexity? Short circuiting implies more branches, more branches means more tests for 100% coverage.

Of course for that to be a downside someone would have to write tests for security critical code, which obviously did not happen.

Post reply on HN