Subject: [Cbor] FYI: bug in CBOR Python packages

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Aug 2017 12:10:13 +1200

Hi,

Not a standards issue, but this may be useful:

I recently discovered the hard way that in both the cbor and cbor2
packages for CBOR handling in Python, when using cbor.loads() or
cbor2.loads(), the length of byte strings is not checked. For example,
when decoding an instance of Tag 24, if the target byte string is
truncated, .loads() does not throw an exception; it simply returns
the truncated bytes object.

I raised an issue for both packages. cbor2 was fixed within 24 hours;
version cbor2-4.0.1 is fixed and throws an exception:
cbor2.decoder.CBORDecodeError: premature end of stream (expected to read 233 bytes, got 225 instead)

The older cbor package still has the problem.

(All this applies to both Python 2 and Python 3.)

Regards
   Brian Carpenter

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Aug 2017 06:43:38 +0200

If we ever write an implementers’ guide, this would be one thing to mention there.
We could write up a list of errors that need to be handled, and mention that premature end of input cannot be handled by silent truncation of ongoing data items.
Maybe it would make sense to collect test cases such as

19 01
63 66 6f
82 01
A2 01 02 03
c1
etc.

(So far, I haven’t seen much need for an implementers’ guide, though.
But maybe that will start to make sense as the body of knowledge on how to implement CBOR well increases.)

Grüße, Carsten

> On Aug 22, 2017, at 02:10, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Aug 2017 11:14:29 +1200

> But maybe that will start to make sense as the body of knowledge on how to implement CBOR well increases.)

Perhaps an implementer's wiki would be a useful start, as a repository for such items.

Here's another related point: Both the Python libraries do a decent job of decoding
tagged items into high-level language objects, but the implementers took different
decisions about naming the class for the decoded object. One chose
<class 'cbor2.types.CBORTag'> and the other chose <class 'cbor.cbor.Tag'>

Not a big deal, but would it be useful to recommend class names, in the
general interest of portability and the Law of Least Astonishment?

   Brian