Google broke a conditional statement that verifies passwords on Chrome OS • Hacker News Board

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

#271

Post by tialaramex » Sat, Jul 24, 2021, 1:31 AM UTC

jcelerier wrote: post #260

tialaramex wrote: post #254

Earlier quoted context omitted.

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

You're correct to observe that more sophisticated value parametrisation might be useful. At least &str (imagine roughly a nicer std::string_view as a built-in type) is on the horizon for Rust.

Because Rust cares a lot about soundness, this gets very tricky for user-defined types. The current idea is that they could be allowed if they derive Eq. What "derive Eq" means in practice is that the compiler is comfortable believing that either you can compare instances of these types to one another with a bit-match or they're composed of types with that property.

You wouldn't be allowed to implement Eq instead for this, because such implementations are safe in Rust, and thus their promises are worthless (Rust has unsafe traits like Allocator, and if you choose to implement those and get it wrong your program has Undefined Behaviour, but by definition that won't happen for a safe trait, even if you deliberately implement it contrary to the specification)

So that rules out floating point numbers because you shouldn't try to compare those to each other with bit matching - NaNs for example.

What does C++ do here? Just YOLO, if you make poor choices the resulting code is nonsense and too bad?

--

We still don't have an example, the constant function pointer thing feels unergonomic to me, I think I'd cook up a Trait representing whatever it is that these functions have in common, and then implement that Trait as necessary to get the same effect by parametrising on the Trait -- but I may very well be missing some affordance your preferred approach has since the equivalent C++ is just to use a Class and finalize the implementations yet you aren't doing that.

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

#272

Post by encryptluks2 » Sat, Jul 24, 2021, 10:29 AM UTC

perl4ever wrote: post #270

encryptluks2 wrote: post #176

Earlier quoted context omitted.

You have to remember, pretty much anyone can sue anyone... doesn't mean that they'll be successful.

I don't have statistics on that, but I find it implausible that there would be hundreds or thousands of lawsuits against a typical corporation if say, only a couple % won or got a settlement.

I find it hard to believe that people are successful over lawsuits like this. Pretty much every product comes with an agreement that by using the device that you agree to it.

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

#273

Post by snovv_crash » Sat, Jul 24, 2021, 9:08 PM UTC

thaumasiotes wrote: post #268

snovv_crash wrote: post #242

Earlier quoted context omitted.

So, it tests that you're running yes() and no(). But it doesn't test that your choice to use 'a()|b()|c()' for your condition was correct, instead of, for example, 'a()&b()&c()' or even '(a()&b())|c()' because you didn't test all the combinations. Using bitwise instead of logical operations hides this in your branch coverage report.

You are not attempting to have branch coverage; you are attempting to cover the space of possible inputs.

You're trying to check that all of your logic is correct. That's the point of doing tests. If your test doesn't check for certain input combinations, then you haven't tested your logic completely.

The point of branch coverage is to show when you missed input combinations for your logic. Artificially running all of the branches and then throwing away results just gives you a false sense of security about how much of your logic you covered.

I mean, technically, using bitwise instead of short-circuiting logic doesn't have branches at an assembly code level. But this is pedantry because we're actually trying to check the logic is correct, not that our compiler can correctly translate && into the same Boolean result as &.

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

#274

Post by Trollmann » Sun, Jul 25, 2021, 12:53 AM UTC

areyousure wrote: post #133

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

While it is true that you can use `and` in C++11, that's a bit of an understatement: these keywords have in fact been present since the very first ISO C++ standard C++98!

TIL! Always thought this was a C++11 feature. Then this argument against the 'new' keywords is even weaker.

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

#275

Post by Trollmann » Sun, Jul 25, 2021, 12:56 AM UTC

yongjik wrote: post #162

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

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

> ... which, frankly, is a very good reason. Don't needlessly change something people are used to.

Unless this reason is causing bugs and security issues.

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

#276

Post by sneak » Sun, Jul 25, 2021, 9:49 PM UTC

ascagnel_ wrote: post #253

nicoburns wrote: post #122

Earlier quoted context omitted.

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

This specific type of failure is evidence that they didn't build the safest thing they can.

Linting catches this.