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

251–260 of 276 posts

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

#251

Post by gpderetta »

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 lost track how many times I have been bitten by the ok = ok && ... trap.

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

#252

Post by inetknght »

josefx wrote: post #188
inetknght wrote: post #105

Earlier quoted context omitted.

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

They have been around since the first standard and basically only exist as a hack around an ancient non ascii compatible encoding. So unless you got burned in 1995 nothing about them was new. They also aren't very consistent between C derived languages. Mostly because C# inherited its versions from VisualBasic, where And is a bitwise operator instead of a short circuiting one.

> * So unless you got burned in 1995 nothing about them was new.*

I didn't mean to imply that they were new features to the language. I meant to imply that they were new style of coding to the manager & coworkers.

Some other features that have burned me from managers & coworkers is `using` to change the visibility of parent class members & functions and CRTP.

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

#253

Post by ascagnel_ »

nicoburns wrote: post #122
ectopod wrote: post #97

Earlier quoted context omitted.

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.

Reprimanding is one thing and firing another though. I certainly think the manager in charge deserves a reprimand.

I wouldn't even say a reprimand is necessary here.

Programming safety is like safety in auto racing or rock climbing: you build the safest thing you can, but the activity you're doing is inherently unsafe, and it will generate failures despite the presence safety measures, so you do your best to study those failures to mitigate them the best you can.

The only time adverse action like a reprimand is necessary is if the manager or tech lead don't take any action to prevent future issues. The only time a firing is necessary is if the security issue was created with intent, rather than accidentally.

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

#254

Post by tialaramex »

jcelerier wrote: post #177
Macha wrote: post #143

Earlier quoted context omitted.

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

It only supports integers so far, which c++ could do pretty much since before it was even standardized 25 years ago. Doesn't seem to support as wide of a type menagerie as C++20's NTTP. Does it even support parametrization over function pointers ?

> It only supports integers so far

Integer-like things. C++ char is similar to Rust's u8 or i8 but Rust's char and bool are very deliberately not just integers.

> Does it even support parametrization over function pointers ?

Can you give a clear example ? I think the answer is "No" but I struggled to put together an application for the feature I'm imagining.

You would like to define a type, which is parameterised not by the type of function, but by specific functions? So, for example I can make a foo and a foo and those are distinct types which presumably internally are using the provided function to behave differently?

Except all the examples I think of come out better with just parametrisation over traits instead. So a clear example from you might illuminate whether this is a sizeable hole or just a difference of philosophy.

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

#255

Post by Mindwipe »

Guidii wrote: post #87
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…

