Oh yes, security is a high priority. It's definitely wrong if malicious data can crash the receiver. The security notes on that page are not a complete story, just mentioning a couple of the less-obvious concerns. It's my intent that the Cap'n Proto runtime should protect the application from all security issues related to decoding, so that apps don't have to worry about it.
The pointers are not actually native pointers, and when you dereference a pointer, the implementation does bounds checking to make sure it points within the message.
I am a security wonk myself and have been thinking carefully about these things, but I also hope to get a formal security review from a third party before any production release.
To some extent, yes. But the total overhead of bounds-checking pointers in a Cap'n Proto message is orders of magnitude smaller than the overhead of decoding an equivalent protobuf message. (You can see this in my benchmarks. Look for "object manipulation time". It's usually a bit slower for Cap'n Proto, but the total time is dwarfed by I/O time.)
Yes! If you really, truly trust your input data, and it is in a single flat array, you can call capnproto::readRootTrusted<MyType>(ptr) instead of setting up a MessageReader. All bounds checks and other validation will be skipped.
But, IMO this is only a good idea for, like, static constants embedded into the source code. Anything you read dynamically could be corrupted if not malicious, and you don't want that to kill your server.
The pointers are not actually native pointers, and when you dereference a pointer, the implementation does bounds checking to make sure it points within the message.
I am a security wonk myself and have been thinking carefully about these things, but I also hope to get a formal security review from a third party before any production release.