Conversation

FFS stop using C.

Quote Tweet

Oct 31, 2018

Kudos to Christian Reiter and Jochen Hoenicke for identifying and disclosing vulnerability in reference implementation of bech32 address handling. This affects many Bitcoin projects, ask your favourite devs for update! blog.trezor.io/details-about-

Replying to

Mad respect, but I also ask, what is wrong with C? Can't you get in equal amounts of trouble in other languages that expose pointers? #JustCurious

Replying to

You can! For instance if this was written in unsafe Rust I'd be complaining as well. But the lesson there is that a bech32 implementation doesn't need to be written in unsafe Rust; use safe Rust instead.

Replying to

and

There are cases where you don't have a choice - I've written a lot of unsafe Rust myself. But bech32 implementations don't need to do anything low level, and there's no need to squeeze the last % of performance out (there might even be no difference in performance).

Replying to

and

The problem is pointers and languages that rely on them. It's just too easy to screw up code that uses them, and we have better alternatives now like Rust's reference system.

Replying to

and

What do you think about languages that try to be secure beyond memory safety (I am mostly thinking on functional languages like OCaml)to write this kind of security critacal code?

Replying to

and

Rust certainly is one. It's not just a memory safe low-level language. It has a modern type system with algebraic data types, type classes usable for both generics and as objects, etc. The ownership / borrowing systems for memory safety catch many non-memory-safety problems too.

6:30 PM · Nov 2, 2018Twitter Web Client

Replying to

The system preventing use-after-free and other memory corruption bugs prevents issues like iterator invalidation or using a file after it's closed still present in a modern garbage collected languages. It also prevents data races between threads (not race conditions as a whole).