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

191–200 of 276 posts

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

#191

Post by Cthulhu_ »

gene91 wrote: post #92
gmfawcett wrote: post #48

Earlier quoted context omitted.

This is one of those times when, for all its verbosity, Ada got it right. For boolean conjunction you must choose between writing "A and B", or "A and then B". The "and then" version is short circuiting, while the bare "and" version is not.

This is a typo of missing an ampersand. If the author were writing Ada, it would have been a typo of missing a “then”. How is it different?

It's different because in C it changes a boolean comparison to a bitwise one. Is Ada's `and` a bitwise and?

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

#192

Post by GoblinSlayer »

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…

When you check for error conditions shortcircuiting is unlikely and thus useless.

if(error1|error2)abort();

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

#193

Post by Cthulhu_ »

wyager wrote: post #55
fouric wrote: 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]…

The most general solution here is to use algebraic types and pattern match on the value being “None” or “Some data”.

It's not, because that would involve re-engineering and re-writing millions of lines of code.

The simpler solution is to fix this gap in their automated testing. Another one is to configure a linter to error on bitwise operations on boolean values.

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

#194

Post by meowface »

nogridbag wrote: post #29
sneak wrote: post #10

Earlier quoted context omitted.

Bitwise & versus logical && is a classic, right up there with an assignment in a comparison (when an equality check is intended), = for ==. That this was missed is pretty surprising, given that it's Google and the stakes involved in the encryption/key management code in a secure platform device. I wonder if we'll even get a postmortem, as this simply cannot happen unless several someones all Seriously Fucked Up simul…

I've seen the = instead of == in the wild with disastrous results: the assignment was on an ORM backed object, e.g. // accidentally mutates all names to Sam and persists to the DB myList.filter { myDomainObj.name = 'Sam' } But it makes me wonder why our programming languages would use characters which can often lead to this type of error.

>But it makes me wonder why our programming languages would use characters which can often lead to this type of error.

Guido van Rossum wondered the same, which is why it isn't possible in Python. Same for "&&" vs. "&", since in Python it's "and" vs. "&".

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

#195

Post by utf_8x »

zinekeller wrote: post #158
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).

> fail-deadly versus fail-safe

Speaking of... https://www.youtube.com/watch?v=TUKQfMFKfjk

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

#196

Post by TeMPOraL »

geofft wrote: post #170
yongjik wrote: post #162

Earlier quoted context omitted.

> that‘s how we always did it ... which, frankly, is a very good reason. Don't needlessly change something people are used to. Why is the blinker control on the left side and the wiper control on the right side? Because that's what people expect.

On the other hand, if it were actually the case that people kept turning on the wipers instead of signaling their turns, it would be a sign that we should figure out how to make these two different operations not use symmetrical levers, and that it would be okay to change people's expectations because those expectations weren't very firm. In aircraft, where it matters a whole lot more that you don't confuse the vario…

Wish it was consistent, though.

'josefx is right in saying[0] these are still primarily hacks around encoding issues.

  | meaning | what is | what should have been |
  |---------+---------+-----------------------|
  | &&      | and     | and                   |
  | &=      | and_eq  | bitand_eq             |
  | &       | bitand  | bitand                |
  | |       | bitor   | bitor                 |
  | ~       | compl   | bitcompl              |
  | !       | not     | not                   |
  | !=      | not_eq  | not_eq                |
  | ||      | or      | or                    |
  | |=      | or_eq   | bitor_eq              |
  | ^       | xor     | bitxor                |
  | ^=      | xor_eq  | bitxor_eq             |
--

[0] - https://news.ycombinator.com/item?id=27928276

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

#197

Post by adrianN »

fouric wrote: post #102
qalmakka wrote: post #99

Earlier quoted context omitted.

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 p…

The type system in C++ is pretty strong actually, it just has too many implicit conversions. It's not like the compiler doesn't know that this value is not a bool.

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

#198

Post by meowface »

anyfoo wrote: post #120
hashingroll wrote: post #115

Earlier quoted context omitted.

The argument for tabs really goes that time is spent much more on reading code than authoring, so it should be optimized and customizable (tab width) for the reader.

Tabs for indentation, spaces for alignment.

I've settled on "follow the existing/upstream project's style; if it's a new project, follow the language's idiomatic style". I personally (strongly) prefer spaces over tabs, but I've inherited/forked plenty of projects that use tabs in JavaScript for example, and I just set my editor and formatter to use tabs in that project.

I think the ideal situation is a language with an official or at least commonly accepted formatter, so that existing and new projects will essentially always follow the same style and you never have to think about it. Like "go fmt" always using tabs. I don't like tabs, but I like that kind of enforced consistency way more than I dislike tabs.

That's also why I like using opinionated third-party formatters like prettier and black. Combined with pre-commit hooks, you almost never have to think about style and can just focus on the code. Plus diffs are cleaner.

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

#199

Post by exikyut »

kps wrote: post #71
sneak wrote: post #10

Earlier quoted context omitted.

Bitwise & versus logical && is a classic, right up there with an assignment in a comparison (when an equality check is intended), = for ==. That this was missed is pretty surprising, given that it's Google and the stakes involved in the encryption/key management code in a secure platform device. I wonder if we'll even get a postmortem, as this simply cannot happen unless several someones all Seriously Fucked Up simul…

I'm quite surprised there isn't a compiler warning for a bitwise operator at the root of a condition. I've been writing `if ((flags & FLAG) != 0)` for decades years for nothing?!?

Hmm. In all seriousness, you could probably build a lint rule/tool to allow only the format you note.

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

#200

Post by maweki »

black_puppydog wrote: post #61

That's not "bricking" as the title suggests. Sorry, word police incoming. :P

If there is such a process as unbricking, then the title is right. If becoming a brick is irrecoverable, then you are right.

If you can't log into a device, it is a paperweight.

Post reply on HN