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

141–150 of 276 posts

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

#141

Post by khazhoux »

sneak wrote: post #10
Traster wrote: 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.

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…

> this simply cannot happen unless several someones all Seriously Fucked Up simultaneously.

This is exactly how any and every bug enters a mature software product: it slips past multiple layers.

> This is a massive, overlapping fuckup. Heads should probably roll here

Some process should change, to fix the problem. But firing people is not necessarily the best solution.

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

#142

Post by shirro »

Traster wrote: 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.

This isn't the failure of an individual. It is a failure of management.

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

#143

Post by Macha »

jcelerier wrote: post #127
fouric wrote: post #102

Earlier quoted context omitted.

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

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

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

#144

Post by baud147258 »

sellyme wrote: post #140
lmilcin wrote: post #100

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

>security of half the world Chrome OS has less than 2% market share.

I heard elsewhere that its market share is closer to 10% (and that it's now the second most popular desktop OS). 2% would be considering mobile OS too, I think

https://www.maketecheasier.com/chrome-os-tops-macos-2nd-most...

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

#146

Post by Macha »

edflsafoiewq wrote: post #67
tmp_anon_22 wrote: post #46

Earlier quoted context omitted.

> type of error even being possible I mean its still possible to forget the ":" character and its still possible to mentally scan a PR and see "=" and miss that it should have been a "==".

= vs == isn't possible in Go because of the statement/expression distinction. The benefits of allowing assignment to be an expression are too small compared to the problems it causes. x == 1 // oops, meant = // x == 1 evaluated but not used if x = 1 { ... } // oops, meant == // syntax error: assignment x = 1 used as value

Python had similar, then introduced := for explicit assignment-as-expression. The debate over that one is considered a contributing factor to Guido's retirement as bdfl

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

#147

Post by anyfoo »

bobbylarrybobby wrote: post #129
anyfoo wrote: post #50

Earlier quoted context omitted.

The problem is not even with "easy to mix up operators" for this, it's about languages without a strong and static enough type system. While the particular problem Google hit is a bit more subtle (involving undefined behavior), in the majority of cases a strongly typed language would not allow expressions that accidentally mix up = and ==, as they often resolve to different types. In C "if (foo = bar)" and "if (foo =…

In many languages, such as python, assignments are statements, not expressions, and so they don’t evaluate to anything at all.

Yeah, I covered that at the end.

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

#148

Post by SquareWheel »

dang wrote: post #12
contravariant wrote: post #6

Wait so are the devices bricked or not? The title says bricked but as far as I can tell people just can't log in temporarily until the fix is rolled out.

Ok, we've done our bit to counter brick dilution in the title above.

Appreciated. Bricked used to mean utterly irreparable. The term certainly has seen dilution, and not for the better.

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

#149

Post by Macha »

galangalalgol wrote: post #60
sneak wrote: post #32

Earlier quoted context omitted.

If you consider a linter part of a programming language, most, when properly configured, do not permit this. It's just the syntax that does; professionals do not rely on syntax validity alone but employ linting, code review, static analysis, and integrations tests on top. The gradient of professionalism in our industry is very wide, and the slope is quite shallow. To your point, however, many languages (such as Go, d…

what is the difference between linting and static analysis? Coverity, cppcheck etc, what are those? You mention integration tests, but not unit test, do you value unit test?

You could consider linting a subset of static analysis that considers only smaller units of code and not program flow. A linter might tell you your variable names are wrong or your brackets are wrong or you used discouraged method xyz. A different static analysis tool might tell you there's a path through a function that leaks memory.

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

#150

Post by tialaramex »

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

Certainly I find

  if (key_data_.has_value() && !key_data_->label().empty())
    return key_data_->label();
to be less readable than:

  if let Some(label) = key_data_ {
    label
  }
It's notable that people complain Rust adds too many odd punctuation marks, and yet in this example it's C++ with an exclamation mark, question marks, and two different structure member operators (dot and arrow) while Rust just does the pattern match.
Post reply on HN