I write this letter from the distant past, late in the month of November in the distant pass of 2017. From your lofty throne upon a future so bright, I urge you to remember the sad lives we lead as a return code type mismatch caused every Mac OS X machine running modern software to be accessible by anyone with physical access by typing "root" into the login field then hammering on the Enter key like a 9 year old.

Morale is high, because we know we cannot be sued for this act of gross incompetence. We have decided to solve this problem by shaking our heads at people who code in C and ignoring any similarities to our own toolkits.

Please remember us and our backwards ways.

Sincerely,

A time traveler from about 3 days ago.

I don't doubt you, but I was just trying to read up on details of this and the internet is so full of fluff pieces that I can't find anything technical real quick. Would you have a link to a writeup of the bug behind this issue?

The relevant function returns an opaque integer to signal failure/success. If this were typed properly — e.g. a type that represents either “Success” or “Failure” explicitly (rather than implicitly via an int) — the bug would be unlikely to happen, since it would require the function in question to explicitly return “Success” when in fact it had failed (as opposed to the opaque 0x01).

Rust goes part of the way here by ensuring that Result variables get checked: https://doc.rust-lang.org/std/result/#results-must-be-used which to my knowledge is not something you can mimic in C/C++. But you could still forget a negation or use && instead of || somewhere, and have an uncommon code path fail.

Code review reduces but doesn't eliminate the probability of these complex logic errors. What's really needed is tooling that ensures test coverage on a phrase-by-phrase, not line-by-line, basis. (Basic line coverage would have said that all these lines of code were executed in testing.) And you need a culture around paying attention to those results. That can be very difficult to build, but for mission-critical software (security included) you absolutely need that level of attention to detail.

We can capture that requirement with something called Linear typing, but even if we don't go for a compiler-enforced consumption the creation of a universally used family of result enums brings enormous discipline and reliability to error handling. In no small part because when considering the result of such an enum, the compiler can demand a total pattern match, which forces developers to consider what that failure means in context and present SOME kind of strategy (even if it's hard failure).

The approaches of languages with type inference and more sophisticated type systems like OCaml and Haskell go even a step further because they can create workflows around these types, creating composite workflows that make it easy to handle errors. It becomes harder to ignore them, or write functions that ignore them.

One of the reasons it's so easy to write parsers in languages like Haskell is that algebraic data types and applicative functor composition make it easy and even convenient to talk about the logic within the context of non-trivial error flows. It's much more frustrating to write a parser without a combinator framework in OCaml or Haskell. Similar stories exist for Validator, Either, and Maybe/Option.

These techniques don't mandate error processing, but they make it more convenient to compose error-handling functions and offer more compiler checking when the results must be handled.

https://objective-see.com/blog/blog_0x24.html notes that od_verify_crypt_password is called with an error check expecting 0, but on failure it returns 0x1. The code then goes on to a "success" path with an "update".

This is a classical type mismatch that C and C++ pre-2012 are so famous for. Someone writing this program where both modules were in Rust would have used Option or Result and this expectation mismatch wouldn't have existed.

A better type checker, better standards and practices, and better discipline around customer facing code are all required, but folks like you demand that every programmer must do it all by hand and then never make a mistake. It's ludicrous.

This is like you saying, "Well cars are so unsafe you can't expect to live if you ride in one. Look at these pictures of horrible car wrecks. These Model Ts are death traps. But we all drove to the talk in Teslas and we're not even sure what the heck you're on about.

Don't use your lack of (or refusal to obtain) familiarity with type systems and type theory as evidence of their inability to help with these problems.

Also, why do you think that Microsoft is secretly pushing static typing? /Maybe/ it's shilling for TypeScript, but there are a lot of other statically typed languages that compile to JavaScript, such as Elm.

JavaScript is the perfect enterprise language. And that's where $M makes most of it's money. But they do not fully control JavaScript, and they have little control over NodeJS. So what do you do ? Embrace, extend, and extinguish! You add enterprise feature! That will convert users back into your ecosystem again! While at the same time trying to hurt JavaScript and NodeJS. Interestingly though Samsung recently bought NodeJS and their new devices does have JavaScript support, so hopefully NodeJS and JavaScript will not be too easy to extinguish.

TL;DR: both Flow and TypeScript are pretty good, and conservatively either of them can prevent about 15% of the bugs that end up in committed code.