Live data from Hacker News

Google broke a conditional statement that verifies passwords on Chrome OS

arstechnica.com

101–110 of 276 posts

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

#101
post #74
post #17

From the article: > The line should read "if (key_data_.has_value() && !key_data_->label().empty()) {" but instead of "&&"—the C++ version of the "AND" operator—the bad update used a single ampersand, breaking the second half of the conditional statement. Someone correct me if I'm wrong, but this seems like it wouldn't be possible in a language that didn't conflate boolean values with bitvectors. Edit: I was wrong[1]…

Other than this particular edge case it's not obvious to me why bitwise operators shouldn't be applicable to boolean values. Aren't they just single-bit vectors? Of course it makes sense that logical operators wouldn't be applicable to numeric types, but why the reverse?

If you stop integer values from being implicitly convertible to booleans, you break the language and its compatibility with C.

The inverse is debatable, though. I honestly don't see why someone would do bitwise operations on boolean, unless they really wish to die a slow death from thousand cuts. Integer promotion rules make even the simplest operations a wild mess, and there's nothing in the standard that prevents bool from having a sizeof equal to int (thus further complicating everything).

It might be sensible for newer language revisions to consider deprecating certain operators from being applied to bool, given that there is a strong change that 99% of the time their use is not on purpose, but I guess it depends on how much disruptive such change would turn out to be.

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

#102
post #30

Earlier quoted context omitted.

I am also of the opinion that `and` is more readable than `&&` (and isn't as easy to typo in a catastrophic way) - although my main point was about the weaker type system.

C++ definitely hasn't a weaker type system than "newer" languages like Java - if any, it is much more richer and complex than most languages out there. What's happening here is a type conversion that has to be in place due to C not having a boolean type until 1999. C++ attempts to construct a boolean from the argument of an `if()`, and given that bool can be constructed from int, the conversion succeedes. You can def…

"Not as weak as Java" is not a very interesting benchmark, as Java also has a poor type system. C++'s type system is pitiable relative to those of Rust, Haskell, OCaml, and SML.

Moreover, in addition to being less expressive than them, C++'s type system is also weak, in formal sense, by allowing many implicit type conversions - which is one of the issues that I was complaining about. The fact that it "has to be in place due to C not having a boolean type until 1999" doesn't make it any less weak.

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

#103
post #8

I bet the post-mortem for this is going to be fun. How this wasn't covered by multiple unit tests, a code review and a roll out strategy is.... impressive.

i've never worked on a project (even TDD) that did that level of testing detail.

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

#105

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

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

#108
post #74

Earlier quoted context omitted.

Other than this particular edge case it's not obvious to me why bitwise operators shouldn't be applicable to boolean values. Aren't they just single-bit vectors? Of course it makes sense that logical operators wouldn't be applicable to numeric types, but why the reverse?

If you stop integer values from being implicitly convertible to booleans, you break the language and its compatibility with C. The inverse is debatable, though. I honestly don't see why someone would do bitwise operations on boolean, unless they really wish to die a slow death from thousand cuts. Integer promotion rules make even the simplest operations a wild mess, and there's nothing in the standard that prevents b…

I don't think the other poster was imagining a language that retained compatibility with C, but rather a new language altogether. Of course it would be impossible to change this aspect of the language if retaining compatibility with C was a requirement.

> I honestly don't see why someone would do bitwise operations on boolean

For example, you might want the behaviour shown here of not short-circuiting. Or you might want to create a bitwise function that also allows calling on single-bit (i.e. boolean) values.

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

#109

Umm... no automated tests? Junior engineers responsible for security of half of the world without proper code review?

Half of the world? We're talking primarily north-american school kids.

https://trends.google.com/trends/explore?q=chromebook

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

#110
post #51

This is clearly a typo that happened to stomp some logic that is not covered by a test. The review 3002282 includes the bug, which deletes one of the & from a && operator. It says it was cherry-picked from review 2994464, which does not change that line. So, slip of the backspace key plus poor testing.

Yeah, the biggest thing to me here is that there's no "login succeeded" unit test, integration test, manual test, etc. Whatever customer logged in first was the first person to actually run the code.
Post reply on HN