I'm not sure this observation is receiving the attention it requires. Thiago is right:
A protocol implementation that crashes when it receives malformed data of any kind is unacceptable. Any such bug must be fixed*). Making sure the tests only run with valid protocol data is *not* a fix. The implementation *will* encounter invalid data in the real world, from bad peer implementations and/or from attackers. Each of these crashes needs to have their own test case created (e.g., by deliberately feeding malformed data) to ensure the crash does not re-occur after it has been fixed. Gr??e, Carsten *) e.g., in the case we are looking at, the call site of cbor_value_map_find_value needs to make sure it only calls this function with a first argument that is actually a map. Taking that first argument out of protocol data received while not checking that it is actually a map is a data validation failure; data validation failures may lead to much worse bugs than just crashing. Thiago Macieira wrote: > On sexta-feira, 25 de mar?o de 2016 14:50:37 PDT Light, John J wrote: >> Uze Choi, >> This can also happen with there is a version mismatch in the wire protocol. >> Make sure both client and server are built from the same version. > > Crashing is not acceptable. The code in the new version (1.1) needs to catch > the situation where the data is in the wrong (old) format and discard the > packet, without crashing. >