"Heads should probably roll here..." Google has a blameless post-mortem process (see https://sre.google/sre-book/postmortem-culture/ ) which essentially boils down to: 0) We want to fix the situation. By the time the post-mortem happens, that should already be done. 1) We want to make sure this never happens again. In order to do that we need to understand as much as we can about what happened. 2) We want everyone to…

Blameless post-mortems are good, but there have been rather a lot of bootloader level disasters on ChromeOS/Android and where they intersect at this point and it is probably worth wondering why this process does not seem to be generating sufficient improvement to make customer devices work better.

One notes that even years later Google still haven't figured out why the Pixel C occasionally just forgot it's own passcode and encryption key and locked users out. Thousands of reports, and publicly acknowledged as an issue. Never addressed. Pixel devices have had multiple bootloader issues and are currently experiencing a widespread Widevine downgrade for months and not fixed.

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

#256

Post by tpoindex »

snvzz wrote: post #62

What it means is: They push crap to users with no testing. Testing would have caught this.

There is a policy that would probably catch these types of errors - Chromeos developers should eat their own dog food, i.e., developers should be required to use a Chromebook on the "dev" or "beta" channels as their daily machines. Sure, use a cloud VM to get work done, but login, email, browsing, etc. done on the Chromebook. Google itself has fine machines for this purpose.

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

#257

Post by tialaramex »

inshadows wrote: post #236
tialaramex wrote: post #229

Earlier quoted context omitted.

I recommend stepping back for a moment and asking yourself: Why is it that you, the person who believe they "know what UB is" and is sure "this is not UB" did not understand what's going on here, while the other people reading who explained why it's UB have understood exactly what's going on ? Doesn't it seem most likely that you in fact do not understand Undefined Behaviour and didn't understand what's going on ?

I don't think you understand UB, because clearly, this is not UB. But I congratulate you. You have enough knowledge to engage in Internet discussions involving fancy names without understanding underlying concepts. Hint: 1) Read my original post. 2) Contemplate whether the compiler is removing anything in this instance.

> Read my original post.

Your original post has some questions. This is good, when you don't understand the world, you can ask questions and other people can help you to understand. Let's look at the questions:

> Where is the undefined behavior?

Using an Optional's value when it doesn't have one is Undefined. Specifically in this case use of the arrow operator on key_data_ is undefined.

> how can the compiler infer that has_value() call has any relation to key_data_ non-NULL-ness?

The compiler is allowed to use almost whatever means it wants to infer this type of relationship. For example if the Optional has_value() checks a member pointer isn't nullptr, and the arrow operator overload uses that pointer, the compiler can infer that if the arrow operator was used then has_value() is true.

At this point you had exciting opportunities to learn stuff you didn't understand about C++

Unfortunately, you also insisted upon some claims that are false, perhaps things you wrongly believed about C++ already that now came up against a fact about the world which seemed to prove them wrong. In particular:

> But that undefined behavior happens at runtime, i.e. compile time UB is not invoked

This isn't a thing. If you learned it somewhere, the source was wrong, if you've instead developed this as some sort of intuition about how C++ works, dismiss this understanding, it will continue to mislead you if retained.

Undefined Behaviour is a claim about the entire program which is useful to the compiler since its purpose is to transform the program. If it was Undefined before the transformation, it will still be Undefined afterwards, no matter what the transformation did, so you didn't break anything with your transformation.

> the statements are kept without any optimizations.

No. The compiler is free to use what it knows to optimize this code. Undefined Behaviour frees it up to optimize here a whole lot more than otherwise.

In particular it needn't worry about scenarios where key_data.has_value() is false, those have Undefined Behaviour, so nothing it could do is wrong.

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

#259

Post by TechBro8615 »

Guidii wrote: post #87
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…

"Heads should probably roll here..." Google has a blameless post-mortem process (see https://sre.google/sre-book/postmortem-culture/ ) which essentially boils down to: 0) We want to fix the situation. By the time the post-mortem happens, that should already be done. 1) We want to make sure this never happens again. In order to do that we need to understand as much as we can about what happened. 2) We want everyone to…

Sounds nice, but how much is this really true in practice? If one guy on the team seriously screws up, won't the rest of the team naturally trust him less?

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

#260

Post by jcelerier »

tialaramex wrote: post #254
jcelerier wrote: post #177

Earlier quoted context omitted.

It only supports integers so far, which c++ could do pretty much since before it was even standardized 25 years ago. Doesn't seem to support as wide of a type menagerie as C++20's NTTP. Does it even support parametrization over function pointers ?

> It only supports integers so far Integer-like things. C++ char is similar to Rust's u8 or i8 but Rust's char and bool are very deliberately not just integers. > Does it even support parametrization over function pointers ? Can you give a clear example ? I think the answer is "No" but I struggled to put together an application for the feature I'm imagining. You would like to define a type, which is parameterised not…

> Integer-like things. C++ char is similar to Rust's u8 or i8 but Rust's char and bool are very deliberately not just integers.

sure, but there's an easy mapping from char / bool to integers. C++ supports parametrizing on values of struct type, which is a clear increase in expressive power:

    struct foo {
      int count;
      float init;
    };
    
    template struct bar {
      float x[arg.count];
      
      bar() {
       for(int i = 0; i  b;
> You would like to define a type, which is parameterised not by the type of function, but by specific functions? So, for example I can make a foo and a foo and those are distinct types which presumably internally are using the provided function to behave differently?

yes, it's pretty much the only way in C++ to have zero-cost callbacks / strategy pattern using function pointers since the compiler can directly inline the function pointer everywhere in the type's implementation instead of having to go and read it from some variable at run-time

Post reply on HN