hrektts / cdr-rs Goto Github PK

I'd like to implement a GIOP/IIOP interface using this crate. However, there is no 4-byte encapsulation header in this protocol; the byte order is marked in the encoded stream (in non-byte-order-sensitive types).

Would it be possible to introduce API to encode without the header, and to specify the encapsulation in the decode call? Otherwise I can't use the _into/_from APIs and have to use allocations.

Two issues in size.rs I see the following code.

First:

   fn serialize_char(self, v: char) -> Result<Self::Ok> {
        self.add_size(v.len_utf8() as u64)
    }

A char in CDR is always u8, it is irritating, that code code here is assuming a dynamic size depending on utf encoding

AFAICS, it should be:

 fn serialize_char(self, v: char) -> Result<Self::Ok> {
        // no alignment required increment byte-size 1
        self.add_size(1 as u8)
 }

Second:

Another weird thing is this code, it will add byte-size of u8 to the counte (1)r, but according to name it should add 0!?

    fn serialize_none(self) -> Result<Self::Ok> {
        self.add_value(0 as u8)
    }

Hello,

First of thanks for contributing the CDR codec, this has helped us a lot in getting zenoh (see https://github.com/eclipse-zenoh/zenoh and http://zenoh.io) seamlessly read/write data from DDS and ROS2.

As a little contribution on our side, we'd like to eliminate all clippy warning, as you'll see by running cargo clippy there is at least one that is quite important on the de.rs | read_vec.

I'll do a pull request right off with the fixes. Ideally would be good to have cargo clippy run as part of the GitHub actions.

Thanks!

• kydos

In the CDR described in the RTPS standard, all 64 bit integers are serialized as an i32 representing the high part (most significant 32 bits) and a u32 representing low part (least significant 32 bits). See for example section 9.4.2.5 Sequence Number in DDSI-RTPS version 2.3 standard.

If I am not mistaken, the implementation in this library serializes these 64 bit objects as a complete set of 8 octets.

I am not sure if your objective is to follow closely the RTPS serialization but I wondered if it would be a possibility to change the current implementation to match the RTPS serialization of 64 bit objects?

Hello 🦀 ,
we (Rust group @sslab-gatech) found a memory-safety/soundness issue in this crate while scanning Rust code on crates.io for potential vulnerabilities.

Issue Description

Deserializer::read_vec method creates an uninitialized buffer and passes it to user-provided Read implementation (self.reader.read_exact). This is unsound, because it allows safe Rust code to exhibit an undefined behavior (read from uninitialized memory).

Suggested Fix

It is safe to zero-initialize the newly allocated part of u8 buffer before read(), in order to prevent user-provided Read from getting access to the old contents from the newly allocated heap memory.

Thank you for checking out this issue 👍