Starting a new, blue water distributed encryption system in a non-safe language is odd at this point. The protocol is being _noodled_ through and the code is in C.
Copying multi-byte values into a network packet is a typical error made by novice developers - this will bite you hard as soon as somebody compiles the code on a Big Endian machine. Even if you might get away with this on opaque elements like a ping ID, the general approach should not be followed.
Because NASA has used C means this guy writes code for the shuttle?
Read the code. Dig through the commit logs. This is the wrong choice on about every level. The best encryption won't save you when you have code like this.
the only thing I'm seeing from your posts is "I'm a fucking idiot who doesn't understand that C is safer than any interpreted pretend-you're-safe language"
Comparing C to Javascript makes no sense, and Javascript is NOT a safe language. Those issues you mentioned are due to programmer incompetence. Bad programmers will make bad code no matter what language they program in. Security should not rely on a language hand-holding bad programmers.
The classes of problems that one encounters in Ada, Haskell, OCaml, Rust, D or Go are vastly different than in languages w/o memory safety.
Writing secure network code in an non-safe language is something that shouldn't be taken lightly. Given the nature of the commits it is hard to comprehend that this product will ever achieve its stated aims.
> memcpy(packet + 1, &con->ping_request_id, sizeof(uint64_t));
Copying multi-byte values into a network packet is a typical error made by novice developers - this will bite you hard as soon as somebody compiles the code on a Big Endian machine. Even if you might get away with this on opaque elements like a ping ID, the general approach should not be followed.