Feature request: opt-in strict deterministic decoding with resource limits

[sliceofcode-dev]

Context

We are evaluating cbor@6.5.1 for verifying signed RFC 8949 deterministic
CBOR received from an untrusted network. The current package is useful as a
general codec, but application validation after ordinary Dart object
construction cannot recover duplicate map keys and does not bound hostile
input before allocation.

Would you be open to an opt-in strict decoder mode? Existing permissive behavior
could remain the default.

Requested controls

A strict options object would ideally support:

• reject duplicate map keys before map construction;
• require RFC 8949 Section 4.2.1 bytewise-lexicographic map-key order;
• require preferred/shortest integer, length, and simple-value encodings;
• reject indefinite-length items;
• optionally reject tags, floats, null, and undefined;
• eagerly reject invalid UTF-8 without replacement characters;
• require exactly one fully consumed top-level item; and
• enforce finite limits for input bytes, nesting depth, map entries, array
  entries, text/byte-string bytes, and total decoded items before excessive
  allocation or recursion.

On failure, it would help to return no partial decoded value and expose one
documented exception type with a stable reason category and byte offset. Useful
categories could include malformed, nonPreferred, duplicateKey,
mapOrder, disallowedType, invalidUtf8, trailingData, and
resourceLimit.

Important ordering detail

The deterministic profile is RFC 8949 Section 4.2.1, not the Section 4.2.3
length-first alternative. A regression could require the mixed-key order 10,
100, -1, whose deterministic encodings begin 0a, 1864, 20.

Why decoder-level support matters

Deterministically re-encoding and comparing bytes is still useful, but it
cannot detect duplicate keys after a Dart map has already collapsed them.
Similarly, application-level collection checks happen too late to prevent
parser allocation. These properties therefore need tokenizer/decoder support.

Is this direction compatible with the package's design? We can adapt to the
maintainer's preferred API shape and provide focused valid/invalid fixtures for
discussion.

[shamblett]

Yes I'm open to this, sounds like a good addition to the package especially with an RFC behind it.

My only real concern is existing users. ideally there should be no impact on them by the addition of the strict decoder either in the existing API or decoding behaviour. Its relatively easy to inadvertently introduce subtle behavioural changes that may trip existing users up. To guard against this the strict decoder should as far as practically possible be entirely seperate from the existing code which from your description above seems to imply that it would anyway. I realise that base types may be re-used to prevent code duplicatuion but this must be strictly monitored, ideally any changes to these types, if needed, should be in the form of extensions rather than updating them directly.

A good benchmark for conformance to this is the existing test suite, the existing unit test suite should run entirely with no errors and no changes to it. This is not totally exhaustive of course but should uncover any impacting behavioral changes. The strict decoder can of course have its own unit test suite in its own files.

I'm not familiar with RFC 8949 sections you mention above but it seems you are proposing a kind of sanitation phase before decoding proper, so is it a viable plan to run the incoming CBOR data through a strict options layer before feeding the possibly updated CBOR data into the existing decoder or does the impact of these checks dictate a more complete seperate decoder?