4 ms·

> I am not sure what can the serialization framework possibly _do_ to make things secure during the serialization Loads of things! A strict specification that

> I am not sure what can the serialization framework possibly _do_ to make things secure during the serialization Loads of things! A strict specification that can only be interpreted one way goes very far. E.g.: a machine-readable BNF grammar file or something similar with no ambiguities. A conformance test suite covering corner-cases is surprisingly effective, even with a supposedly perfect spec. "Be strict with what you generate and lax with what you accept" has been demonstrated over and over again to be a disaster over the long-term in an ecosystem of many groups. Be strict always with what is accepted, not just generated! Speaking of being strict: schema validation is essential. Strong typing for scalars helps a lot. The actual implementations of the spec can obviously have a wide range of security features. Never allowing arbitrary type instantiation is critical, yet is a mistake that keeps reoccurring much like SQL injection. Etc, etc...

eviks 3y ago
what's the best modern alternative that is designed in this way?
- jiggawatts 3y ago
  gRPC ticks most of the checkboxes. Unfortunately these are lessons that have to be learned over and over. Anything based on JSON is generally suspect. If you see the terms "quick" or "simple" in some marketing splash-page, assume the author has not thought about the hard problems like security and long-term interoperability. Similarly, if you find yourself hand-rolling RPC client code and calling methods on something like "HttpClient" manually, you've done it wrong. That code should have been spat out by a code-generator from a schema.
  - signa11 3y ago
    > gRPC ticks most of the checkboxes. huh :) ! gRPC is a 'r-p-c' framework, and uses protobuf for serialization. you should be comparing protobuf to cap'nproto.
signa11 3y ago
> I am not sure what can the serialization framework possibly _do_ to make things secure during the serialization >> Loads of things! >> A strict specification that can only be interpreted one way goes very far. E.g.: a machine-readable BNF grammar file or something similar with no ambiguities. once again, that is not the domain of the serialization framework ! it is a policy which needs to be established and enforced at input / output layer by the entity which implements it. a serialization framework should just serialize and deserialize objects to / from an i/o 'channel' f.e. file, network, etc. shackling it with specification / enforcement of security etc. policies seems conflating one concern with another.

eviks 3y ago

what's the best modern alternative that is designed in this way?

jiggawatts 3y ago
gRPC ticks most of the checkboxes. Unfortunately these are lessons that have to be learned over and over. Anything based on JSON is generally suspect. If you see the terms "quick" or "simple" in some marketing splash-page, assume the author has not thought about the hard problems like security and long-term interoperability. Similarly, if you find yourself hand-rolling RPC client code and calling methods on something like "HttpClient" manually, you've done it wrong. That code should have been spat out by a code-generator from a schema.
- signa11 3y ago
  > gRPC ticks most of the checkboxes. huh :) ! gRPC is a 'r-p-c' framework, and uses protobuf for serialization. you should be comparing protobuf to cap'nproto.

signa11 3y ago

> I am not sure what can the serialization framework possibly _do_ to make things secure during the serialization >> Loads of things! >> A strict specification that can only be interpreted one way goes very far. E.g.: a machine-readable BNF grammar file or something similar with no ambiguities. once again, that is not the domain of the serialization framework ! it is a policy which needs to be established and enforced at input / output layer by the entity which implements it. a serialization framework should just serialize and deserialize objects to / from an i/o 'channel' f.e. file, network, etc. shackling it with specification / enforcement of security etc. policies seems conflating one concern with another.